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://github.com/sandip4n/gem5/commit/3dd0438159d67fe2b5bcc777b43046fdca90f6b9 > 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://gem5.atlassian.net/browse/GEM5-819. 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 and 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://github.com/sandip4n/gem5/commit/3b0203e63d892c94fd0e67cfe79f5e6662504c4a >> 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 -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
