Re: Calling a MIPS maintainer (was Re: GCC build failed formips-elf with your patch on 2002-06-18T19:37:45Z.)

[Eric Christopher <echristo at redhat dot com>]

> Okay.  Any of y'all that know MIPS assembly feel like volunteering?  :-)
> 
> I think this is what HJ was sort of trying to do with the <sgidefs.h>
> header or whatever it was called, followed by
> 
>     #if _MIPS_ISA > some_magic_number
>     use assembly
>     #else
>     do something generic
>     #endif
> 
> in config/cpu/mips/bits/atomicity.h.  Of course, anything that didn't have
> <sgidefs.h> broke, thus the patch was reverted and MIPS went back to the
> generic routines.
> 

Right, and this isn't a particularly good test atm anyhow. Another test
that will currently work is to test for __mips > 1. However, I don't
like this either for this reason:

The current situation is that all sub-cpu variants set MIPS_ISA_DEFAULT
in addition to the arch. I'm not convinced that this is a good idea and
may change it in the future since checking the "standard" ISA for
features is only a good idea if each chip does the "standard" ISA +
instructions, not subtracting some instructions.

I think a local configure test is the best bet. Try to assemble
something that looks like:

L1:
    ll     $4,0($17)
    sc     $3,0($17)

or something. If no errors, then we're fine. If it errors then we go to
something generic, e.g.

[echristo@ghostwheel /ghostwheel]$
./sourceware/builds-combined/build-mips/gas/as-new foo.s 
foo.s: Assembler messages:
foo.s:2: Error: opcode not supported on this processor: R3000 (MIPS1)
`ll $4,0($17)'
foo.s:3: Error: opcode not supported on this processor: R3000 (MIPS1)
`sc $3,0($17)'
[echristo@ghostwheel /ghostwheel]$
./sourceware/builds-combined/build-mips/gas/as-new foo.s -mips2
[echristo@ghostwheel /ghostwheel]$

> 
> For now, just to let mips-elf build again, I'll explicitly force it to
> use the generic cpu bits.  That will at least get us back to the status quo.
> 

Thanks.

-eric

-- 
I will not carve gods