The stores seem like trickier operations. If the value is oddly aligned you might have to write three bytes on one page and 1 byte on another. In that case you'll probably have to break the store up into 4 byte writes or do some kind of RMW.
How is this handled in x86? What happens if you take a trap the write? Could it be half done? Ali On Wed, 21 Oct 2009 16:53:54 +0100, "Timothy M Jones" <[email protected]> wrote: > 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 >>> _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
