Re: MIPS CPU names as provided to/by gas

[Anders Norlander <anders dot norlander at synergenix dot se>]

On Tue, Oct 10, 2000 at 04:43:37PM -0700, Chris G. Demetriou wrote:
> So, as some of you who follow the MIPS community might have recently
> noticed, MIPS has recently released information about a family of of
> processors, the MIPS32 4K family.
> 
> The current variants are the 4Kp, 4Kc, and 4Km.
> 
> The recent changes to add 4K support to binutils added recognition of
> those names, so that (depending on circumstance) they map to either
> CPU_4K or CPU_MIPS32.  The function to provide a name for the string
> CPU_4K, however, provides "4K".
> 4K is, of course, used as shorthand currently for "4000" and produces
> CPU_R4000.
> Given that 4K has been an acceptable alias for R4000 for a Long Time,
> I'm wondering what the right solution to this is.
> 
> One reasonable thing might be to have CPU_4K translate back to "4Kc".
Yes, that seems like a reasonably way to do it.


> Another, probably more reasonable based on the MIPS naming convention,
> is to actually name the MIPS32 4K parts as "MIPS32_4K" and
> "MIPS32_4Kx"
> 
> 
> Comments would be appreciated.  I am, of course, willing to code any
> reasonable solution that's suggested.
> 
> Note that this is not going to be a one-time problem: MIPS already has
> a MIPS32 5K on its roadmap, and, of course, 5K conflicts with the
> existing accepted names for R5000.  8-S
The 5K is even MIPS64.

> 
> chris
> 
> p.s. The existing addition of MIPS32 support is... somewhat
> incomplete.  It treats MIPS32 as a CPU variant, and that is simply not
> correct.  It is an ISA, just like MIPS-I - MIPS-V, and as such will
> reasonable be extended by vendors just like they are.  However, even
> assuming that that were reasonable as a temporary measure, MIPS32 is
> actually "MIPS-II plus stuff," not "MIPS-I plus stuff" as seems to
> currently be coded.  I.e. when you say -mips32, you really really do
> mean MIPS32 ISA, or, failing that, you mean MIPS-II plus a few
> instructions.  I'll be providing some patches before too long to make
> it a real ISA.
Yes, the support is a bit incomplete. It is, however, easier to treat 4Kc
as CPU variants supporting ISA 2 plus some extensions. You'll have to patch
bfd to support MIPS32 as an architecture. You'd also have to recognize as
an architecture in ELF.

I'm unsure if somebody is maintaining a standard for the MIPS arch field in ELF.
CVS binutils defines E_MIPS_ARCH_[1-4], while some toolchains add encode MIPS-5
as 0x40000000 (is there a -mips5 chip in production/use?) and add MIPS32/64 as
0x50000000 and 0x60000000. It would be a good thing to avoid conflicts here
if code compiled with one tool indicates that it is one arch, while another
tool interprets it as something else.

I'm not arguing that MIPS32 should not be treated as an architecture rather
than a variant, I just want to make sure no conflicts arise.
But if we treat MIPS32 as an ISA we can avoid the CPU_* naming issue, so that's
probably a good thing. 4Kc should probably be the default when -mips32 is
specified.

Regards,
Anders