Lpc2000

Robert,

Thanks for your detailed response.  Here is an alternate view.

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> >My experience tells me otherwise.  Inline assembler has its place just
> >like any other feature *provided* one understands how to use it before
> >one does.
> 
> Apparently we have experienced different projects and tools.

I have had considerable experience in training programmers from 18 to
50, in academia and in industry, using Borland, ByteCraft, Keil
compiler variants besides K&R C, on 8-bit, 16-bit, 32-bit, CPUs and DSPs.

I have written compilers, assemblers, linkers, operating systems,
mostly all in C.  I also have a good record in trouble shooting
problems to their root causes when it is not clear if the compiler or
the code being compiled is at fault.

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

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.

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

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

I am not saying optimisers do not screw up.  But they are bugs just
like other bugs.   There are bugs in how compilers implement switch
statements. That is not sufficient grounds IMO to advocate not using
switch construct.

> 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.  I provided an
example in GCC where you do not have to name a register -- get the
compiler to allocate it.  This way, the compiler always knows what is
being used.

I am happy to consider real examples, past or present, which I hope
will make it easier to illustrate the points I have raised.

Jaya