These patches look good to me. I tried the changes on a few of my compiled MIPS SPEC2000 binaries and all the TLS stuff seems to work alright.
I like how you put the thread pointer in a register...this is a much cleaner solution than my own. Thanks, Gabe. On Tue, Dec 29, 2009 at 10:11 PM, <[email protected]> wrote: > These MIPS patches clean up two generic issues (rdhwr decoding, MIPS ISA > object CPU pointer), improve the initial stack frame, and add support for > thread local storage. > > The initial stack frame change was essentially moved over by Matt (originally > from SPARC? Alpha?), and is currently credited just to "Matt". Please let me > know what you want the commit to say. I removed your comment about > generalizing argsInit and generalized it like SPARC's version. > > Instead of putting the thread local storage pointer in the various contexts > and routing it through all the CPUs and *Insts, contexts, etc., I added a new, > artificial control register to MIPS. I used a register to associate it with a > thread, but to the simulated code it should look like it's managed in software > like it is in the Linux kernel. In SE mode the difference is basically > irrelevant. > > Thes changes do -not- allow the fp-add-mips or add.d.mips64el test programs > sent out by Matt and Vince to run, but do let them get farther before > crashing. Right now it runs into the assert in fpNanOperands Matt identified > earlier. > > To fix fpNanOperands, I think we're going to have to significantly change how > that's set up. Right now, it goes through all the operands of the instruction > and checks each one for nan assuming it's single precision. It also assumes > it's floating point, I think, which seems a little dangerous. What will > probably need to happen is to check each argument more explicitly, taking into > account whether it's half of a double, etc. I'm not all that familiar with FP > in MIPS or, off hand, how nan is encoded, so I could be wrong. > > After that we'll need the fpFilterDoubles function Matt moved over, and I > think by that point double operands will be basically straightened out. As a > nice side effect we should be able to run more modern binaries. > > Gabe > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > -- Cheers, Matt _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
