Lpc2000

At 02:32 PM 4/11/2006 +0000, jayasooriah wrote:
> > Problem 1:  Nearly all implementations suffer from a lack of
> > documentation.  One case in particular I remember the documentation
>boiling
> > down to more or less "the inline asm syntax is  asm assembly
> > instruction;"  Needless to say, I didn't even attempt that one.
>
>I do not agree with your "nearly all" characterisation.  Perhaps many.

Fair enough, Many/nearly all could well be a sampling error or selective 
memory.

>The ARM GCC Inline Assembler Cookbook is one that comes to mind.  I
>have seen some others documented reasonably well too but I will admit,
>it is very hard to get programmers (whether 18 of 50) to reading the
>manual.

I would be an exception, annoys some people for some reason.

Where would I find that BTW?  The one gripe I have against GCC is that the 
documentation seems to be well hidden.

> > Problem 2: Incompatible C syntax The form above is obviously not
> > compatible, so is the form
> >          #asm
> >                  assembly instructions
> >          #endasm
> > They both cause problems with tools and reuse.  Tools are generally the
> > bigger issue.
>
>I agree, *if* the compiler does not support inline assembly properly.
>  Do you think GCC falls in this category?  I am not sure about the
>rest, but in GCC, the ASM feature is a (clever) hook to the code
>generator internals.

I've no reason to disparage GCC particularly.  Indeed GCC seems to be the 
best thought out implementation I've seen (mostly from afar) but it as a 
result it also tends to be most of the way towards being a third language. 
I've just yet to see an advantage to inline over standard assembler and 
given the problems I've encountered the 0 benefits/x problem ratio tends to 
discourage :)

Actually (as a side bar), the availability or lack thereof of GCC for an 
architecture is becoming a major consideration in choosing a 
microcontroller for me.  I've become fed up with the copy protection 
schemes commercial compilers tend to foist upon me.


> > Problem 3: optimization. If the assembly is just inserted in the
>middle of
> > the generated code before being passed to the backend it is sometimes
> > optimized away.
>
>I would classify this more a myth than fact.  One has to understand
>the limitations of the feature before one uses it.  More often I find
>that the programmer forgets to use the volatile qualifier.

Since at least one of the compilers that exhibited this had no concept of 
volatile (pre-ANSI) that would have been difficult.  Surely volatile is not 
used universally to signal this?

> > Problem 4: Register reappropriation.  Not a good term but it will
>do.  The
> > compiler documents the calling convention but when using inline even
>at the
> > beginning of the function the compiler appropriates the register for
>other
> > temporary uses first so you can never be sure that you will get what
>you
> > were expecting when you originally wrote it.
>
>I classify this the myth category.  More often than not, one forgets
>and names a register and forgets to tell the compiler.

That presupposes that it is possible to tell the compiler what registers 
are being used.

Both of the last two problems I have seen.  It's been long enough I 
couldn't dredge up the details so it's certainly subject to fuzzy recall 
and you should feel free to take with as much salt as you like :)


My experience has taught me (much as touching a hot stove does) to avoid 
compiler and architecture specific 'features'.  There are times they cannot 
be avoided or the facilities they provide are very advantageous.  Items 
like mapping into otherwise unaddressable memory spaces come to 
mind.  However, for items like assembly and interrupt prologues and 
epilogues where there clear, simple well tested alternatives I won't 
subject myself to the risk any more.

I don't expect we are likely to change each others minds, but knowing why 
we reach the decision we do is useful I think.  Now if someone could come 
up with a credible way of measuring some of this we might be further 
along.  On the other hand that might just destroy the fun of debate ;)

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/