I've compiled this on a bunch of machines and things are good, so I
say go for it.
I have one request. You messed up the indentation in readReg, can you fix it?
Please commit this ASAP.
Thanks Korey.
Nate
2008/10/2 Korey Sewell <[EMAIL PROTECTED]>:
> Implementing shadow sets for the rdpgpr a
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 PROT
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 flatte
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 i
Any update on a diff korey? We need to get this done and out the door.
Nate
On Tue, Sep 30, 2008 at 10:07 AM, Korey Sewell <[EMAIL PROTECTED]> wrote:
>> 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 u
> 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'
> 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
sai
> 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
___
> 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 purpos
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
On Tue, Sep 30, 2008 at 1:21 AM, Korey Sewell <[EMAIL PROTECTED]> wrote:
> Looking further, it seems that there has been confusion on NumIntRegs
> v. NumArchIntReg
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 impl
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 contro
> 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 th
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
> 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
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 an
> 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, Nu
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 comp
> 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.
> fi
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, 2
I'm trying to get rid of lots of compiler warnings so that things work
properly with gcc 4.3 and I encountered something that's a bug.
In src/arch/mips/int_regfile.cc
The functions readReg and setReg both check to make sure that "intReg
< NumIntRegs" and do something special if it is. The confus
21 matches
Mail list logo
