Re: [PATCH] MIPS32 DSP instructions again

[Nigel Stephens <nigel at mips dot com>]

Eric Christopher wrote:

> > 10 new operand formats, 3, 4, 5, 6, 7, 8, 9, 0, ', :.  These
> > new DSP instructions are considered as part of the MIPS32
> > instructions, so there is no gas flag to enable or disable them.
> >    
>
> I've not looked at the rest, but I'm not sure that this part is
> acceptable. What you're saying is that these aren't part of any
> particular ASE, but also weren't part of the core description that was
> published back in 99 or so? I don't think that we should allow
> instructions to be assembled for any core that doesn't support them.
> Since, IIRC, there are extant MIPS32 parts out in the world that means
> we'll need a switch for this.
>
> Your thoughts?
>  

Hi Eric

The first version of this code did add a -mdsp option to the assembler, 
and tagged the instructions in the opcode table, but we made a conscious 
decision to remove it. Now you may insist on us putting it back again 
:-(, but I'll explain our decision first. The logic was as follows:

Historically the various MIPS ISAs and CPUs were distinguished in the 
opcode tables because they often reused the opcode space such that the 
assembler and disassembler absolutely had to distinguish between the 
differents variants. For example MIPS III reused the old MIPS I/II 
coprocessor 3 opcodes, and some CPUs from other vendors even encoded 
identically named instructions with different opcodes (e.g. madd).

However the MIPS32 and MIPS64 architectures are defined carefully and 
rigorously to avoid such opcode and name collisions. So long as an ASE 
or ISA revision is defined as part of the MIPS32 / MIPS64 architecture, 
then it will be guaranteed not to clash with any other MIPS32 / MIPS64 
ASE or ISA revision. This means that it is enough to know that you are 
assembling or disassembling code for MIPS32 (or MIPS64) to enable all of 
the ASEs, such as the DSP ASE in this case. If the programmer happens to 
use a machine instruction which isn't supported on their particular CPU 
core, then that's their mistake, and they're guaranteed to get a 
reserved instruction exception if they try to execute it. Of course they 
may also be clever enough to check at run-time which ASEs are available, 
and then choose whether or not to execute those instructions (e.g. 
inside a generic OS kernel designed to run on a range of cores with 
different ASEs).

That's not to say that the *compiler* doesn't need to be told precisely 
the ISA revision and available ASEs, because it does need to know which 
instructions it is allowed to generate - for example the SmartMIPS ASE 
adds an indexed load instruction, which the compiler can make good use 
of. It's the binary tools which, I suggest, don't need to distinguish 
the ASEs.

A final argument against labelling each and every ASE in the opcode 
tables, is that you might then argue yourself into saying that the ASEs 
also need to be recorded within the ELF header, so that the disassembler 
and debugger can decide whether or not to decode those instructions, or 
a kernel can decide whether or not to run an executable - but we're 
running out of spare bits in there! :-)

Nigel