Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
ehird wrote:An OS in Lisp? Interesting. What compiler are you using that gives you the low level access required? I thought Lisp OS' were a thing of the Lisp Machines and nothing past that
It's interpreted (ill might use some bytecode compiling stuff if im up to it). I'm designing for the next gen processors
A compiled Lisp would defeat the purpose of my OS, which is an OS which can rewrite itself run-time. It's more of an experiment than something functional. I will forgo memory protection, so that this can be fully exploited.
The interpreter will run atop a very small (couple hundred byes) nanokernel written in ASM. The hardest part will be implementing Lisp in pure ASM [/b]
I suggest you implement your Lisp in Lisp, by having a compiler capable of compiling to native code. That'll make your life much easier.
It also means you'll then able to compile code at runtime. This has nothing to do with rewriting at runtime. The important thing for rewriting at runtime is having extremely late binding, such that you rely on basicly one hard-coded thing: resolving symbols. Even that can be made latebound after the system has started, by simply having closures carry references to the other closures they need to call.... which in case of eval and compiler would include the symbol resolver..
The biggest pain with the whole thing then is garbage collecting code. There's nothing theoretically very hard, but if you want to compact the area where your code lives, you need to have your code relocatable by your garbage collector, and you need to be able to fix your stack to reflect those relocations.
...
I've got the start of a project that's kinda supposed to do that, though I'm at the stage of having my compiler compile my Lisp dialect, the compiler itself running in MzScheme, outputting GAS (there's no integrated assembler yet) and missing 99% of all runtime..
ATM I'm doing more conventional OS dev though.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
I'm not too worried about efficiency, the design itself is inherently inefficient and making it more efficient would insubstantial.
What I mean by rewriting is macros. Compiling into machine code sounds hard, and I'm not really up to the task. How are you licensing your compiler, it would be VERY helpful.
I'm sticking w/ ASM for the nano-kernel, hopefully it will pay off and I can keep the nano-kernel REALLY tiny.
My kernel has 16Kb and the more advanced features it has is incipient disk partition detection, as well as the basic keyboard, timer, floppy, an incipient memory manager and other miscellaneous things.
