This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] MIPS32 DSP instructions again
- From: Ian Lance Taylor <ian at airs dot com>
- To: Nigel Stephens <nigel at mips dot com>
- Cc: Eric Christopher <echristo at redhat dot com>, Chao-ying Fu <fu at mips dot com>, Richard Sandiford <rsandifo at nildram dot co dot uk>, "Thekkath, Radhika" <radhika at mips dot com>, binutils at sourceware dot org
- Date: 09 Jun 2005 12:58:51 -0400
- Subject: Re: [PATCH] MIPS32 DSP instructions again
- References: <B5B9CAE3-D2C9-11D9-BE69-003065BDF310@apple.com><1117671176.4744.67.camel@localhost.localdomain><87r7flusey.fsf@firetop.home><1117735089.22225.3.camel@localhost.localdomain><42A5B577.6080603@mips.com><1118165083.5438.5.camel@localhost.localdomain><000801c56bb9$bd9ea620$a914a8c0@MIPS.COM><1118188909.5438.74.camel@localhost.localdomain><000b01c56bc3$d2a06950$a914a8c0@MIPS.COM><1118199844.4731.2.camel@localhost.localdomain><42A86366.4010201@mips.com>
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).
I disagree. I think it is appropriate and useful for the assembler to
be able to correctly accept or reject instructions based on the
command line options and .set options.
I agree that the disassembler doesn't need to know.
> 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! :-)
I think using a .note section would be appropriate, but I don't feel
all that strongly about it.
Ian