Just to make sure your questions are clearly answered: On Wed, Oct 21, 2009 at 8:53 AM, 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? > Yes. > > 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? > The ISA should issue a single read() or write() call, which the CPU model should split into at most two requests, guaranteeing only that they do not cross a cache-block boundary. Basically just what the SimpleCPU models are already doing, though I can understand if that wasn't perfectly obvious from reading the code :-). Steve > > 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 >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
