Hi All, My group would also be interested in this feature, and have been discussing something similar to Yan's suggestion.
Our use case would be for implementing architectural features of AArch64 which require extensions to memory packets which are optional, or which would not be applicable to all ISAs. We would favour adding the extension mechanism to the Request class rather than the Packet class because some use cases require adding metadata during the translation process. Our current idea was to add a map of key -> BaseExtensionPtr pairs to the Request, and an API to access these items. Clients could then implement a ConcreteExtension class and insert instances into the request as required. Perhaps we should make a Jira ticket to discuss this feature in more detail? Richard. > This is to mimic systemc's protocol extension mechanism, where you can add > side channel info to a transaction. Sender state is more for keeping track > of information the sender needs related to a particular packet, rather than > to send additional state down the line to other consumers. For instance, > there is no identifier in a SenderState, since it is assumed when you get a > response back, your SenderState is at the top of the stack. There would be > no real way to determine which SenderState matched a particular extension > except dynamic casting everything to search for a particular type, and even > then you could have false hits from extension subclasses. > > > Gabe > 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
