Lpc2000

At 02:55 PM 5/6/05 -0700, Richard wrote:
>At 06:38 AM 5/6/2005, Robert Adsett wrote:
> >...
> >Well put.  In the end compiler writers have limited resources to develop
> >and test.  If I have a choice about where I want them to put their efforts
> >it's in basic code generation.  Interrupt epilogue and prologue (or task
> >switching or machine register access or.... ) are easily handled in
> >assembly leaving the bulk of the code to standard C or C++ code.
> >
> >Robert
>
>Keep in mind that I am one of those compiler writers. Regardless whether a
>compiler company can reasonably support certain extensions that some
>customers may need, my comments about it being "sad statement to make" is a
>response to your statement basically saying that you were not getting good
>results from the compilers and the implications is that you were not
>getting good responses from the compiler vendors for support either.

Catching up on some correspondence.  I spent until 1 in the morning Monday 
on a service call for a client who usually only calls me in on these when 
things are too difficult for his techs.  I ended up dealing with series of 
simple problems (one ended up being a missing! fuse).  I think the techs 
must have fallen asleep.  That of course set me behind.

Actually Richard, I did realize you were one of those compiler writers.  I 
hope you didn't think I was casting aspersions.  And frankly, I don't 
consider a compiler producing bad code for an interrupt keyword to be a bad 
result for a compiler, since I don't consider that to be part of the 
compilers job.  Not being able to multiply two 16 bit numbers together 
correctly, that's a bad compiler and unfortunately, I've seen that too.

Generally I want a pretty utilitarian compiler.  Command line driven, no 
IDE, the smallest number of extensions possible, startup source code, 
bullet-proof code generation, a companion assembler and the best optimizer 
possible.  I don't need or particularly want interrupt support, in-line 
assembler, wizards or keywords to provide access to some particular micro 
feature (usually I only need access to such features for a very (very) 
small portion of the code and that can be easily done in assembly).  I will 
avoid if at all possible, dongles be they hardware or software,compilers 
that only allow access to assembly via in-line assembly, compilers w/o 
linkers and compilers w/o a command line that provides access to all of the 
compiler options.  I already have a good editor and a good make and I don't 
need another one with it's own new set of interface prejudices forced upon 
me.

Compiler extensions can be necessary, but quite frankly, I've yet to see 
the need for any on the ARM architecture.

Support from compiler vendors is all over the map.  One compiler I used, I 
was always using a beta version since they kept fixing bugs I ran into.  I 
suppose that''s good support in the sense that they kept fixing the 
problems (and this was download via modem before internet connections were 
commonplace).

One of my most annoying support issues was not with a compiler vendor but 
an RTOS vendor.  I was developing on a chip that had a lot of errata and 
partly as a result of that I was using a low optimization level on the 
compiler.  I spent some time (weeks) trying to track down a bug that would 
appear and disappear with little apparent rhyme or reason.  It appeared 
that the context was getting corrupted and naturally interrupts were a 
prime suspect.  I finally tracked it down to an operation in the RTOS that 
was supposed to be atomic but took two store operations.  Interestingly 
enough the operation was atomic when the optimizer was turned up since the 
compiler generated a sequence that effectively disabled interrupts during 
the two stores.  With the optimizer was turned down the operation was 
broken into a slightly longer non-atomic sequence.  Being a good customer I 
reported the oversight of not protecting this operation in order to ensure 
it was atomic.  The response?  It wasn't considered a bug since it didn't 
occur at the higher optimization levels!

The worst compiler issue was the 16 bit multiplication above which was 
blamed as being an ANSI requirement.  We replaced the compiler ;)

The best support is the support you don't need :)

Having said that, I've never used a compiler seriously that hasn't broken 
in use.  The only exception so far is GCC and I expect that's just a matter 
of time.  And most of those compilers have been well known and respected.

Enough of the soapbox for now :)

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/