Hi Jason. As I've said somewhere before (maybe this thread?), that is mostly not changing. There will still be an m5 library for use in other programs, a java and lua wrapper, an m5 utility which takes basically the same commands (with some cruft removed), etc. The changes are that I'm refactoring and reimplementing the guts of the code and the build process so that it's scalable, features are implemented consistently across ISAs, bit rotted code is fixed, there are tests, etc.
The main user visible change I've made is that the way the m5 ops are called run time selectable rather than build time selectable, as described in the document I referenced. I've also made it possible to use the utility to call m5 ops through ARM semihosting so they can be used with fast model CPUs. The build process is different now too, although that is more utilitarian. I've gotten rid of many of the previous setup's shortcomings which I won't enumerate here, but it still builds the same things more or less, plus the tests I'm adding. Gabe On Tue, Apr 7, 2020 at 7:55 AM Jason Lowe-Power <ja...@lowepower.com> wrote: > Hey Gabe, > > I'd love to review your patches that you've posted improving the m5 > utility, but I don't feel that I can review them well without understanding > what the end goal is. If you could provide some documentation on how you > see the m5 utility being used, then I can try to carve out some time to > review your code. > > Thanks, > Jason > > On Tue, Mar 31, 2020 at 3:28 PM Jason Lowe-Power <ja...@lowepower.com> > wrote: > >> Oh, one more comment... >> >> Do you think it's worth changing the name to "gem5" instead of "m5". >> Since we're making big changes, it seems like now might be right time. >> >> Cheers, >> Jason >> >> On Tue, Mar 31, 2020 at 3:10 PM Jason Lowe-Power <ja...@lowepower.com> >> wrote: >> >>> Hey Gabe, >>> >>> First of all, thanks for this cleanup. We've needed to update this code >>> for a long time! >>> >>> Do you have a pointer to what would be "new" documentation on the m5 ops >>> tools? I was briefly going through your changes and it's not clear how >>> you're envisioning people using this library now. For instance, I'd like to >>> understand: >>> - How do I build the m5 binary for full system mode? >>> - How do I link my application to the m5 "library" in SE mode? >>> - How do I link my application to the m5 "library" in FS mode? >>> >>> Before, this wasn't documented very well, but it was kinda obvious that >>> you just "had to do it yourself". With your changes, it looks like you have >>> some very specific use cases in mind. It would be good to understand your >>> vision while I'm reviewing these changes. I looked through the document you >>> linked in your other email, but didn't really see how this fit in. >>> >>> Thanks! >>> Jason >>> >>> On Fri, Mar 27, 2020 at 6:31 PM Gabe Black <gabebl...@google.com> wrote: >>> >>>> Hi folks. I just uploaded a series (mostly small) patches which revamp >>>> the >>>> m5 utility as described in a design document I sent out a while ago. >>>> I've >>>> done some very preliminary sanity testing, but a lot more testing >>>> can/should be done to make sure I didn't screw anything up. >>>> >>>> One thing in particular that still needs to be done is to expand the >>>> java >>>> and lua wrappers so that they can call the different backends for the m5 >>>> ops (instruction, address, and semihosting). That can be done in the >>>> future >>>> since I *suspect* those wrappers aren't used very much. If we provide >>>> them >>>> though, we should try to make sure they work. >>>> >>>> https://gem5-review.googlesource.com/c/public/gem5/+/27246/1 >>>> >>>> Gabe >>>> _______________________________________________ >>>> gem5-dev mailing list >>>> gem5-dev@gem5.org >>>> http://m5sim.org/mailman/listinfo/gem5-dev >>> >>> _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
