Lpc2000

--- In lpc2000@yahoogroups.com, "John Heenan" <l10@...> wrote:

> > It certainly dismisses the myth that one can disable interrupts 
> while
> > in 16-bit mode without interworking!
> 
> I was not aware of any such myths.

I was referring to the persistent request (to which your first post
was a response) that my interrupts example can be extended to 16-bit
mode without interworking.

> Interrupts can be disabled without interworking on the LPC2xxx 
> through the VIC registers while in Thumb mode. I have brief notes in 
> preperation to be submitted as a file to the group.

Yes but there are costs.  The first (and prohibitive as I have argued)
is that the implementation of VIC on the LPC family (based on PL190
design) causes spurious interrupts to be generated when you do this.

The second (probably more insidious) is that the distinction between
of user and system modes appear to have been lost in the process.

> As I said it is just standard code adapted to fit a simple idea, 
> namely force industry standard ARM assembler code into a form 
> suitable for Thumb through functions compiled for interworking.

The term "industry standard" cuts both ways -- see comment below :)

> Both ARM and Philips state a 
> default handler must be assigned using the standard examples they 
> provide that has been incorparated into the code.

The "default" handler in VIC (PL190) is to handle interrupts that are
not vectored.  If all the interrupts are vectored, one does not need
to dismiss interrupts through the default handler -- one can take a
kernel panic when this happens as it indicates a system failure.

Philips requirement is different -- it a default interrupt handler is
required to dismiss spurious interrupts generated by LPC peripherals.

> Point accepted. Saw THUMB_INTERWORK in another example and took a 
> punt it was standard. I was wrong.

I like to make the distinction between "practice" and "standards". 
This is what I meant by "cuts both ways" earlier :)

> It reflects my attitudes to macros and functions. I tend to make 
> function names reflect what is really going on at the lower level and 
> make them lower case. I tend to make macros names closer to the real 
> intention of the macro is and in upper case. It is a practice that 
> serves me well personally. I get a marriage of intention (macro name) 
> with implementation (function name), all in a single line definition! 
> 
> However it is a practice I can be divorced from if is the democratic 
> will!

My experience from having to look at historical code base, is that
this is one of the biggest impediments to code life.  The next person
has to not only understand and appreciate how the features of the
language are used, but also understand new abstractions that sometimes
obfuscate the original intent;

For example:

	SAVE_INTERRUPT_STATE;

and

	int mode;

	mode = getInterruptState()

say quite different things.  The latter can be understood by anyone
with just the language semantics, but to understand the former, one
has to include the mind set of the original programmer to discover how
is the save achieved, where is it saved, and how does one restore the
saved state, what happens when there are more than one saved state, etc.

I advocate the philosophy that one uses as much of what is there
rather than creating new abstractions, and that a strong case be made
each time a new abstraction is contemplated.

Programs express precisely what we cannot easily do as prose.  Making
program look like prose usually works against KISS rules.


> > I prefer to avoid having to name registers explicitly so as not to
> > impose additional constraints on register optimisation.
>  
> I only named one register, r3, and specified it was clobbered. Since 
> the register cannot be attached to an input or output variable and 
> since I did not to troll through the horrific GAS assembler 
> documentation to see if there was a qualifier to specify working 
> registers r0-r3 or r12 only, I took the easy way out.

You are right in that there is no way to allocate a register that is
not attached.  However I thought the method I originally proposed that
does exactly the same overcomes this limitation.

> Inline code CANNOT get rid of the call and return bx instructions 
> (bxl for Thumb also) as these instructions are the mode change 
> instructions. Inline code expands TOTAL code size but does have the 
> advantage of not refilling the fetch/decode/execute pipeline.

Not true.  The compiler is able to optimise prolog/epilog when it
instantiates functions inline.  Have look at my original example
carefully.

Regards,

Jaya