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
