MIPS CPU names as provided to/by gas

[Chris G. Demetriou]

Anders Norlander <anders.norlander@synergenix.se> writes:
> > One reasonable thing might be to have CPU_4K translate back to "4Kc".
> Yes, that seems like a reasonably way to do it.

For now in my development tree, it translates back to mips32-4kc, but
all of the obvious variants are accepted.


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

yeah, oops, fingers got ahead of brain.  (I knew that -- if you look
at my company's web site, you might guess that i spend a lot of time
thinking about MIPS processors.  8-)

"at least several" companies have mips32 processors coming down their
pipes.


In addition to the processor naming thing, mips64 provides a different
ball of pain:  "Hey, I want to configure a mips64-elf toolchain!"
"Oh, you mean a MIPS3 toolchain, right?"  "No, I want MIPS64!"  "Well,
in our world 64 means 3!"  8-)


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

Yup.  There are some annoyances with that, though, e.g. mips32 CPUs
can define extensions, then you've got the ISA with the extension and
the extension to that, etc.

Also, there's the fact that MIPS considers these first-class ISAs from
what I can tell.  8-)


> 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 don't think that anybody's doing that.  I think the only reasonable
thing to do is get new definitions out and in general use out as
quickly as possible, and set a de facto standard.

To be honest, if you want potential for conflicts, look in the elf
flags field.  *sigh* That's a huge mess, and should be sorted out
eventually.  IIRC, from the discussion on the gcc(-patches?) list a
bit ago, there are already conflicts there between the GNU definitions
and the SGI ones.


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

I'd certainly like to avoid conflicts, yes.  Do you have any pointers
to what other (non-"GNU") vendors are doing with the arch bits?  or
good contacts into vendors to find out?

However, in some sense, we're staking out new ground here, and so
there's some inherent risk.


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

I'd say "probably yes" to that.  I do kind of wonder if it's declaring
a fake "generic mips32 CPU," which can be used for all CPUs which
don't extend the MIPS32 spec in vendor-specific ways.



To be honest, I'm just glad to see some signs of life re: MIPS
support.  (And, by the way, I don't mean to belittle your changes -- I
was quite glad to see them go in, and the fact that they did is a fair
part of what's spurred me to be so active here in the last few days.)


chris