Lpc2000

Jaya,

I fear I'm repeating myself: the problem isn't that in-line assembler 
doesn't work, the problem is that it is completely non-standard and 
non-portable. 

If you insist on using it, when you move to a new platform you have 
to re-write the application (as in the hypothetical example I 
presented).

Better by far I think to follow the well-known technique of isolating 
the platform-specific parts (i.e. the assembler) into a small 
separate compilation unit (i.e. assembler source file), and providing 
different versions of that file for different platforms. In other 
words, rather than mixing portable with non-portable code (as in-line 
assembler does), separate it out.

Now if you believe portablility between environments isn't an issue 
for you, I suggest you read back over some recent posts to see the 
difficulties encountered by those attempting to port code to ARM when 
non-portable features have been used. I'm sure the authors would have 
said when the code was 1st produced "I doin't have to worry about 
portablility".

I really can't think of another way of saying this, though I could 
supply a real example if you or anyone else is really interested.

Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "brendanmurphy37" <brendan.murphy@>
> wrote:
> 
> > I've already provided an example of where it can cause problems:
> 
> Sorry I must have missed it becuase it was not clear.
> 
> > If you have an application that makes extensive use of processing
> > on 128-bit numbers using in-line assembler (as someone suggested),
> > what happens when you want to port that application to another 
> > environment? Bit of a problem, I think.
> 
> Which environment are you switching to? What is the problem?
> 
> Examples of simple needs where inline assembly meets the requiremnt
> well have been presented here.  If there is a problem, I like to 
know
> what it is in specific terms.
> 
> Jaya
>