> > > Ralf, before the perfect solution is found, the following patch makes
> > > the gcc complain go away. It just use ".set mips3" pragma.
Which, as Ralf correctly observes, will generate code that will
crash on 32-bit CPUs, and apparently do entirely the wrong
thing for other reasons on the 64-bit ones.
> > It's still perfectly broken. Uld is a 64-bit instruction meaning you
still
> > could get into problems with register corruption or even reserved
instruction
> > exceptions on 32-bit cpus. Not too mention that nobody did notice that
> > the constraints of the inline assembler were broken for all access sizes
> > plus a cast that would have cut off the upper 32 bit of a 64 bit access
in
> > any case. That's fixed now.
> >
>
> With my limited wisdom, I am totally confused by this paragraph.
>
> I think you mentioned a couple of times before where 64-bit instructions
> corrupt registers in 32-bit mode. I think I have done that before with
> R5000 R4500. I did not notice any corruption. What exactly is the
> corruption you are referring to?
Uld is an unaligned doubleword load macro that should generate
a LDL/LDR sequence if MIPS III, IV, V or MIPS64 is enabled in
the compiler/assembler. That sequence should either execute
correctly or deliver a reserved instruction exception. No
MIPS-compatible CPU should silently fail or corrupt registers.
> With the second half, are you saying the "cut-off-upper-32-bit" bug
> actually hides the register corruption problem? If so, maybe we need
> the "cut-off-upper_32-bit" bug for the 32-bit MIPS tree.
This is a joke, right?
Kevin K.
|