Home Original page

[PATCH] MIPS32 DSP instructions again

Paul Koning pkoning@equallogic.com
Thu Jun 9 17:13:00 GMT 2005 
>>>>> "Ian" == Ian Lance Taylor <ian@airs.com> writes:

 Ian> Nigel Stephens <nigel@mips.com> writes:
 >> 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).

 Ian> I disagree.  I think it is appropriate and useful for the
 Ian> assembler to be able to correctly accept or reject instructions
 Ian> based on the command line options and .set options.

Agreed.

 Ian> I agree that the disassembler doesn't need to know.

The disassembler right now does know about instruction sets, and
interprets ASE/ISA specific bit patterns according to what it's told.
If I take a bit of mips64 code full of LDs and such, and feed it to
objdump -d -mmips:3000 I get something rather different from what I
wrote, which makes sense.

       paul
More information about the Binutils mailing list