Re: [Patch] MIPS: mips16e machine patterns - zeb/zeh seb/seh

[David Ung <davidu at mips dot com>]

> >
> > That's because to be MIPS32/32R2/64/64R2 ASE compliant, the full MIPS16e
> > set is required, not a subset (MIPS16). I've simply made that if the
> > user gave -mips16 option for mips_isa>=32, they really mean -mips16e.
> > As in Ian's previous reply, -march=mips32 -mips16 will imply -mips16e.
> 
> Yeah, I don't like this though.  If there's a separate flag for MIPS16e,
> that's what the user should use to get MIPS16e.  I was happy with either
> (a) or (b), but this third option just seems too complicated to me.
> 
> So which is more important to you?  That -mips16 -mips32 => MIPS16e?
> Or that MIPS16e be selectable by a separate command-line option?
> 
> If the first, then I don't think there's a strong argument for keeping
> the separate -mips16e flag.  Ian mentioned the possiblity that another
> manufacturer might produce a processor that isn't a true MIPS32 or MIPS64
> implementation but that nevertheless provides full MIPS16e compatibility.
> If that happens, we can just make that processor's -march flag select
> MIPS16e, in the same way that you're doing for MIPS32 and MIPS64.

I thought Ian's original comment was that if a vendor decides to
implement MIPS32/MIPS64 with only mips16 support, we can add the option
of -mno-mips16e then (you would have to do something like -march=mips32
-mno-mips16e -mips16).  Having -march=mips32 -mips16 to automatically
choose MIPS16e is useful as existing Makefiles needn't be changed if its
already using the -mips16 switch, but now have more choice of
instructions to use.  And that's ok since all MIPS32/64 compliant cpu
have the MIPS16e set.  
While non-MIPS32/64 cpu can choose if they want MIPS16 or MIPS16e.  
If for some unknown reason, a MIPS32/64 ISA and MIPS16 ASE is
implemented, then -mno-mips16e need to be introduced.  But then it's not
really MIPS32/64 compliant anyway, and arguably shouldn't even be call
that legally.
At the moment, MIPS32/64 with MIPS16 is not possible (to be extreme, we
could give a warning msg for this case, urgh).
I am not against either (a) or (b), but it seems there's now an option
(c).  Though this is a bit confusing, it is what the architecture
specification defines.  What do people think?

David.