Can an Operating System be written un C-unlike programming language

[Lee Salzman]

Hey, one step at a time. I've still got an optimizing compiler to finish.
That's the difficult part. :)

Interrupts are none too complicated, more or less what you said.
You have some stubs in assembly that handle acking the PIC and
dispatch to some Slate code, not really too different than how the
current VM deals with asynchronous signals.

As for drivers, there really is little need for assembly. Memory-mapped
IO, and even x86 IO ports, can be wrapped as Slate methods. You
only need assembly just to handle various processor functions.

But really, this is all best left  undiscussed right now until the compiler
is done. I'd rather the OS be less wishful thinking and vapor than something
that will just happen as a natural progression of self-hosting. I know how
to do it, it's no big deal, and it will happen when the time is right. 
It's just a few
little drivers. Nothing to see here, move along. :)

The discussion effort is better spent on the issues like the UI and 
development
system (which need the attention!), which regardless form the basis of any
interaction with Slate. Take Squeak for example. I can bolt it directly 
to the hardware,
but it little changes my Squeaking experience except for getting rid of 
the instances
where I have to escape from Squeak to do things.

Lee

Steven Shaw wrote:

>On 5/11/05, Lee Salzman <lsalzman1 at cox.net> wrote:
>  
>
>>It really is dirt simple to write an operating system in Slate.
>>    
>>
>
>Cool - let's do it!
>
>I think makes more sense to use an existing bootloader such as grub
>rather than rewriting one.
>
>I don't know what you mean by interrupt stub. Don't some some parts of
>drivers (I think they call it the top-half in Linux) need to be
>interrupt/trap free? Are you saying that that part can be written in a
>general way, handing off to regular Slate code? The Slate code becomes
>then the "bottom-half" in Linux-speak. I though that the top-half must
>reply to the hardware in most cases, so I guess that means there would
>be some assembly required in most hardware drivers...?
>
>There will probably also be some assembler parts to handle
>synchronisation primitives and maybe task switching... yes?
>
>Steve.
>
>
>  
>