Hi all, I (finally) finished rebasing and updating the changes based on the feedback. Thank you all for your help on this!
On the to do list before merging: - Some more comments that may need a bit of back and forth (especially from Andreas as of 5/26) - Run the nightly and weekly tests on the tip - Update the website and release notes Here's the changes again if anyone else wants to provide feedback :) https://gem5-review.googlesource.com/q/topic:all-ruby-protocols Cheers, Jason On Tue, Apr 12, 2022 at 1:44 PM Jason Lowe-Power <ja...@lowepower.com> wrote: > Hi all, > > I would really appreciate some reviews on these changes. This is something > that I know many in the development community (Andreas, Gabe, others) have > been asking for. Please take a look! > > I think most changes are pretty straightforward. There is one change where > I would like some specific feedback on a good way to incorporate multiple > Ruby protocols into the SConscript ( > https://gem5-review.googlesource.com/c/public/gem5/+/58443/2) > > Hi Giacomo, > > I dug into the idea you proposed a bit more today, and I'm pretty > convinced that it would be significant work. > > It's possible to make a SimObject be part of a submodule of m5.objects. > However, the problem comes in the params. I don't think there's an easy way > to create two params/<simobject>.hh files for SimObjects which have the > same name. > > Basically, we have a strong assumption in the SimObject generation code > that no two SimObjects will have exactly the same name. Extending this to > allow SimObjects with the same name would be quite a bit of effort. Right > now, I don't believe this effort is worth the benefit for this set of > changes. > > Let me know what you think. > > Cheers, > Jason > > On Fri, Apr 1, 2022 at 7:48 AM Jason Lowe-Power <ja...@lowepower.com> > wrote: > >> Sounds like a good idea. But I don't know how to do this easily. All >> SimObjects are part of the m5.object module, and this is deeply embedded in >> many different parts of gem5. >> >> My best guess at how to do this would be to add a new type of SimObject >> which is not in m5.objects, but in a submodule. Then, we would also have to >> extend the Scons concept of "SimObject" and how scons creates the SimObject >> params files and the python m5.objects files. My initial thought is that >> this would be a lot more work. I could be wrong, though. >> >> If you have a specific idea on how to implement this, or if you can >> provide an implementation, I can try to integrate it with what I have done. >> >> Either way, it will require non-backwards compatible changes to configs >> to import the correct module or use the new names. I'm not sure the benefit >> is worth the investment, though. >> >> Let me know what you think :) >> >> Cheers, >> Jason >> >> >> >> On Fri, Apr 1, 2022 at 7:31 AM Giacomo Travaglini < >> giacomo.travagl...@arm.com> wrote: >> >>> Congrats to Jason and to everyone who’s making this possible! >>> >>> >>> >>> About the naming, I wonder if we could provide a different python module >>> per ruby protocol. >>> >>> That would allow us to avoid prefixing in favour of something like: >>> >>> >>> $from m5.objects.mi_example import L1Cache_Controller >>> >>> >>> >>> or >>> >>> >>> $from m5.objects.msi import L1Cache_Controller >>> >>> >>> >>> Kind Regards >>> >>> >>> >>> Giacomo >>> >>> >>> >>> >>> >>> *From: *Jason Lowe-Power via gem5-dev <gem5-dev@gem5.org> >>> *Date: *Thursday, 31 March 2022 at 18:43 >>> *To: *gem5 Developer List <gem5-dev@gem5.org> >>> *Cc: *Jason Lowe-Power <ja...@lowepower.com> >>> *Subject: *[gem5-dev] Request for comments/reviews: Multiple Ruby >>> protocols in a single binary >>> >>> Hi all, >>> >>> >>> >>> For as long as gem5 has been gem5, you have had to build a different >>> gem5 binary if you want to use a different Ruby protocol. Making it >>> possible to build multiple protocols has been on the roadmap for a long >>> time (at least as long as I've been involved with the project). >>> >>> >>> >>> I'm excited to say that we've been able to do this (finally), and we >>> have a set of changesets on gerrit for review/comments feedback. >>> >>> >>> >>> There are a couple of todo items before it's merged, and a couple of >>> user-facing changes that we could not find a way to make fully backwards >>> compatible. More on this below. >>> >>> >>> >>> Let me know what you think, and let me know if there are any questions! >>> I'm excited to see this get in for gem5-22.0. >>> >>> >>> >>> Changes: https://gem5-review.googlesource.com/q/topic:all-ruby-protocols >>> >>> >>> >>> *Non-backwards compatible changes:* >>> >>> Previously each SLICC protocol used the same names for the same machine >>> time. E.g., MI_example has an `L1Cache_Controller` and MSI has an >>> `L1Cache_Controller`. These names were automatically generated from the >>> MachineType (L1Cache) + "_Controller". Now, since we want to be able to >>> compile these two protocols at the same time, we need to make sure there >>> are no (python) name clashes. So, these have been renamed to have the >>> protocol name prepended onto the machine name (e.g., >>> `MI_example_L1Cache_Controller`). >>> >>> >>> >>> For most people using Ruby, we can provide backwards compatibility. If >>> you simply instantiate the `L1Cache_Controller` in python, we can provide a >>> new factory function that does the "right" thing. However, if you inherit >>> from `L1Cache_Controller` to specialize the controller, this won't work. >>> >>> >>> >>> *The user-facing change is* if you have any local ruby protocol >>> configuration files which use inheritance with the controllers, you will >>> have to update the controller classes to use the name of the protocol >>> prepended on the controller name. >>> >>> >>> >>> We have updated all of the configurations that are in the gem5 repo. You >>> will see warnings if you use the old backwards-compatible names (including >>> with Ruby.py). >>> >>> >>> >>> The only other user-facing change (I think, reviewers, please point out >>> if I'm wrong), is that in places that `buildEnv["PROTOCOL"]` was used to >>> check the protocol that was built, you will now need to use >>> `getRubyProtocol` (also available in `m5.defines`). However, we are >>> currently supporting backwards compatibility here, but there will be no >>> warning when we drop backwards compatibility (I expect this to be in a >>> couple of releases). >>> >>> >>> >>> *To do items* >>> >>> - Correctly integrate this with scons (and the new kconfig). See >>> https://gem5-review.googlesource.com/c/public/gem5/+/58443 for a WIP >>> that needs to be updated. >>> >>> - Update the website. Assuming there are no major flaws in our >>> implementation, we will update the website soon (before the changes are >>> committed). The main updates are the two user-facing changes described >>> above, but I expect some updates to how Ruby/SLICC works as well. >>> >>> - Add another commit that checks if the protocol is in the list of built >>> protocols instead of a single protocol. I'm holding off on this one until >>> item #1 is complete. This will also include a new command-line parameter to >>> set the "main" protocol for backwards compatibility. >>> >>> >>> >>> Cheers, >>> >>> Jason >>> >>> >>> IMPORTANT NOTICE: The contents of this email and any attachments are >>> confidential and may also be privileged. If you are not the intended >>> recipient, please notify the sender immediately and do not disclose the >>> contents to any other person, use it for any purpose, or store or copy the >>> information in any medium. Thank you. >>> >>
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org
