In the simple CPU, the requests are all translated before any are sent, so you can't have something half in the memory system and then take a fault on it. I don't know exactly how that would map to O3. I believe it's fine to do 3 bytes and 1 byte as two requests since they only have to avoid block boundaries, not necessarily be aligned on size boundaries. That's what x86 does.
Ali Saidi wrote: > 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 > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
