The delay slots in MIPS are a simpler version of what's in SPARC and should work with no problems. If there are any problems, I'm 99% sure they'd be easy to fix.
Gabe Korey Sewell wrote: > Looking further, it seems that there has been confusion on NumIntRegs > v. NumArchIntRegs on Jaidev's implementation. > > Wrgpr and Rdgpr are functions for the sole purpose of having shadow > set register compatibility. > > Those functions need to take whatever the source register value and > then use a control register to compute which shadow set to get to. The > shadow set needs to be computed by getting the offset and adding it to > the source register value. > > So in short, change that NumIntReg to NumArchIntRegs in both the rdgpr > and wrgpr instructions and we should be fine. > > In terms of testing the result, well, I'm not sure every single > instruction gets stressed in the MIPS Linux boot. This implementation > was to get every single instruction in the MIPS ISA 32 specification > as "MIPS-compliant" as possible but there isnt a full suite of test > cases that I can pull from. The tests that were ran to verify this > code were MIPS in-house regressions so I couldnt possibly get those. > > What has to happen is that the other regressions we have just need to > be compiled for MIPS and we should be good to go. Things have changed > in O3 so I cant say for sure it would work given how delay slots must > work for MIPS in O3. However, it's kind of a time-sync in terms of > "what's the next thing to do" because as well as the regressions for > MIPS, there is also the inorder model, O3 compatibility and there is > also inserting a booting MIPS Linux code into the tree. > > On Mon, Sep 29, 2008 at 5:48 PM, nathan binkert <[EMAIL PROTECTED]> wrote: > >>> OK, so I agree that the else clause is looking superfluous and with >>> the comment "probably written by ..." then it definitely has no place. >>> >>> So if the compiler warning is caused by writing past the out of bounds >>> value then the fix would be to just delete the else clause since >>> inside of the original if condition it seems that shadow sets have >>> been taken care of. >>> >> Well, the problem is that if you look at the wrpgrp and rdpgpr code in >> the decoder.isa, that code will generate requests that are out of >> bounds if SRSCtl_PSS is ever greater than zero. Furthermore, the code >> in readReg and setReg can also generate an out of bound reference. >> Look where NumIntRegs is multipled by currShadowSet. If you get into >> this part of the code and currShadowSet is nonzero, then it will also >> be out of bounds. I'm guessing that the right thing to do (in >> addition to removing the else clause) in both cases is replace >> NumIntRegs with NumIntArchRegs. However, I did not write this code, I >> don't know this code, and I don't have any way of testing the result. >> >> >>> As for MIPS regressions, I am wondering about those myself since no >>> doubt this has been tested with more than a "hello world" app and the >>> work left off with MIPS close to booting Linux. >>> >> It would be wonderful if you could either hunt down some regressions >> or create some. Is there more code at MIPS that we could get? >> >> Nate >> _______________________________________________ >> 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
