Re: [Fwd: Re: [PATCH] MIPS32 DSP instructions again]

[Richard Sandiford <rsandifo at nildram dot co dot uk>]

Eric Christopher <echristo@redhat.com> writes:
>> The MIPS DSP architecture manual uses the $ac syntax, it's also been 
>> used by other toolchain companies who have updated their assemblers to 
>> support the DSP ASE, and there's now quite a significant amount of DSP 
>> assembler code written by various parties which will be using $ac. I'd 
>> prefer it if we could stick with $ac but, if you insist, then would 
>> supporting both $ac and $acc as aliases be acceptable?
> [...]
> Yes, you can have $ac as an alias.

You mean we should still acccept $accX as well?  If so, I think that's
just going to lead to confusion.  

I tend to think the MIPS tools are complicated enough as it is.  Having
two names for something would just make them even more so.  For example,
would you require there to be an objdump/disassemly flag to select
between "$accX" and "$acX" names?  Should gdb accept both names, and
have an option for choosing between "$accX" and "$acX" in things like
the "info reg" output?  If so, then everything gets more complicated.
If not, then I expect users of the non-canonical names are going to
either (a) be confused or (b) learn to stick with the canonical names.

If the official docs, other tools, and recommended usage all say "$acX",
is there really any benefit in accepting "$accX" as well?  Sure, some
other architectures use "accX"-like names, but other architectures also
give their integer registers names like "$rX" or plain "rX".  I don't
see that as any reason for MIPS assemblers to accept those names too.

At the end of the day, you need to know the assembly language of
the target you're coding for.  And from what I've seen of the DSP
instructions, remembering to call the registers "$acX" is probably
going to be the least of your worries. ;)

Richard