Thanks for this clarification, Andreas. We were mostly confused by the flags, cmd, and attributes because - as you pointed out - there seems to be a lot of overlap with no clear division between the three objects. I think this patch is going in a good direction.
For our particular case it seems we have a few options. Use regular read/write commands but have special flags denoting them as ACQUIRE/RELEASE (2). Or we could have multiple commands for the each of the sync/serializing ops with attributes denoting them as IsSynchornizing or IsSerializing etc (4,5). Are those suitable options? Are there other options? -----Original Message----- From: gem5-dev [mailto:[email protected]] On Behalf Of Andreas Hansson Sent: Thursday, August 06, 2015 4:43 PM To: gem5 Developer List Subject: Re: [gem5-dev] extending request with more attributes Hi Marc (et al), Have a look at http://reviews.gem5.org/r/3004/ for addressing (5) in my previous mail. Andreas On 06/08/2015 10:41, "gem5-dev on behalf of Andreas Hansson" <[email protected] on behalf of [email protected]> wrote: >Hi Marc, > >I would suggest the following (again, this is up for discussion): > >1. Request flags should the kind of properties that we would have >associated with page-table entries. I am thinking memory attributes >like uncacheable, strictly ordered, secure, etc. > >2. Request flags could also be used to distinguish packets of specific >types, where ‘normal’ packet commands like read/write are used, but we >want to be able to single out what the ‘reason’ is. Prefetch, PT walks, >Fetch, etc. > >3. We should try and sort out the current use of CLEAR_LL, LOCKED_RMW, >LLSC, MEM_SWAP, and MEM_SWAP_COND. In my view these should not really >be request flags, because we have specific packets to represent these >actions. Also, most of these are ArchSpecific and should go in the >ArchSpecific flags. Perhaps we just need to figure out a better way to >do this. > >4. Packet attributes should be common attributes shared by multiple >families of packet commands. Good examples are ‘NeedsResponse’, >‘IsRead’, ‘NeedsExclusive’ etc. > >5. Packet attributes should not be introduced if they only apply to a >single request/response. Thus, I think we should remove IsSWPrefetch >and IsHWPrefetch as an attribute. > >Does this align with your view of the world? > >Andreas > > > >On 05/08/2015 22:30, "gem5-dev on behalf of Marc Orr" ><[email protected] on behalf of [email protected]> wrote: > >>In response to reviews http://reviews.gem5.org/r/2821/ and >>http://reviews.gem5.org/r/3003/. >> >>I was going to look at addressing this today for AMD. I'm not >>extremely familiar with the organization of the request flags, packet >>commands, packet attributes, and packet flags. That said, I was under >>the impression that the request is supposed to capture information >>that exist at the instruction level. To me, acquire and release are at >>the instruction level (not a spurious command between two memory >>controllers like flush command). >> >>Also, the 32 bits that we have to work with in the request seems >>rather small. Especially, when you consider that it needs to capture >>all of the possible attributes for a memory request across all of the >>different ISAs... >> >>How would armv8 ldra and strl instructions convey to the cache >>hierarchy acquire/release attributes from the instruction (if it were >>necessary)? >> >>Thanks, >>Marc >>_______________________________________________ >>gem5-dev mailing list >>[email protected] >>http://m5sim.org/mailman/listinfo/gem5-dev > > >-- 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. > >ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >Registered in England & Wales, Company No: 2557590 ARM Holdings plc, >Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in >England & Wales, Company No: 2548782 >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev -- 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. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ 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
