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