[ECOS] ARM cpu modes

[ECOS] ARM cpu modes

[Colin_Helliwell]

Jesper said in a message yesterday that "[ARM] Application threads run in
supervisor mode in eCos". I've heard/seen it said somewhere that the ARM's
privileged Supervisor mode was intended for OS-type operations, whilst the
non-privileged User mode was intended for application-level code. I was curious
about the rationale behind the choice made in eCos, and whether it is felt that
there are actually any pros and/or cons of running application threads in
supervisor mode.

Thanks.
Colin Helliwell

Re: [ECOS] ARM cpu modes

[Hugo 'NOx' Tyson]

Colin_Helliwell@Mitel.COM writes:
> Jesper said in a message yesterday that "[ARM] Application threads run in
> supervisor mode in eCos". I've heard/seen it said somewhere that the ARM's
> privileged Supervisor mode was intended for OS-type operations, whilst the
> non-privileged User mode was intended for application-level code. I was curious
> about the rationale behind the choice made in eCos, and whether it is felt that
> there are actually any pros and/or cons of running application threads in
> supervisor mode.

Those distinctions are only pointful if you do stuff like memory protection
(including of IO device) and therefore have a SWI interface to *all* system
services. 
"Big" OS's with processes (=> memory protection and VM) would do this.
"Small" OS's ie. eCos, with threads and one uniform memory space do not.

eCos apps are fully linked, there is no SWI interface, and for performance
reasons, we *want* appliction object files to contain "privilidged"
operations from eCos macros or inline functions.  Device driver code is not
"special" in any way.  For example, cache flushing or sync'ing is usually a
coprocessor operation, which you can only do in a non-User mode.  But it's
only a couple of instructions, so there's no need to put in a clunking
great function with mode changes surrounding it; just put it inline with
the app code.  So it all must run in Supervisor mode.

Actually, we have considered moving to System mode (User mode reg set with
SVC mode privilidges) but it's not available on all ARMs and there ain't
much to gain...

HTH,
	- Huge

-- 
The 20th Century brought unprecedented increases in worldwide numeracy and
literacy and incredible advances in technology, science and mathematics.
It was also the only century in the past or in any reasonable predictable
future apparently to contain only 99 years.

RE: [ECOS] ARM cpu modes

[Gary Thomas]

On 05-Apr-00 Colin_Helliwell@Mitel.COM wrote:
> Jesper said in a message yesterday that "[ARM] Application threads run in
> supervisor mode in eCos". I've heard/seen it said somewhere that the ARM's
> privileged Supervisor mode was intended for OS-type operations, whilst the
> non-privileged User mode was intended for application-level code. I was curious
> about the rationale behind the choice made in eCos, and whether it is felt that
> there are actually any pros and/or cons of running application threads in
> supervisor mode.
> 

eCos assumes full responsibility for the hardware.  An eCos application needs
to run with the same level of access and privledge as the kernel since we do
not employ any sort of level switch (i.e. eCos functions are accessed as
function calls, there is no "system call" mechanism being used).

On the ARM, this means that the kernel, and thus the application, run in
Supervisor Mode.

As for the motivation?  Speed and control.  By not using a level switch (aka
system call), applications get the most efficient access to kernel functions.
There is no need for copying parameters and data when making calls, no need
for excessive state savings, etc.  Overall, the application simply gets the
most efficient use of system resources.

Re: [ECOS] ARM cpu modes

[Hugo 'NOx' Tyson]

Colin_Helliwell@Mitel.COM writes:
> Jesper said in a message yesterday that "[ARM] Application threads run in
> supervisor mode in eCos". I've heard/seen it said somewhere that the ARM's
> privileged Supervisor mode was intended for OS-type operations, whilst the
> non-privileged User mode was intended for application-level code. I was curious
> about the rationale behind the choice made in eCos, and whether it is felt that
> there are actually any pros and/or cons of running application threads in
> supervisor mode.

Those distinctions are only pointful if you do stuff like memory protection
(including of IO device) and therefore have a SWI interface to *all* system
services. 
"Big" OS's with processes (=> memory protection and VM) would do this.
"Small" OS's ie. eCos, with threads and one uniform memory space do not.

eCos apps are fully linked, there is no SWI interface, and for performance
reasons, we *want* appliction object files to contain "privilidged"
operations from eCos macros or inline functions.  Device driver code is not
"special" in any way.  For example, cache flushing or sync'ing is usually a
coprocessor operation, which you can only do in a non-User mode.  But it's
only a couple of instructions, so there's no need to put in a clunking
great function with mode changes surrounding it; just put it inline with
the app code.  So it all must run in Supervisor mode.

Actually, we have considered moving to System mode (User mode reg set with
SVC mode privilidges) but it's not available on all ARMs and there ain't
much to gain...

HTH,
	- Huge

-- 
The 20th Century brought unprecedented increases in worldwide numeracy and
literacy and incredible advances in technology, science and mathematics.
It was also the only century in the past or in any reasonable predictable
future apparently to contain only 99 years.