Dear all, I've delved into the problem of adding alignment faults to PowerPC but it's a bit more difficult than I first thought.
The Power ISA book states that instructions must be word aligned. All other accesses can be unaligned. I.e. there are no alignment restrictions at all for loads and stores. This is now causing me problems in the cache when I try to do an unaligned store that crosses a block boundary. I've looked at other ISAs but they don't seem to have the same problems. I'm thinking that the fix should be to split the store (or load) into two memory requests, one for each of the cache lines to access. My question is - where is the best place to do this? In LSQUnit::insertStore would be the easiest place, but is that the correct place for it? However, since this is Power specific, maybe it should be handled within the code for this ISA only? Any thoughts on this would be much appreciated before I go hacking away through the code. Thanks Tim On Mon, 19 Oct 2009 18:04:12 +0100, Steve Reinhardt <[email protected]> wrote: > Hi Tim, > > That assertion is just letting you know that it doesn't make sense to > translate a request that crosses a page boundary. I'm guessing that in > our > other RISC ISAs we check alignment first, so you get an alignment fault > before you even try to translate the access. The alignment fault will > then > be properly ignored if the instruction turns out to be misspeculated. > > Steve > > On Mon, Oct 19, 2009 at 7:10 AM, Timothy M Jones > <[email protected]>wrote: > >> Hi everyone, >> >> I'm getting an assertion failure in the top of >> PageTable::translate(RequestPtr req) when running one of my PowerPC >> binaries on O3CPU. This is the offending assertion: >> >> assert(pageAlign(req->getVaddr() + req->getSize() - 1) >> == pageAlign(req->getVaddr())); >> >> If I comment this out and put in a DPRINTF, it turns out that the >> problem >> is this: >> >> 39789018: system.cpu.iew.lsq.thread.0: Executing store PC 0x1002fb38 >> [sn:67277] >> 39789018: global: RegFile: Access to int register 57, has data >> 0xffffffff >> 39789018: global: RegFile: Access to int register 232, has data 0x9 >> 39789018: global: Would fail assertion in PageTable::translate >> 39789018: global: Couldn't Translate: 0xffffffff >> 39789018: system.cpu.iew.lsq.thread.0: Fault on Store PC 0x1002fb38, >> [sn:67277], >> Size = 0 >> >> Later on, this store gets squashed because of a branch misprediction. >> >> Should this assertion be failing, even for speculative instructions? If >> so, then I'm guessing that I've got a problem with the store being >> scheduled too early. If not, then is it safe to remove or modify the >> assertion to account for speculation? >> >> Thanks >> Tim >> >> -- >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
