Lpc2000

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> Actually I was thinking more along the lines of a real time 
> kernel,  threads, semaphores etc..  I can see the term being
extended a bit 
> beyond that but at the risk of its losing its meaning.

My aim was to challenge that assumption that kernel must be large,
general purpose, and is only worth if there are many primitives.

The atomicFeed() example shows the benefits of making even just a
single procedure call a kernel primitive.  I have boot loaders that
run with as little as three of four kernel primitives.

> In this case somewhere between 50 and 80% since all you are left
with is 
> the implementation function.

I dont understand what you mean.  Are you suggesting changing the
kernel call to procedure call will be smaller -- 50 to 80%.  I like to
see how.  You have to try it to discover the tradeoffs.

> That's not really fair though I would expect 
> a real kernal to use somewhat heavier functions.

This is contrary to the KISS rule -- the simpler the functions are,
the less likely they will fail, the easier they are to manage, and the
more useful they would tend to be.

There are OSes (as different from kernel feature) that seek to
accommodate a variety of paradigms.  They are big for this reason.

> I wouldn't pass the WD as 
> an address to the function like that, it just confuses the
interface.  Also 
> something I wouldn't do inline but we've been through that ;)

This is more a "style" or "preference" issue than programming
paradigm.  Maing it a parameter avoids having to provide separate
primitives for WD, PLL, and so on.

> However the bigger issue hasn't been addressed which is the rest of the 
> overhead.  The rather simple to maintain simple function interface
has been 
> replaced by two functions separated by an interrupt.  Across this
interrupt 
> you have lost the type checking and other interface protection C
normally 
> provides.

If you do not use kernel calls then you cannot reap the benefits.

I went through at great lengths to preserve type checking.  Hennce the
use of inline functions rather than macros.  Why do you say type
checking is lost?

> You also have not addressed the issue of what this approach actually 
> achieves.  Since there appears to be no extra protection added by
being in 
> user mode all that appears to have happened is that you've replaced one 
> function call with two calls plus an interrupt (one call to setup the 
> registers for the interrupt, one call from the interrupt cracker to the 
> actual function).

Two that I like to point out most:

1)  implementation does not know (and does not rely on knowing) if the
caller is in 16- or 32-bit mode; and

2)  implementation does not know (and does not rely on knowing) if the
caller is in user or system mode;

This means that there is no need to maintain multiple version
libraries for the four permutations of the two modes.

> I also don't see anything being lost by using a library that links
directly 
> rather than through a SWI.  Quite the reverse actually.

Library linked code is strewn all over the code space.  Kernel method
allows it to be managed much more efficiently.

Supppose a system locked up because interrupts ended up turned off. 
It would be trivial (or near trivial) to identify the culprit with the
kernel approach without having to even rebuild a single application
code.  I cannot think of any other method that is as simple and efficient.

> I can see three cases where this approach could be useful
>          1- A large system where the kernal is loaded separately
from the 
> application.  Possibly with the application in RAM

I would advocate against this.

>          2- A multi-language app with the kernal and application having 
> incompatible calling conventions.

This is not my intention here.

>          3- An appliance application where the kernal and chip are
shipped 
> as a unit.

Yes, it would have been much more efficient to provide primitives in
this manner that avoids the programmer having to discover one
limitation after another the painful way because the interface is a
procedure call but with the complex implementation idiosyncrasies
hidden from the user's view.

> >Incidentally, the "vectored SWI" approach I use allows any team member
> >who are play with custom "system mode" kernel calls.
> 
> "to play with" maybe?
> 
> Which is different from a linked library in what fashion?

Actually this "play with" comment comes from my training background. 
I like the programmers to get experience in working across interfaces
by working on both sides and this method allows them to.

Where the abstraction is useful to many programmers, it makes its way
into the common pool of kernel functions, and becomes part of the tool
set that new programmers can assume already exists and not re-invent
the wheel.

> >PS:  E&OE applies here too :)  If you spot mistakes, please do not
> >hesitate to point it out.
> 
> E&OE?

Errors and Omissions Excepted (or something like it).  It is meant to
say that I have not put through the code through compile or debugger.

My justification is simply that if I put the fully operational code,
there are things in there that will distract one form the purpose of
the example.

However it takes time for me to make the changes, then compile to make
sure there are no typo or silly errors.  So I get lazy and just add
E&OE!  It just helps me provide examples more liberally than I can
otherwise do.

Jaya