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" <gem5-dev-boun...@gem5.org on behalf of andreas.hans...@arm.com> 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" ><gem5-dev-boun...@gem5.org on behalf of marc....@gmail.com> 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 >>gem5-dev@gem5.org >>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 >gem5-dev@gem5.org >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 gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
