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

[Paul Koning <pkoning at equallogic dot com>]

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

 Dominic> Ian Lance Taylor (ian@airs.com) writes:

 >> > Which comes down to this: under what circumstances might it be
 >> helpful > for the assembler to reject a piece of code which it
 >> could have > assembled?
 >> 
 >> In general, it is better to get a compile-time error than a
 >> run-time error.

 Dominic> Depends whether it's a real one, of course.

Yes, I would certainly submit bug reports for incorrect error
messages.

 >> For example, suppose some library is written to use the new
 >> instructions.  Suppose it's a portable library, for various
 >> processors.  I get the source code for that library, and I compile
 >> it with the options appropriate for my processor.  Unfortunately,
 >> there is a bug, and the library uses an asm statement with an
 >> instruction which is not supported on my processor.  I would
 >> prefer to get a compile-time error rather than a run-time error.

 Dominic> I see where you're coming from.  But if your configuration
 Dominic> was screwed up you would be quite likely to send the wrong
 Dominic> flag to the assembler too :-(.

Then I would fix the bug that caused the wrong flag to be passed.

 Dominic> Perhaps I'm from an old school, but I do really hate
 Dominic> programs which could have given you some useful output, but
 Dominic> second-guess you and give you an error message instead.
 Dominic> There are always corner cases where you're doing bizarre
 Dominic> things (running DSP instructions on a non-DSP CPU and
 Dominic> trap-emulating them, for example) which you end up having to
 Dominic> figure out how to lie to the toolchain.  I think an
 Dominic> assembler is a low-level thing which should do what it's
 Dominic> told to do, and not argue overmuch.

 Dominic> Are you convinced?  Half...?

No, no way, not at all.

If I want the assembler to accept DSP opcodes, I'll tell it to do so.
I can pass it an architecture flag, or in very unusual cases, I might
do .set push; .set dsp32; .....; .set pop.

Note that the case where emulation is done would be covered by telling
the assembler that the architecture is one that DOES support the DSP
ASE -- because "supported" means "I want those opcodes to be accepted
because in my environment they work", whether "work" is via hardware
or via software.

One reason I feel very strongly about this is that I want to catch
bugs early on.  Bugs that can be caught at compile time are trivial to
fix.  Bugs that I hit at run time may be VERY hard to fix depending on
which code path they live in.  If a compiler or assembler could have
done a trivial test to catch a bug that insteads causes a crash at a
customer site, I am going to be VERY upset.

One reason I like C++ is that it catches some bugs at compile time
that C leaves until runtime.

Incidentally, if you want to talk about second-guessing in assemblers,
we can have a very interesting religious debate about real assemblers
that emit one binary opcode for each source opcode, vs. the MIPS
"assembler" that performs amazingly strange transformations on my
code.  But I think I'll resist the urge for now and just keep saying
".set nomacro; .set noreorder; .set noat".  :-)

     paul