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 %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
