[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