This is relatively hard to do if you have a cracked store, but a fused double-wide load. Usually, these partial store-to-load-forwarding (STLF) cases are not supported and will serialise the execution and will then forward through the cache (or the write-buffer).
If both store *and* load are cracked into separate uops, then the forwarding will just work as is: store_A -- forward -> load_A store_B -- forward -> load_B -- Sincerely, Stephan Stephan Diestelhorst Staff Engineer, ARM Research - Systems +44 (0)1223 405662 On Friday 13 March 2015 03:32:57 Vanchinathan Venkataramani wrote: > Hi Mitch > > Thanks a lot for your reply. > > In my case there are two stores (ready but not committed) which have all the > data required by ldrd. So I'm not sure how I can merge the data from both > these stores and forward it to the load. > Thank you once again > > On Fri, Mar 13, 2015 at 11:31 AM, Vanchinathan Venkataramani > <dcsv...@nus.edu.sg<mailto:dcsv...@nus.edu.sg>> wrote: Hi Mitch > > Thanks a lot for your reply. > > In my case there are two stores (ready but not committed) which have all the > data required by ldrd. So I'm not sure how I can merge the data from both > these stores and forward it to the load. > Thank you once again > > On Thu, Mar 12, 2015 at 10:21 PM, Mitch Hayenga > <mitch.hayenga+g...@gmail.com<mailto:mitch.hayenga+g...@gmail.com>> wrote: > Here's how o3 would work in this case. The relevant code is in > src/cpu/o3/lsq_unit.hh (in the "LSQUnit::read" function) around line 640. > The code in the backend explicitly works on micro-ops, so each load/store > micro-op will get it's own LSQ entry. If both the ldrd and strd are > cracked, then nothing special needs to happen. Each load micro-op will > iterate through the store queue looking to see if any store has the > required data. > If however, we don't crack the ldrd, but do crack the strd... Then no store > will have the full 8 bytes of data needed for the load to complete. > Currently this will cause o3 to detect a "partial forward" from a store. > The load is then not allowed to complete and will have to re-execute later > once the store has committed. o3's LSQ does not assume it can merge > multiple store entries together to satisfy a larger load. > > On Thu, Mar 12, 2015 at 5:05 AM, Andreas Hansson > <andreas.hans...@arm.com<mailto:andreas.hans...@arm.com>> wrote: I must > confess I am not too familiar with how the various CPUs accomplish this. > Hopefully someone else is able to help. > Andreas > > From: Vanchinathan Venkataramani > <dcsv...@gmail.com<mailto:dcsv...@gmail.com>> Reply-To: gem5 users mailing > list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Date: Wednesday, 11 > March 2015 09:22 > To: gem5 users mailing list > <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Subject: [gem5-users] > Forwarding data from strd to ldrd > > Hi Andreas > > I'm looking into strd and ldrd instruction on gem5. > > ldrd reads eight bytes of data into two registers, while strd writes the > value from two registers into memory. > In gem5, strd in divided into multiple micro instructions, each writing four > bytes of data. A younger ldrd might have to get the data directly from two > micro store instruction. > It will be really helpful if you can provide some pointers on how ldrd is > able to get the date from the older strd micro instructions in gem5. > Thanks in advance. > > -- 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-users mailing list > gem5-users@gem5.org<mailto:gem5-users@gem5.org> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org<mailto:gem5-users@gem5.org> > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > -- 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-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
