Thanks Andreas and Tony, I think I understand Andreas' original email AFTER reading Tony's response :-).
In addition to the two options Tony suggested (enumerated below): - 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) I would add: - Add a new "regular" command: FENCE. Have special flags to denote it as ACQUIRE/RELEASE (2) - Add a new "regular" command: FENCE. Use attributes to capture the properties of a particular FENCE command: IsAcquire, IsRelease, etc. (4,5) Any others? Also, on point (3) in Andreas' original email: I agree that Architecture specific flags are not handled very well right now. I noticed that the first 8 bits in request.hh (ARCH_BITS) are supposed to be architecture specific (according the comment at least). I wonder if those bits are sufficient to solve the problem that Andreas raises. Thanks, Marc On Thu, Aug 6, 2015 at 3:18 PM, Gutierrez, Anthony < [email protected]> wrote: > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
