I've observed that with other loads closer to the store. But this one is not the case.
-- Eberle A. Rambo. Mastering in Computer Science System Design Automation Lab (LAPS) and Interdepartmental Core of Microelectronics (NIME) Department of Informatics and Statistics (INE) Federal University of Santa Catarina (UFSC) On Thu, Apr 7, 2011 at 10:43 AM, Korey Sewell <[email protected]> wrote: > The O3 model does have load-store forwarding, so yes, if you have a > store to A in the LSQ and another load comes to that same address A > while the store is still in the LSQ, then the load can save time and > just pull the data from the LSQ instead of going out to memory. > > I'm not sure if this is what you are observing or not. > > On Thu, Apr 7, 2011 at 9:37 AM, Eberle <[email protected]> wrote: > > Hi there, > > > > I've been facing a situation that I suppose it shouldn't happen. > > Using the O3 model and SPARC ISA, in the middle of the execution there > are > > some memory operations: Store to address A followed by other accesses to > > other addresses and then a Load to address A. > > What happens is that this Load is being somehow flagged as completed > before > > the Store, but reading his data though. > > I've checked in the Memory Dependency Unit and some other related units > but > > there was nothing I could do there that would change that behavior. And I > > know that when something like that is detected in the LSQ, it returns a > > fault, squashes, etc. > > > > As far as I know, the O3 model implements the Alpha Memory Model, and the > > reordering between memory operations to the same address is not allowed > > (except in some aggressive implementations, which I think it's not the > > case). > > Is this normal and I'm missing something? Or it really shouldn't happen? > > > > > > Thanks in advance, > > > > -- > > Eberle A. Rambo. > > System Design Automation Lab (LAPS) and > > Interdepartmental Core of Microelectronics (NIME) > > Department of Informatics and Statistics (INE) > > Federal University of Santa Catarina (UFSC) > > _______________________________________________ > > m5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/m5-dev > > > > > > -- > - Korey > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
