RFC: MIPS paired single vector support

Nigel Stephens nigel@mips.com
Mon Aug 16 17:11:00 GMT 2004

cgd@broadcom.com wrote:

>At Mon, 16 Aug 2004 00:54:26 +0100, Nigel Stephens wrote:
>>(BTW we're going to need to rethink how ASEs and optional extensions
>>like this are encoded in the ELF file header, we're running out of
>>bits in the machine-specific flags there).
>Yes.  (I think i've mentioned this a few times in the last few years. 8-)
>If one allows for the Cygnus-style EF_MIPS_MACH, we're very nearly
>out.  (IMO, EF_MIPS_MACH isn't a great thing, but it exists.)

I had been thinking that we could snarf some bits from EF_MIPS_MACH. A 
certain range of values was "reserved" by Cygnus. I know that 
Algorithmics/MIPS used a few too. But maybe when the value is outside of 
the "reserved" ranges it could be used to give us some extra ASE bits - 
that's on the (perhaps rather hopeful) assumption that in the 
MIPS32/MIPS64 world we're not going to see so many incompatible 
extensions to the instruction set.

>Ideally, it would be possible to come up with something compatible
>with what SGI has done, too.

What is that? Do you mean the .MIPS.options section? We could consider 
extending it with some new "ODK" tags to hold CPU type (PrID value?) and 
ASE information. That sort-of fits in with Daniel's suggestion too.


More information about the Gcc-patches mailing list