Yeah, I'd guessed that's what it was. I tried to implement my second approach and that didn't work out, so I tried my third approach and that did.
Now I need to teach O3 how to handle variable instruction lengths and more complex microcode, and I've rediscovered O3 does its decode in fetch. It's doing that, I think, to detect unconditional branches and other really easy to decode in Alpha instructions at the time it does branch prediction so it gets a more intelligent answer. For SPARC, I put the macroop unpacking right there so all the instructions leaving decode (which is really in fetch) are actually going to get executed. The macroops are used up and then discarded without entering the rest of the system. That works when you've got a fixed size, fairly short, straight line run of microops, but it going to be a little messier for x86. I'd like to pull the decode into the actual decode stage, but then that would disrupt what Alpha is doing with these early decode bits. I haven't thought about it enough to determine if there's a problem, but if anyone wants to throw in their two cents as far as suggestions or constraints feel free. Gabe nathan binkert wrote: > Basically, when there's a translation fault, some parts of the > instruction (the opcode, and Ra) need to be stored in a status > register so that PALCODE can use it to figure out exactly what > happened in the fault. I put a file on daystrom called > /tmp/164hrm.pdf. Section 5.2.6 details the register. > > Nate > > > >> Hi Alpha experts. I'm working towards getting x86 to run in O3, and >> I'm running into a minor hangup having to do with MachInsts and >> ExtMachInsts that I won't bother to go into. I could nullify the problem >> and also simplify some code if I can eliminate this line in Alpha's >> fault code >> >> http://repo.m5sim.org/m5/file/c76a14014c27/src/arch/alpha/faults.cc#l152 >> >> which grabs some bits out of the MachInst and sticks them in some >> register. Could someone please tell me what those bits are? I'd like to >> see if I can figure out a different way to derive them. Failing that, >> I'm hoping to make getInst pull out the ExtMachInst directly from the >> faulting StaticInst somehow instead of it being stuffed into the >> ThreadState or similar object and retrieved later. Failing -that-, I'll >> probably need to figure out a good way serialize X86's ExtMachInst >> structure generically, without the CPU having to know it's not a built >> in data type. >> > _______________________________________________ > 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
