OSDev.org

Hi, first of all.

Today while I was learning some Forth, a sudden idea came to me. What if I wrote a Lisp interpreter in Forth so all the low level details that Lisp cannot access can be executed by calling Forth 'words' (basically functions). That way one should be able write a operating system mostly in Lisp and Forth rather than C (I don't like C). If you can't do things in Lisp, like trigger a interrupt, then call a Forth word to do if for you.

Forth by its design is very small and simple so its fast and is so suitable for hardware level interactions. After you have written words for most low level tasks I could write a Lisp (or scheme) interpreter in it. Using this interpreter process management, GUI's and all those lovely things would be much easier than in C thusly I could get a operating system in much less time.

Any ideas, thoughts on viability of it, or am I a Lisp programmer waiting for the prophesied return of the Lisp Machine?

Your proficiency dictates your programming speed, so just go ahead and do what suits you best. Lisp will most likely not be part of any commercial hardware or embedded product anywhere in the future.

Oh and, try openfirmware

Hi Daniel,

The idea sounds good from an academic stand point . Forth is a wonderful language and i very much like its simplicity.
I am myself interested in good algorithms than how to write a driver for device xyz . A system where it is very easy to prototype algorithms would be nice.

--Thomas

hall123 wrote:Any ideas, thoughts on viability of it, or am I a Lisp programmer waiting for the prophesied return of the Lisp Machine?

Yes, and it's a good thing!

I think you'll run into difficult scoping decisions when it comes to hardware access from Lisp. What features do you present to your Lisp virtual machine? How minimal can your Forth hypervisor be? Some examples...

- Your Forth code will definitely need to work with the x86-64 page tables. Should your Lisp VM be able to access them too?
- Your Forth code will want SMP/whatever support. Should your Lisp VM see processors directly, or should they be abstracted beneath the VM?
- Your Forth code might be minimal enough not to worry about MMIO and PMIO devices, but your Lisp OS will definitely want access to those things.

If you go down that road you either end up writing a minimal Lisp environment in Forth and adding tons of unsafe extensions to Lisp to work with the x86 architecture or you write a virtual machine specification for Lisp and implement a complete HAL/VMM in Forth - i.e. a Lisp machine emulator.

Also, Lisp?

http://lambda-the-ultimate.org/node/299 wrote: Bored by those lemmings who use wildly popular operating systems such as the HURD?
Wondering how Arrows might improve operating system design now that monads are ho-hum?
Looking for an opportunity to write a purely functional network driver?

If this sounds familiar, hOp, and now House is the project for you!

Bam!

Actually I've had a project in the back of my mind along these same lines that I've been trying to distill into a post for feedback. If I ever get it written down I'd love your thoughts!

Thanks for the response,

As for what should be hidden or shown to the Lisp environment, I was thinking that from Lisp one should be able to able to access most of the hardware. For example if I was writing a terminal function from Lisp I would do something like:
(set-cursor-and-write (x) (y) (string))
(set-cursor-and-write 20 20 "This is the terminal printing function")

The arguments would be put on stack for Forth and a Forth word like 'set-hardware-cursor' would place the cursor at 20X and 20Y and a second Forth word will write the string.

So basically as much the hardware is accessible from Lisp as possible and what I can't is with Forth. From a protection standpoint user space applications will not have access to hardware control functions, as they could mess everything up, they have to make a system call. But the Lisp OS or programs the user allows have full control over every little detail.

But going on that idea a little, if a Lisp program could issue... ...then your hypervisor is providing a terminal emulator and a windowing environment and a video driver and a font driver and all of the stuff it takes for set-cursor-and-write to exist.

At the other extreme, some hardware concepts don't necessarily work in Lisp - at least not without changing what Lisp is. Interrupts are the first example that come to mind.

There's at least two posters I've seen here with sigs indicating they are working on functional system programming. I can't find their usernames right now but maybe they'll chime in. I think one of the projects involved a new functional language, but I don't know how abstracted from hardware it was.