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]


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.

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

> 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.

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

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

Are you convinced?  Half...?

--
Dominic


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