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>.