> I think I had come across that problem too but I am sure > that one of my patches will fix that. Probably this one
Yes -- that's what I meant by "commits related to 3dd04381". So, let's start with this small area. > Yes, I can submit it via gerrit. > As a kernel developer, I am more used to mailing list based reviews > but feel free to let me know what works best for you. Gerrit is the procedure currently used by the gem5 community. Even though I personally find it non-ideal, it is kind of a given for the foreseeable future, and I think the optimal scenario (within the realistic choices) would be if you started upstreaming using that procedure. The other alternative, of which I was afraid before I initially wrote to you, would have been if you had abandoned the project or had no time/energy to do the rebasing / pushing / working with the review, in that case I was thinking about just taking your patches and putting them on Gerrit myself but I can see a whole number of reasons to avoid this. -----"Sandipan Das" <[email protected]> wrote: ----- To: "Boris Shingarov" <[email protected]> From: "Sandipan Das" <[email protected]> Date: 02/03/2021 01:30PM Cc: [email protected], "Pratik Rajesh Sampat" <[email protected]>, "Kajol Jain" <[email protected]>, "Gautham R. Shenoy" <[email protected]>, "gem5 Developer List" <[email protected]> Subject: Re: [gem5-dev] Re: Upstreaming power-gem5 Hello Boris, On 03/02/21 2:34 am, Boris Shingarov wrote: > Hi Sandipan, > >> This makes it possible >> to run both 32-bit and 64-bit big and little endian PowerPC binaries >> in SE mode. If its okay with you, we can start by working on trying to >> get these changes reviewed and merged first. > > Yes, yes! This aligns very well with both what sequence I think is the most > realistic technically, and with my project's priorities. > Great! >> You can find them here: [develop-power] > > Some of these commits just scream as the perfect first candidates, for > example > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sandip4n_gem5_commit_3dd0438159d67fe2b5bcc777b43046fdca90f6b9&d=DwICaQ&c=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc&r=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4&m=wgWrcP9-wt5oZuq9SWs5UbL4CH93tpVcax1mrsrf0hU&s=qRcEv2oabPve_Q2GdbmZOqMVBxL32Co3y4ROuJevXDA&e= > and related. Because right now the Decoder is in a really sad state, > crashing even on simple, perfectly valid programs (and that's even within BE, > 32-bit SE), see for example > https://urldefense.proofpoint.com/v2/url?u=https-3A__gem5.atlassian.net_browse_GEM5-2D819&d=DwICaQ&c=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc&r=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4&m=wgWrcP9-wt5oZuq9SWs5UbL4CH93tpVcax1mrsrf0hU&s=ST81CURwY4zbSASQ6L3PKNAA0FC7ia8-GQTVzzunqEs&e=. > So, how about we start from that one? How would you like to proceed -- do > you want to submit on Gerrit using the regular process a nd I will review it? > I think I had come across that problem too but I am sure that one of my patches will fix that. Probably this one: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_sandip4n_gem5_commit_3b0203e63d892c94fd0e67cfe79f5e6662504c4a&d=DwICaQ&c=sPZ6DeHLiehUHQWKIrsNwWp3t7snrE-az24ztT0w7Jc&r=ecC5uu6ubGhPt6qQ8xWcSQh1QUJ8B1-CG4B9kRM0nd4&m=wgWrcP9-wt5oZuq9SWs5UbL4CH93tpVcax1mrsrf0hU&s=GAbuvqL0DsFG6QcbNsVo4liY1x1U2DR8YE0ekWQDYE8&e= >> this has been a hobby/side project and hence, the biggest >> challenge for us has been finding spare cycles > > At my day job at LabWare, I write JIT compilers, and the development > technology is centered around simulation -- so I can't draw a bright line > where gem5 stops being a "side" project and becomes part of the "main" > project because the latter depends on it. But it does mean that I naturally > have more timeslices for some aspects of gem5 than for other aspects. >>> So, in order for external UARTs like 8250 to be >> used for console interactions, we currently use some hacks >> which I am sure are not quite upstreamable > > Yeah, we are in the same boat here. > I, too, have a long queue of hacks to gem5 which I did just to enable some > experiments with the JIT compiler; they've been waiting *years* that I rework > them into "real" patches to go upstream -- but that stage of work is very > slow and painful labour. > Sounds interesting. I have minimal experience with JIT compilers having worked on the Linux kernel's in-built eBPF JIT compilers. Have peeked into Qemu's TCG too. On that note, are there any plans to add a JIT engine to gem5? Since gem5 supports checkpoints, uninteresting parts of a program can be run in JITed mode to speed things up. >> The FS mode changes depend on 64-bit support but aside from that, >> it also needs a fair amount > > What scares me every time I think about FS, is that it will need coordinating > across projects/communities (Kernel, OPAL, ...) where I don't have a lot of > background in. Well, let's worry about FS when the time comes. > The folks that I work with here at IBM LTC can assist us with that. Besides, like we agreed, lets start with SE mode. - Sandipan _______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
