Lpc2000

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

> The compiler 'knows' about DI and EI to disable/enable 
> interrupts. The ways to the put an MSP430 to sleep are myriad. 
> The objective is to minimise the time for which interrupts are 
> disabled. Putting in a single assembler instruction achieves 
> that objective and documents everything the user needs to know.
> 

Good example of an appropriate use of in-line assembler. The side 
effects of issuing the "DI" and "EI" are pretty much non-existent in 
this case: there really is very little argument for taking another 
approach (though I would hide the implementation behind macros just 
in case).

For an in-appropriate use, see the recent example of ARM macros to do 
a similar task.

> Where I will code a complete routine is for something like the 
> TCP/IP checksum, where a hand-coded assembly routine will beat 
> the pants off the output of most compilers.

I'd be careful about making this argument. We do a lot of DSP stuff 
on RISC processors (digital filters of various types). For the low-
level stuff, our starting point is a 'C' implementation. On a couple 
of platforms we coded these up in assembler. However, we stopped 
doing this, as by measuring the performance of the optimised 'C' 
version we found there was little difference in performance: 
certainly not enough to justify the additional development and test 
time required. The greatest performance gains came from algorithm 
optimisation rather than coding in assembler.

> 
> For an ARM7, each call/ret pair costs at least six cycles. For 
> matched entry/exit routines, that costs at least 12 additional 
> clocks. On the LPC2xxx there are four potential MAM stalls.
> 

Someone presented this argument in relation to coding a context 
switching implementation. I'd argue that if you can't afford a few 
extra cycles in your context switches, you're doing too many of them. 
Try another approach.

I've seen this argument so many times: a particular way of doing 
something saves a few cycles. In the vast majority of cases it makes 
absolutely no difference to a system's performance. If you really are 
that close to the edge, you're much better off at reconsidering the 
overall approach you're using.

Unless something is inside a loop with many iterations, or part of a 
very high frequency event (e.g. a high frequency interrupt), it is 
pretty much guaranteed not to have any impact on system throughput. 
If it is in either of those situations, and performance was an issue 
(determined by quantitative analysis or empirically), I'd look at re-
coding the entire offending section. If you really, really feel the 
need for in-line assembler, I'd isolate the relevant code into a 
separate source file.

> When you have an effectively 12MHz ARM (not an LPC2xxx), 
> thirteen tasks, and a bomb-disposal machine to control, you 
> learn to be paranoid!

I'd argue that this would lead one to maximise quality rather than 
speed of code. Simplicity, ease of maintenance, absence of side-
effects, portability all tend to drive quality up. Squeezing the last 
drop of performance, using non-standard compiler extensions and the 
like all tend to drive it down.

Please don't get upset anyone, the above is just an opinion! I'm 
happy to accept that the counter argument is perfectly valid: all I'm 
saying is that based on my own experience, using in-line assembler 
would be my last rather than first choice.