Python OS

[Jeremy Jones]

Richard Blackwood wrote:

> Kay Schluehr wrote:
>
>>> / Richard Blackwood wrote:
>>
>>
>> /
>>
>>> What I do not quite understand is the overall assertion that 
>>> low-level aspects of OS design can not be simulated.  Interrupts 
>>> were much discussed, but I ask: can one not simulate interrupts?  It 
>>> seems absurd to me that this would be impossible.  
>>
>>
>>
>> This is indeed trivial. It can be reduced to the statement that the 
>> Python language is Turing-complete. What remains unclear in this 
>> discussion is the perspective on "Python". Somewhere we have to leave 
>> the sim in order to run a concrete
>> system. 
>
>
> What does this mean?  Run a "concrete system"?

And why do we have to leave the sim?  I've said that I don't care if the 
virtual operating system talks to real hardware or not.  Actually, it 
would be really cool if it didn't.  Richard seems to concur with this 
for his purposes.  So, if Richard doesn't care about talking directly to 
hardware, then the sim _is_ the concrete system.

>
>> The different high level representations of the concept "hardware 
>> interrupt" have to be projected onto one and only one that is 
>> feasible by the machine. If I interpret Your concerns correctly, You 
>> obtain a greater flexibility on the sim-level, which should influence 
>> again the "real" OS machine code?
>
>
> If possible but not a necessity.

I would envision a virtual machine (read, a piece of software that 
emulates processor, storage devices, etc) **written in Python** which 
provides the faux low-level system calls to the operating system **also 
written in Python** which does the things that real operating systems 
do.  Such a system could be as simple as emulating an 8-bit processor, 
tape drive, keyboard for input and line printer for output, 64KB of 
RAM.  Pretty much a useless OS/hardware platform by today's standards.  
I don't think Richard ever was meaning prototyping for the purpose of 
creating a functional OS not in Python.

>
>> The model of this relationship is Psyco in the PyPy realm: being 
>> itself a Python program, that generates machine code on the fly that 
>> drives again the interpreter, that runs Psyco. But this tangled 
>> hierarchy in which OS and Python-Interpreter drive each other may
>> be my own fantasy, that has nothing to do with Your "prototyping" 
>> intention
>> in the closer sense ... ?
>
>
> It may have a home in my intentions, but a splendid fantasy regardless.
>
>>
>> Regards       Kay
>>
>>
>>
>>
>>
> - Richard B.


feeling-like-i-am-beating-a-dead-horse-ly y'rs,

Jeremy Jones