Hi Jason, replies inline. On Tue, Mar 31, 2020 at 3:29 PM Jason Lowe-Power <[email protected]> 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. > That's not a bad idea, although there are a lot of compatibility issues that make me want to keep that separate. For instance, if we change all the names for the symbols for calling the ops from m5_* to gem5_*, that would break existing consumers of the library. It would be easy to fix them with simple find/replace assuming they can be rebuilt and is probably worth doing, but it would be a good idea to draw people's attention to it before hand. In general I think it would be a good idea to pick a good name for these operations (m5 ops, gem5 ops, pseudo ops, pseudo instructions) and stick with it throughout the code base. I personally like gem5 ops since we're not m5 any more, they aren't always instructions, and if they aren't there not really pseudo anything, but again it would be nice to let people have some input before scrubbing that down. > > Cheers, > Jason > > On Tue, Mar 31, 2020 at 3:10 PM Jason Lowe-Power <[email protected]> > 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? > scons build/${version you want} For aarch64 for instance, this will build, among other things, build/aarch64/out/m5 which is the m5 binary for 64 bit ARM. It will support the instruction based method (default, or with --inst), address based method (with --addr, or --addr=${address}, or --addr ${address}), and semihosting based method (with --semi). > > - How do I link my application to the m5 "library" in SE mode? > This is the same as before, just link against build/${version}/out/libm5.a, and include the same header in include/m5ops.h. Note that the version of the functions in the header have no suffix, and so will use the instruction based call method. There aren't prototypes for them (I should fix that in a later change), but there are also versions with suffixes which use the other methods, *_addr and *_semi. > > - How do I link my application to the m5 "library" in FS mode? > Same as above. > > > > 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. > Much of this is generic cleanup to get to a good spot to implement what's in that doc, rather than building on top of an unstable base. The doc is describing how the utility will now support multiple call methods in the same utility, and how it will support calling through semihosting on ARM. It would be a good idea to make some sort of README to put in the m5 utility directory and/or on the website, and I have plans (which I need to write up) about how to build tests for the m5 utility so it doesn't get broken as easily in the future. > > > > Thanks! > > Jason > > > > On Fri, Mar 27, 2020 at 6:31 PM Gabe Black <[email protected]> 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 > >> [email protected] > >> http://m5sim.org/mailman/listinfo/gem5-dev > > > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
