Re: load_unaligned() and "uld" instruction

[Ralf Baechle <ralf@oss.sgi.com>]

On Mon, Sep 25, 2000 at 02:36:39PM -0700, Jun Sun wrote:

> I looked at my problem again, and it turns out that it was caused by
> "-mips2" compiler option.  If I use "-mips3", the complain goes away,
> which seems to make sense - assuming "uld" and "usw" are introduced in
> mips III.
> 
> This actually brings another question (which I thought I have posted
> before).  Take a look of arch/mips/Makefile, you will find most CPUS
> uses -mips2 compiler option.  While -mips2 is safe, it cannot take
> advantages of "uld" etc.  Is there any reason that we don't want to use
> -mips3, at least for some of the later CPUs?

You cannot use any kind of 64-bit operation for the 32-bit kernel except
for the $zero register.  This is because all exceptions as far as they
store / restore the integer registers at all will only deal with the lower
32-bit of the registers.  In other word any interrupt will corrupt the
upper 32-bit bit of gp registers.

Back in history I tried to enable the use of the full 64-bit register in
the kernel - it ended up ugly as hell, especially because we still want
to be able to share most of the code with the R3000.

> If we have to use "-mips2" option, is there a clean way which allows us
> to "uld/usw" instructions (instead of manually twicking the compilation
> for each file that uses them)?
> 
> Another question is that in the same file most CPUs will take another
> compiler option such as "-mcpu=r8000", in which case the cpu model
> usually does NOT correspond to the actual CPU.  Why is that?

-mcpu=<somecpu> chooses what CPU gcc will schedule instructions for.  No
matter what value you choose for <somecpu> the code will run on all CPUs.
-mips<n> chooses which ISA level gcc will generate code for; that code
won't run on CPUs with a ISA level less than <n>.

  Ralf