Thanks for the information. I've just had a quick look - I take this is all the split_addr code in TimingSimpleCPU::read/write?
I believe that unaligned data accesses may be fairly common. There is no restriction on their use. At the very least they are causing failures in several benchmarks. If I were to implement a similar thing in O3 would this be the best way to do it? I.e. should it be one store causing two requests, or split into two stores each with one request? Tim On Wed, 21 Oct 2009 16:35:32 +0100, Steve Reinhardt <[email protected]> wrote: > 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 >> -- 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
