Lpc2000

Robert,

I agree completely. I'd much rather spend time figuring out the 
calling conventions for a particular platform (which as you point 
out, you need to know anyway) than learning some obscure syntax and 
set of rules for some compiler-specific non-standard feature like in-
line assembler.

Until you're faced with it, it's too easy to ignore portability 
issues. However, even a brief review of the problems people have 
reported to this group over the past while will show how common 
those issues are. In-line assembler, "__irq" and "__fiq" function 
modifiers, bit-masks to access hardware registers, take your pick. I 
think they're all best avoided.

To take another example given recently, I can easily imagine 
implementing a set of math functions for 128-bit numbers in 
assembler for efficiency reasons, and calling them from some 
application. When you want to (or more likely are forced to) move to 
a different target platform, all you have to do is re-code the small 
number of lower-most level assembler functions, instead of re-
writing an entire application.

None of this is to say that any of these features don't or can't be 
made work, and if it suits then fine. Just be aware that most of 
them have more than their fair share of capacity to bite at some 
stage down the line.

Finally, to the original questioner that started this thread I'd 
recommend reading the relevant compiler's documentation for an 
example, as it is typically compiler dependent on how it operates.

Brendan

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> 
wrote:
>
> At 11:50 PM 4/8/06 -0300, Boris Estudiez wrote:
> >On 07/04/2006 at 21:29:55 -0400 Robert Adsett Wrote:
> > > At 10:31 PM 4/7/2006 +0000, rtstofer wrote:
> > >
> > > >OK, I'll bite!  I have used inline assembly in cc5x (sort of 
C for the
> > > >PIC) to control exactly the number of cycles in a delay 
routine.  No
> > > >active interrupts in this code.  I suppose it could be done 
in C but
> > > >that would change with compilers and optimization.
> > >
> > > An argument for assembly yes, but I don't see it as an 
argument for inline
> > > assembly.
> > >
> > > Robert
> > >
> >
> >One advantage of inline assembly is that you don't have to worry
> >about of the calling convention used by the compiler (such as 
ATPCS
> >or APCS).
> 
> An argument yes, but I don't think  a good one.  In the same time, 
or less, 
> that it takes to figure all the peculiarities of how inline 
interacts with 
> the main code (if indeed it's documented even close to properly) 
you can 
> learn the calling conventions of the compiler and do a 'proper' 
assembly 
> routine.  And the resulting code is a whole lot less fragile.
> 
> If you are serious about embedded work then at some point you have 
to learn 
> the calling conventions anyway so you've not saved any effort.
> 
> 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/
>