Lpc2000

--- In lpc2000@yahoogroups.com, "Stephen Pelc" <stephen@...> wrote:

> When I look at where MPE (as opposed to its clients) uses in-
> line assembly, we find it in device-specific drivers, e.g. UART 
> and Ethernet drivers, and in CPU specific sections, e.g. 
> schedulers, where we are striving for performance.

That's true with me, too. The few times I get involved with low-level
issues not already handled by libraries I need to spend a lot of hours
with irritating registers, processor modes and the like. Frankly,
these types of things make me employable, so I shouldn't complain too
much!

But I have never used any inline assember except for the code
recommended by compiler vendors (which used to happen more than it
does now - libs weren't well developed back then). I always prefer to
isolate my asm code in separate modules with well-defined API's, and
then I link them to C programs.

I also use asm for things that need to be kept secret, like licensing
support code, and the like. It's much harder to disassemble hand-coded
assembly routines than compiled C code, especially if the asm code was
written with this in mind. Sometimes the art of deception even
involves code for peripherals that aren't even being used for anything
- it's the old magicians trick of attracting you to one hand while the
other hand is doing something completely different.

Assembler routines take about 10 - 20 times longer to write than C,
and a much longer time to debug. Most companies simply can't afford
this kind of development except for those cases where there is no
alternative. And when this kind of need arises it often makes sense to
use a consultant who specializes in this.

Eric