Lpc2000

Allow me to get back to the thread proper using top down.

I will start with the list of advantages I have already pointed out as
arising from making the distinction between user and system modes of
operation as follows:
 
1/  allows codes of different maturity level (system vs user,
operational vs experimental, infrastructure vs application) to coexist
in the (embedded) system in a way that failure of (user) code does not
result in failure of the entire system;

2/  provides isolation between caller and callee in providing the
kernel primitives that will work under variety of conditions,
including that not anticipated by the provider; and

3/  renders the resulting system friendly in relation to probing by
hooking onto kernel primitives without the need to touch user code.

[This helps track down problems of the type that go away when you add
code to the application to watch what happens.]

The tools I listed as useful in achieving the above goals, without
making the system complicated, large or inefficient are:

1/  Inline functions: These behave exactly like a function that does
not have this attribute (for type checking and so on), but at the same
time makes the implementation visible to the compiler (and user).

2/  Inline assembler: This allows target code to generate the
appropriate binary instance of the same source code depending on how
it is compiled (16- or 32-bit mode, interworking paradigm, and so on)
to accommodate style and preference requirements of the application
programmer.

In the context of this, I shall respond to your post by way of annotation.

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
> >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.

If the advantages I listed above does not apply to your scenario, then
I can accept this statement.  I cannot see why the do not though.

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

Even taking into account the, I cannot see how to make it more
efficient :)  Probably because I do not like assembler too much!

> One line functions tend to lead to a proliferation of functions.

The fact that a feature or technique can also be misused is (to me)
not sufficient justification to barr its use.

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

See above.

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

I think you do not appreciate the fact that there is only one instance
of the kernel binary, not multiple variants depending on what mode the
application was compiled in.

I use the ARM primitives designed just for this purpose.  Doing it
otherwise would be more expensive in terms of code and space.

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

See above.

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

If you use ARM/THUMB, you have to maintain two version.  In my method,
you do not need to.

If you do not distinguish system vs user mode, then it does not apply.
If you however chose to, then this comes at no cost in my approach.

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

This is where I think you have not understood the code snippet that I
hoped will speak for itself.

The kernel is compiled with the interface header and in 32-bit mode. 
There is only one instance of the kernel in memory.

The user code is compiled in 16- or 32-bit mode, and only one version
of its binary is in the system.  You can have one application compiled
in 16-bit mode, and another in 32-bit mode, coexist in the same
system, and use the same calls, with only one copy of the binary of
each of these applications.

> Good Lord, you have got to be kidding.

If I had a penny every time I heard that, I would be rich! :)


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

See benefits listed above.

>          - How does implementing a kernal help you narrow that region 
> down?

Because the kernel handles all interrupt enable and disable
operations, this is where one starts looking for problems relating
interrupts disabled but not enabled thereafter.

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

No.  I provide the disableInt() and restoreInt() primitives to any
function, whether or not it is running in user or system mode.

There is no restriction that you leave the kernel mode with interrupt
disabled.

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

This is where I ask people to include memory protection in their
selection of targets for their application.

[soap box]
My biggest gripe with LPC family is not so much that it has no concept
of memory protection, but its flash operations are not protected
unlike any other system I have seen or have been told about.  The
absence of CDP gives rise to software causing the hardware to be
unusable in the case of LPC.
[end of soap box]

Jaya