Valix: An OS, a Plan

[xvedejas]

I'm doing a (free) operating system (just a hobby, won't be big and professional like linux) for 32-bit PCs . It's called Valix, and it's a multiboot compliant pmode OS with memory protection. Valix so far has mouse and keyboard drivers, as well as a textmode VGA driver and a virtual file system; I'm planning on adding preemptive multitasking as well soon. Valix will be licensed under the GPL version 3, though I have yet to really release it.

What I'd rather discuss are my plans for the operating system as a whole. Valix is written almost entirely in C, but I'd like all its userland applications to be interpreted by an interpreter that is integrated into the kernel. I'm not entirely sure on the implementation, but I'd like the planned scripting language to be similar to either smalltalk or python, maybe a subset of one or a mix of both. This interpreter will act not only as the system shell but also as the runtime for all applications. I wonder what this plan might entail. Here are some speculations:

- Since the kernel interprets everything, and essentially has control of all processes, is it necessary to have any sort of kernel/user separation? (ring 0, ring 3) The only machine code in the memory would be kernel code.

- Would there be a way of speeding up user applications, since the interpreter is part of the kernel? Of course the interpreter wouldn't be as fast as pre-compiled C code, but could the kernel handle certain optimizations in the way it interprets the code? I'm thinking for multitasking, instead of having multiple interpreter processes, only one interpreter that switches between which script it is interpreting? I'm not an expert on how multitasking works, so I don't know how feasible this is.

- Does anyone have any experience with interpreters? Where are some good places to get started learning their internals? The wiki, at least, offers no information on this, understandably; creating programming languages is usually more separate from OS developing.

All these questions are asked to make sure that I complete my goal The Right Way (tm). If anyone is interested in my fledgling OS, I could probably scrape together some source code , though I remind everyone it is a work in progress. Thanks for help, discussion, critique, etc.

note: I put this in design and theory mostly because I'm not stuck on one implementation flaw but rather I'm wondering about the whole idea behind interpreters and what that might mean for my OS.

[Combuster]

is it necessary to have any sort of kernel/user separation?

Yes, there should be. However, if you are interpreting things you can use software isolation so you don't need any rings or paging for the system to be safe.

Would there be a way of speeding up user applications

JIT / Ahead of time compilation? Trace cache methods? They all involve changing the code into something closer to machine language. It only wouldn't be pure interpretation anymore.

- Does anyone have any experience with interpreters?

Standard approach: Get a parser for the language and do something with the output. In case of an interpreter - perform the mentioned tasks. While a python interpreter would be a far bigger project than the execute-script-to-set-up-shader-values I once built. Oh well: University literature on the subject pretty much gives you all the theory to get started.

[salil_bhagurkar]

Having your interpreter switch between script it is interpreting can be more optimized than doing host processor based context switching. Having an interpreter will give you preemptive multitasking even without support for it from the host processor code. This means that you have well defined context switch (script switch) points in your system, making it better for processor caches IMHO.

But you would need to have preemption for the kernel land if you intend to make it tolerant to bad device drivers which might get caught in loops, for real time constraints and for interactivity needs.

[yemista]

If you plan to only ever run programs though a kernel interpretter, you dont need memory protection either. Essentially the program you run will be a text file, so the kernel can control where in memory it executes the code.

[xvedejas]

Yes, there should be. However, if you are interpreting things you can use software isolation so you don't need any rings or paging for the system to be safe.

Ah, yes, I meant aside from software isolation. I guess this simplifies certain things as well.

JIT / Ahead of time compilation? Trace cache methods? They all involve changing the code into something closer to machine language. It only wouldn't be pure interpretation anymore.

I might think about compiling to bytecode, but I don't want to directly run any machine code. The question was really asking about multitasking, use of memory, etc, however.

Standard approach: Get a parser for the language and do something with the output. In case of an interpreter - perform the mentioned tasks. While a python interpreter would be a far bigger project than the execute-script-to-set-up-shader-values I once built. Oh well: University literature on the subject pretty much gives you all the theory to get started.

Thanks for the link. I think I'll end up writing my own parser, since I don't see it being easy to port anything to my OS since it doesn't have standard C libraries.

Having your interpreter switch between script it is interpreting can be more optimized than doing host processor based context switching. Having an interpreter will give you preemptive multitasking even without support for it from the host processor code. This means that you have well defined context switch (script switch) points in your system, making it better for processor caches IMHO.

Yes, that's what I was thinking of. I'm just wondering were to start...

But you would need to have preemption for the kernel land if you intend to make it tolerant to bad device drivers which might get caught in loops, for real time constraints and for interactivity needs.

Yes, that's a good point. But what does this entail for the interpreter? On the other hand, that would be good motivation not to write bad drivers

I understand the basics of parsing, but I wonder how to make objects work. I suppose using C structs would be a good starting point, but then how to implement inheritance? I'd have to combine attributes of different structs or something every time I subclass an object.

I also wonder how to implement the context switches; I guess I'd need to store all the information from one interpreted text file when I switch to another (what variables stand for, defined classes, current position in code, etc). But again, I'm not sure how this would be accomplished.

[mathematician]

What I'd rather discuss are my plans for the operating system as a whole. Valix is written almost entirely in C, but I'd like all its userland applications to be interpreted by an interpreter that is integrated into the kernel. I'm not entirely sure on the implementation, but I'd like the planned scripting language to be similar to either smalltalk or python, maybe a subset of one or a mix of both. This interpreter will act not only as the system shell but also as the runtime for all applications. I wonder what this plan might entail. Here are some speculations:

I have got to admit that I don't really see the point, but if you really want to roll the clock back about thirty years, and again machines whose only OS was a BASIC interpreter (or whatever other language you want to invent), then you need to read up on recursive descent parsers.