Re: [m5-dev] Confusing MIPS code

2008-10-03 Thread Korey Sewell
Since shadow sets is more/less an optional part of the architecture, I would rather have some process where if shadow sets is ON then we do the flattening thing, but if it's OFF we just do the regular process without the flattening overhead. On Fri, Oct 3, 2008 at 12:43 AM, Gabe Black [EMAIL

Re: [m5-dev] Confusing MIPS code

2008-10-02 Thread Korey Sewell
Implementing shadow sets for the rdpgpr and wrpgpr is going to take more than regfile and decoder changes. Those instructions mean read/write from/to the previous shadow set, so that means I would need to edit the threadcontext (tcBase()) or execcontext to include functions that would allow the

Re: [m5-dev] Confusing MIPS code

2008-10-02 Thread Gabe Black
This is probably the best thing to do in the short term, but in the long term you don't need to change the threadcontext to access other sets of registers. SPARC does something pretty similar with register window manipulating instructions which access multiple windows. You'd use register

Re: [m5-dev] Confusing MIPS code

2008-09-30 Thread Gabe Black
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

Re: [m5-dev] Confusing MIPS code

2008-09-30 Thread nathan binkert
Looking further, it seems that there has been confusion on NumIntRegs v. NumArchIntRegs on Jaidev's implementation. Can we talk to Jaidev? Do you have his e-mail address? I'd like to get this figured out. Do they have updated code perhaps? Wrgpr and Rdgpr are functions for the sole purpose

Re: [m5-dev] Confusing MIPS code

2008-09-30 Thread nathan binkert
FYI: I have gcc 4.1 on my system so I'm assuming that whoever is testing for gcc 4.3 compatibility with knock this quick patch out Unfortunately, it's not so quick re my previous e-mail. And if you correct it for 4.1, it will probably be correct or 4.3. Nate

Re: [m5-dev] Confusing MIPS code

2008-09-30 Thread Korey Sewell
Can we talk to Jaidev? Do you have his e-mail address? Sure, I can email him... I'd like to get this figured out. Do they have updated code perhaps? I'm pretty sure that is the appropriate fix. Full coverage of the shadow-sets in regression testing wasnt available previously so like I said

Re: [m5-dev] Confusing MIPS code

2008-09-30 Thread nathan binkert
I'm pretty sure that is the appropriate fix. Full coverage of the shadow-sets in regression testing wasnt available previously so like I said before this is a case of implementing every instruction on the MIPS32 ISA specification for possible future cases then this code works and now it's

Re: [m5-dev] Confusing MIPS code

2008-09-29 Thread Ali Saidi
Unless Korey can come up with a fix by tomorrow, I vote to put in a panic() (not an assert) so we can create a stable release that works with gcc 4.3. Ali On Sep 24, 2008, at 9:43 AM, nathan binkert wrote: oh i think I see now... This shadow set code and DSP/MT was done by myself and

Re: [m5-dev] Confusing MIPS code

2008-09-29 Thread nathan binkert
Unless Korey can come up with a fix by tomorrow, I vote to put in a panic() (not an assert) so we can create a stable release that works with gcc 4.3. I agree with this, but I'd love to see an actual fix. I'd rather not see MIPS rot away. Nate

Re: [m5-dev] Confusing MIPS code

2008-09-29 Thread Korey Sewell
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

Re: [m5-dev] Confusing MIPS code

2008-09-29 Thread nathan binkert
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

Re: [m5-dev] Confusing MIPS code

2008-09-29 Thread Korey Sewell
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

Re: [m5-dev] Confusing MIPS code

2008-09-24 Thread Korey Sewell
How's it a compiler error to do a unsigned integer comparison? In the MIPS ISA, I believe a bunch of registers were added into int reg. file to maintain add in the MIPS MT /DSP compatibility. However, this looks to be some shadow set register compatibility code that got added... On Wed, Sep 24,

Re: [m5-dev] Confusing MIPS code

2008-09-24 Thread nathan binkert
How's it a compiler error to do a unsigned integer comparison? That's not the error. The error is that in the else clause, it's guaranteed that the array access will be beyond the end of the array. That's the error. In the MIPS ISA, I believe a bunch of registers were added into int reg. file

Re: [m5-dev] Confusing MIPS code

2008-09-24 Thread Korey Sewell
oh i think I see now... This shadow set code and DSP/MT was done by myself and some of the MIPS guys... Anyway, the issue is probably that the value for NumShadowSets or something is set to 0 or a wrong value causing the bad access. I'll see if I can look into it... But this is an actual

Re: [m5-dev] Confusing MIPS code

2008-09-24 Thread nathan binkert
oh i think I see now... This shadow set code and DSP/MT was done by myself and some of the MIPS guys... Anyway, the issue is probably that the value for NumShadowSets or something is set to 0 or a wrong value causing the bad access. Well, if you look at the code in isa_traits.hh,