LLL: Re: More thoughts
Mike Prince
mprince@crl.com
Mon, 31 Oct 1994 16:16:29 -0800 (PST)
On Mon, 31 Oct 1994, Andy Thornton wrote:
> Virtual Processor
> -----------------
> ... I would suggest that any extra
> registers on the host processor be used as the top entries (the most used)
> of the stack which should speed execution.
Bingo! You're on the same wavelength as me.
> I would discourage the use of multiple code versions in a single
> executable - it seems at odds with the philosophy of "one binary for all"
> which is so central to the project. Also if these objects are to be
> migrated then keeping the size down is an important consideration.
Agreed.
> High Level Language
> -------------------
>
> The argument that this has to be portable holds no water because we have
> the virtual processor for portability so we can use any language that we
> want. If we want to get the system widely accepted then a range of
> application programming languages must be catered for and I would be
> inclined to avoid tieing ourselves to tightly to any particular
> language's object model.
That's our argument for making PIOS a foundation piece of software.
MOOSE can sit on top and provide one flavor of OS. But I would like to
encourage others to experiment with their own high level OS "flavors".
> Real Processor Interfacing
> --------------------------
>
> We should have some kind of system for identifying the specific strengths
> of each real processor in the system - ie. if the processor supports
> floating point in hardware. Some indication of the speed of the
> processor and it's current load is also required.
I proposed that each tool box come with a very small tool exhibiting the
larger tool boxes behavior, a sort of benchmark tool. The OS could
sample the speed of this code snippet to determine which processor
performs the best.
> If we intend that the micro kernel should be compiled down to the virtual
> code we will need some form of boot strapping translator to get us a
> running kernel - it's a bit of a chicken and egg problem...
I think we can make the microkernel so small that it will be programmed
in C (arguments pro/con) and a little assembly HAL. It will basically be
a loader and compiler/interpreter, task switcher, and some other very
basic functions. I want to move as much as possible out of the kernel,
including the kitchen sink.
Let's see how small we can make it.
Mike