This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Paul Koning wrote:
"Dominic" == Dominic Sweetman <dom@mips.com> writes:


 Dominic> Nigel forwarded me your comments on why an assembler should
 Dominic> be passed a flag and on the basis of that flag reject
 Dominic> mnemonics from the DSP ASE:

 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.

Dominic> And Paul...

>> Agreed.

 Dominic> Which comes down to this: under what circumstances might it
 Dominic> be helpful for the assembler to reject a piece of code which
 Dominic> it could have assembled?

If you tell the compiler that it should generate code for, say, R3000,
but by some oversight you stuck in some embedded asm code with opcodes
not valid on that architecture, you want the assembler to tell you
that.  It's far bettter to get a compile time error than a crash at
runtime that may be hard to reproduce.

In other words when I tell the assembler "I'm writing code for
architecture X" I want the assembler to do TWO things:

1. Accept all constructs that are valid in X.
2. Reject all constructs that are NOT valid in X.


I was going to say the same thing, but you did it first.


Speaking as a person who works with MIPS32 without the DSP ASE every day, I would would prefer not to have to find the problems at runtime.

Just my $0.02

David Daney


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]