Actually no... x86 handles this by hacking up the CPU model to dynamically generate two requests when the access is unaligned. Currently only the simple CPU model is so hacked (x86 doesn't work on O3 for a number of reasons, and this is one of them).
If unaligned data accesses are common in Power, hacking up O3 to do the same thing may be necessary to get it running there. Steve On Wed, Oct 21, 2009 at 8:05 AM, Ali Saidi <[email protected]> wrote: > > 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" > <[email protected]> > 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 <[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 > >>> > _______________________________________________ > 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
