Lpc2000

Jaya,

OK - I think we got off on the wrong track: I'll try and explain 
further.

I was using your example - which is perfectly valid in itself - to 
illustrate a point.

Consider the following sequence of events:

1. We need some mechanism to lock out interrupts, for reasons that 
should be clear enough to everyone.

2. We decide to implement this as in-line assembler, wrapped up in 
some nice macros. In fact, we implement exactly the same macros as 
you presented in your example.

3. We test these out, and they work well. Everyone is delighted with 
the results. Our macros are a great sucess, and everyone is happy. 
Everyone uses them, all over the place.

4. Then, as often happens, some new requirement comes along. Code 
space is now a real issue for everyone. No problem: our chosen 
architecture has just the solution: re-build all our software using 
Thumb mode.

5. We re-build our software and are faced with an immediate problem: 
our nice macros that are used everywhere no longer work, as they use 
ARM-mode specific instructions.

How do we solve this problem? there are all sorts of ways it can be 
solved: I'm sure you and I could both come up with several without 
too much effort. The problem is that it will take effort, no matter 
how it's done.

The point I'm making is that the more you use non-standard, compiler-
specfic features such as in-line assembler, the more likely it is 
that changing requirements will cause problems.

It's a general point: unfortunately as we all know we can never 
anticipate all possible requirement changes when we produce a 
solution to a set of requirements. However, by following some general 
rules, such as avoiding non-portable features where possible, we 
increase our chances of being able to modify our system with fewer 
rather than more changes as requirements change.

I completely take your point that your example was for illustrative 
purposes only, and that you probably wouldn't implement these macros 
in a working system (possibly for the reasons I outline). However, 
I'm using also it to illustrate a point: a naïve programmer might 
very well use solutions such as those in the example, without being 
conscious of the need to consider portability issues.

Best wishes
Brendan

--- In lpc2000@yahoogroups.com, "jayasooriah" <jayasooriah@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "brendanmurphy37" <brendan.murphy@>
> wrote:
> 
> > Maybe you should read what I said again, with this clarification 
in 
> > mind?
> 
> I have.  You include interworking requirements to the original 
problem
> from which I extracted the requirements.
> 
> If you can rephrase your problem without interworking requirements, 
I
> am happy to respond.
> 
> I do not wish to start a thread on interworking at this time because
> it is a different kettle of fish.  (I do not know of any compiler 
that
> is capable of optimisating across interworking barrier.)
> 
> Jaya
>