OSDev.org

It's definitely been asked before, but I've read over SICP's "Designing Register Machines" and I went around and did some research. So far as I've found, there are three big projects I've found. I'm sure it's not all projects but I've found these to be the most relevant and understandable.

1. DreamOS is based on Dream Scheme, a scheme interpreter built in x86 assember. It's implementation I have to disagree with as it's not very efficient processor-wise, but then again, it's based on a CISC so I can't expect perfection.

• Armpit Scheme Interpreter is another Scheme interpreter but for ARM Microprocessors. It's extremely small and as far as I can tell, fairly fast as well. I have not tested it as they provide no binaries and I don't have an ARM processor to test on nor feel like setting up a crosscompiler when I can read the assembly just fine.

1. Movitz is an on-the-metal Lisp (not Scheme, exactly) interpreter for the x86. It provides some ability to manipulate the x86, but it's not perfect either.

The problem that I see is not that Scheme is a high level language, but that these approaches involve interpretation of manually input scheme code. To have an effective operating system, loading text to interpret is not only a security hazard, but also involves ugly hacks (like DreamOS) to read from media that may not be present. As for Armpit, well, the same problems with interpretation present themselves.

I learned Scheme by a friend who is a developer that works on Chicken Scheme. Chicken boasts many features, three of which are very important to this idea: One, it is capable of converting Scheme into C code of which the binaries have almost (no exact figure) native performance; two, it's also got a very nice FFI interface and is capable of being compiled along with other regular C code; and three, it represents the quintessential implementation of "continuation-passing style" for functional programming.

My idea here is simple: rework the Chicken Scheme compiler to make relatively free standing C code, using machine-dependent assembly for the core primitives for things like the processor-machine HAL, memory allocation, string and integral/floating-point operations, as Armpit does for the ARM Microprocessor. This way, I get the benefit of Scheme's functional programming paradigm compiled into native code for a given processor, without the problems associated with interpretation and loading of code from a medium.

What are your opinions on the idea?

I think it would be it would be really cool as an exercise in programming, but scheme is not really made for this kind of thing. Ive used chicken scheme before, and the output is very very ugly, mostly a bunch of define statements. However I plan to check out DreamOS. A scheme kernel is virutally useless, but conceptually a really cool idea

yemista wrote:I think it would be it would be really cool as an exercise in programming, but scheme is not really made for this kind of thing. Ive used chicken scheme before, and the output is very very ugly, mostly a bunch of define statements. However I plan to check out DreamOS. A scheme kernel is virutally useless, but conceptually a really cool idea

Yes, it's not pretty. It's a Scheme-to-C converter. That's like saying GCC's internal headers are not really made for "this kind of thing" because they use the C preprocessor. It still compiles the software, so what's the big deal?

I'd like to see an operating system that's basically a big Emacs, but I don't think that converting the Scheme to C is the right way to do that. Far better would be to go the microkernel route: write a small interpreter in C that abstracts the hardware and interprets the Scheme code.

$0.02

JackScott wrote:I'd like to see an operating system that's basically a big Emacs, but I don't think that converting the Scheme to C is the right way to do that. Far better would be to go the microkernel route: write a small interpreter in C that abstracts the hardware and interprets the Scheme code.

$0.02

I just don't think interpretation-by-default is going to work, for some of the reasons I've already stated. Mind you, with libchicken compiled into the kernel, CHICKEN_load() can load a precompiled object (under linux it can load shared libraries) OR script code and it immediately becomes visible so making things extensible that way is very easy. I figure it might be a neat way to approach using scheme in such a bare-metal environment.

JackScott wrote:I'd like to see an operating system that's basically a big Emacs,

Wait, Emacs isn't just a big operating system?

So far I have done two progs in Scheme, and both of them are mathematical. Due to this fact (that I'm a Scheme noob) I can't conceive a useful command line program written in such a language, let alone an operating system. However, if you think that's plausible, I suggest making a network-oriented kernel and cut the hardware out as much as you can (using other OS' to access it - a mainframe-like server?). JackScott's suggestion sounds best. But if you're a Scheme master and don't want to listen to us Scheme noobs, I heard Stalin compiles fast code - http://sourceforge.net/projects/stalin/.

paxcoder wrote:So far I have done two progs in Scheme, and both of them are mathematical. Due to this fact (that I'm a Scheme noob) I can't conceive a useful command line program written in such a language, let alone an operating system. However, if you think that's plausible, I suggest making a network-oriented kernel and cut the hardware out as much as you can (using other OS' to access it - a mainframe-like server?). JackScott's suggestion sounds best. But if you're a Scheme master and don't want to listen to us Scheme noobs, I heard Stalin compiles fast code - http://sourceforge.net/projects/stalin/.

It's about the benefits of functional programming and the realization of operating system specifics as a manifestation of delimited continuations. From a purely software standpoint, there is no mutation of global state and thus no limitations with regard to concurrency or scalability. Sadly, from a hardware standpoint, the CISC doesn't help the situation and most of my problems come from trying to work around the ingrained semantics that hardware manufacturers seem to think are useful. Don't even get me started about the BIOS.

syntropy wrote:Sadly, from a hardware standpoint, the CISC doesn't help the situation and most of my problems come from trying to work around the ingrained semantics that hardware manufacturers seem to think are useful. Don't even get me started about the BIOS.

What's the problem? Any examples?