Python OS

[Mike Meyer]

"Diez B. Roggisch" <deetsNOSPAM at web.de> writes:

>> OS's have been written for VMs (LISP and Forth) that didn't have the
>> notion of interrupt before they were built. For LISPMs, interrupt
>> handlers are LISP objects (*). Java may not be as powerful as LISP,
>> but I'm pretty sure you could turn interrupts into method invocations
>> without having to extend the VM.
> How so? An interrupt is a address the processor directly jumps to by
> adjusting its PC. The JVM doesn't even have the idea of function pointers.
> Invoking a (even static) method involves several lookups in dicts until the
> actual code  pointer is known - and that's byte code then, not machine
> code.

No, that's how most modern machines generate interrupts. That doesn't
mean the your JVM-based system would have to do it that way. An
interrupt could trigger a lookup in a privlieged dict to find a code
pointer.


> As your examples show, one can implement a VM ontop of a considederably thin
> layer of low level code and expose hooks that allow for system
> functionality to be developed in a high-level language running bytecode.
> Fine. Never doubted that. I've written myself C-wrappings that allowed
> python callables to be passed as callbacks to the C-lib - no black magic
> there. But that took some dozen lines of C-code, and time-critical
> interrupts won't work properly if you allow their code beeing implemented
> in a notably slower language.

If you followed the link in my last post, you saw a paper on one of
the early LISPMs, which put a virtual LISP machine in silicon. The
same could be done for JVM. However, the success of LISPMs and Forth
in silicon would contraindicate doing that.

   <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.