Hi Tim, I think x86 handles this by micro-coding loads that aren't aligned.
Ali On Wed, 21 Oct 2009 12:47:49 +0100, "Timothy M Jones" <tjon...@inf.ed.ac.uk> wrote: > 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 <ste...@gmail.com> > 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 >> <tjon...@inf.ed.ac.uk>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 >>> m5-dev@m5sim.org >>> http://m5sim.org/mailman/listinfo/m5-dev >>> _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
