Lpc2000

In looking at this again, it struck me that another reason not to 
use in-line assembler such as the example below (i.e. particularly 
where macros are involved) is to ask what happens when you want to 
re-compile the code using Thumb mode (as you might want to do to 
reduce code size)? My guess is that the macros will no longer work, 
so you'll be forced to do Thumb versions of the same. Then you have 
to figure out a way to use the correct macros at the correct places.

This is a typical example of not considering portability issues at 
the start, and having them come back to haunt you at a later date.

1. Start off with some neat code that exploits some compiler 
feature, in this case by writing some clever macros that use in-line 
assembler.

2. There's no issue with Thumb mode, because all the code is 
compiled in ARM mode: where's the problem?

3. The macros are so good they get to be used all over the place.

4. Suddenly someone wants to use this software: the problem is 
they're insisting on using a part with a minimal amount of code 
space.

5. We know we can achieve this if we used the preferred ARM 
mechanism for reducing code space (Thumb mode), but we have all 
these ARM-code inline assembler macros scattered throughout the code.

6. What do we do?

I'm not saying this scenario is the case here, but hopefully people 
can see what the big deal is with using non-standard, non-portable 
features: you can never tell how requirements will evolve over time.

The alternative I approach I posted doesn't suffer from this 
problem. I'm not saying it's perfect, but I'd argue that at the very 
least it is easier to maintain and modify.

I have seen many, many examples of the sequence of events listed 
above (details changed obviously), and each time there's been a lot 
of pain involved in solving the self-inflicted problems thrown up. 

Please note that none of this is a criticism of the actual code 
below: I'm simply using it to illustrate a point.

Brendan.


--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> 
wrote:
>
> This is an add-on to Danish Ali's contribution to AH's original 
question.

[[items removed here]]

> 
> > // ===========================================================
> > // 'irqMask'
> > 
> > // mask either irq or fiq bit
> > inline int
> > irqMask(mask)
> > {
> > 	int mode;
> > 
> > 	// set mask bit
> > 	asm volatile
> > 	(
> > 		"mrs\t%0, cpsr"		"\n\t"
> > 		"orr\t%1, %1, %0"	"\n\t"
> > 		"msr\tcpsr, %1"	
> > 		: "=&r" (mode)
> > 		: "r" (mask)
> > 	);
> > 
> > 	// previous mode
> > 	return (mode);
> > 
> > } // irqMask()
> > 
> > // End of 'irqMask'
> > // ===========================================================
> >