Lpc2000

At 04:20 AM 4/18/2006 +0000, jayasooriah wrote:
>--- 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.

I don't yet see a benefit in using SWI over a function call.  Only 
disadvantages.  That is the question here; not the size of whatever we 
refer to as the kernal, since presumably that's why we are using user mode 
rather than system mode.

> > 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.

Let's see

function call -> SWI -> Irq  cracker -> function call

vs

function call

As I said earlier I don't consider this an important point.  Remember I'm 
one of those who think inline code is a bad idea, I'm not going to quibble 
about the extra execution time of a SWI unless maybe you are calling it in 
a small time critical loop.  "Premature optimization is the root of all 
evil"  Knuth (I think)

> > 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.

> > 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.

One line functions tend to lead to a proliferation of functions.  Also 
violating the KISS principle.  There is a golden mean somewhere.  This 
particular case I would have gone the other way and provided two functions 
one for the watchdog and one for the PLL since they are the only items that 
make use of that particular mechanism.  The functions would also provide 
some additional functionality.  Each function providing a complete 
functional unit in keeping with the KISS principle.

> > 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.

True, but the question of whether to use a kernal or other set of support 
functions is separate from what benefit user mode may have. I ask again 
what benefits does user mode have?


>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?

If your compiler can type check a SWI it's a sight better than any I've 
ever seen.


> > 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

?? How is that an issue? We've been talking about user/system 
mode.  Compiling libraries for ARM/Thumb is a simple exercise.  Trivial if 
your 2 or 3 assembly routines are written to accommodate both.


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

This gets us back to the question I've been asking from the 
beginning.  What is the benefit of running in user mode?

If SWI is available in both that eliminates it as an a benefit of user mode 
even if there is an advantage to SWI.

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

I can see maintaining ARM/Thumb but why maintain system and user versions?

Your solution also needs to maintain both.  You still need a library


> > 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.

Good Lord, you have got to be kidding.

>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.

Two points.
         - What do either of these have to do with user/system modes?
         - How does implementing a kernal help you narrow that region 
down?  The only way I can see it is you restrict interrupt setting to the 
kernal but even that only narrows it down if you insist that interrupts 
always be on when exiting the kernal.  That's not unreasonable in my 
opinion but it's got nothing to do with user/system modes.  It also does 
absolutely nothing to protect against the far bigger dangers of memory 
access outside of the bounds.

> > 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.

I wouldn't use it either but then I don't build embedded systems that 
large.  AFAIK nearly all large embedded systems use this technique.  For 
that matter a fair number of them use hard disks.


> >          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.

huh?

Idiosyncratic is idiosyncratic whether in a SWI or a function 
call.  Whether in user mode or system mode.

> > >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.

I was verifying that I understood your grammar here.  I wasn't clear that I 
understood it.  It appears I did.  And again how is this different from a 
linked library?

>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.

Indeed, but this is a separate question from system versus user mode 
benefits.

I do use kernals of support, after all why keep rewriting the same thing 
over and over,  but so far I see no benefit to using user mode.  I was 
hoping you would provide one but we seem to have veered off into a 
discussion of SWI, which is somewhat related but doesn't provide an answer 
unless there is a benefit to using a SWI over using a function call.  And 
for the size of system we appear to be talking about I fail to see any 
benefit in a SWI.


> > >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.

Ah, I've just not seen that used before.

Robert


" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/