Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
Why not? Ever heard of bootstrapping? You can write a compiler for a subset of your language in some other language, then write a compiler for your language and compile it with your first compiler. Ta-da, you have a compiler for your language in bytecode.
Yes, I didn't say you can't have a compiler in bytecode. It's just that, eventually, you will need to run something binary (precompiled). In your case, that's the first compiler, along with what core functions it uses (ie malloc) while Johnny's approach includes the little Ruby converter too.
Not to mention (well, Johnny did) the speed issue.
So eventually some things must be binary (native code). Not much of a point saying that, since everybody knew that already. I just wanted to point out that imho the scheduler should be one of these, and the gui shouldn't, as opposed to (OP):
Also, the entire windowing/control subsystem is embedded in the kernel itself.
If you compile something to byte code, then you need an interpreter to run it. This interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it. This other interpreter may be native code or byte code, but if it is byte code, then you need another interpreter to run it.
You need some real code running. You can't keep bootstrapping a bytecode compiler without a native run-time environment and loader.
Compiler A: compiles subset of X, runs on Y, written in Z, compiled to native executable, generates bytecode.
Compiler B: compiles X, runs on your own operating system, written in X, compiled to bytecode, generates bytecode.
First write compiler A. Then you have a compiler which runs on one system and generates code for another system (does it sound familiar?). Then you write compiler B. What do you have now? A compiler for creating bytecode executables on Y and a compiler creating bytecode executables on your own system. Compile the second compiler with first compiler and you have a compiler written in bytecode and your os hasn't even heard of running "real code".
When does your operating system need to run some real code and have a native run-time environment and loader? All "real code" in the path I am talking about is running on some other operating system. When does your operating system need to run something binary (precompiled)? In the path I am talking about your operating system is executing only bytecode. When does your operating system need to implement core functions the first compiler uses (ie malloc)? A HP-UX server a public library uses in my home town doesn't need DirectX because my sister plays The Sims 2.
What then takes the byte code and makes it so it can run on the CPU? That can't be bytecode because then you'd have a chicken and the egg problem. Something in the OS has to be written in native code, because something has to be able to get the byte code (at runtime) into a format that the CPU can use, without actually being written in bytecode itself. The problem isn't getting code to bytecode, it's getting bytecode to the CPU in a bare metal environment.
I think you're thinking about this:
Source->Compiler->Bytecode
We're thinking about this:
Byecode->Interpreter->CPU
The interpreter can't be bytecode, because then how would you start the interpreter? This is the part that needs to be native code.
geomagas wrote:It's just that, eventually, you will need to run something binary (precompiled). In your case, that's the first compiler
I think that sentences mean you have to run "the first compiler" as native and not that you need to have a interpreter in "binary (precompiled)".
Craze Frog wrote:If you compile something to byte code, then you need an interpreter to run it.
I understood this to mean same thing as above sentences, that you need to run the original compiler for the language on your os. But I think I misunderstood this incorrectly.
edit: I just realised how messy this post really is.
The only thing the Kernel would have to run is the VM. (Read: Virtual Machine)
Together with that, you can store some bytecode images on the volume for the VM to load.
Then, you can write your own compiler in your own language, compile, and run again. (Bootstrapping!)
DniFan wrote:The only thing the Kernel would have to run is the VM. (Read: Virtual Machine)
Together with that, you can store some bytecode images on the volume for the VM to load.
Then, you can write your own compiler in your own language, compile, and run again. (Bootstrapping!)
If you don't want to write the compiler in raw bytecode, you need a compiler that is able to generate your bytecode. That means you can't really drop the phase of writing compiler which is capable of that and runs on some other system unless you're Mel II or a masochist who has lots of time for debugging.
DniFan wrote:The only thing the Kernel would have to run is the VM. (Read: Virtual Machine)
Together with that, you can store some bytecode images on the volume for the VM to load.
Then, you can write your own compiler in your own language, compile, and run again. (Bootstrapping!)
Of course, but the VM can't be byte-code. It must be native code. UNLESS you've got another VM to run it. Then, however, this other VM must be native code. UNLESS you've got another VM to run it. Then, however, this other VM must be native code. UNLESS you've got another VM to run it. Then, however, this other VM must be native code. And so on.
You cannot have a programming language that compiles to bytecode without native run-time support and loading (whether you call it VM or interpreter). You can never bootstrap this interpreter as byte-code, even if you call it a VM.
I think everyone got confused when the word "compiler" was introduced into the discussion (from what I can tell it was geomagas' first post in the thread). Some people correctly understood what he meant while some people went with the more literal meaning of what he said and then we had this whole thing where everyone was trying to get the other people to understand their position. I hope this helps clear things up:
The compiler itself (the program that takes the source code and translates it into byte code) can be written in any language and run on any platform that the developer wants. He can then use this compiler to write another one that is compiled to byte code and runs on his OS.
The VM (the program that actually runs the byte code, and what I believe geomagas meant to say) needs to be written in native code, because otherwise it would need itself to run itself. This is the layer between all bytecode-based applications and the CPU and other hardware his OS runs on, a kind of HAL if you will.
By presenting both answers I hope to unify both sides of the discussion and end an age of confusion and despair... or something like that.
All of my code, excluding the source-to-ruby converter (which is written in ruby), is written in my own language. My build process for my kernel consists of converting my compiler to ruby, and then compiling my kernel into bytecode. The kernel is a strict microkernel, in that it only contains the mechanism for scheduling and memory management. After the kernel is compiled into bytecode, I compile bytecode runtime into bytecode.
So at this point I have two programs in bytecode, which are needed to run bytecode. Enter the chicken and the egg problem. To get around this, the kernel and bytecode runtime are translated into native code. My bytecode and source langauge both include support for heavy compile-time known value based optimizations, meaning that a kernel can be tailored exactly for the system it is being run on even though it isn't dynamically translated. For example, there might be a loop in the kernel that checks all the processors in the system to see if they have any tasks running. If the bytecode to native-code translator is informed that the target system has four processors, it can replace this loop with a series of four if statements. It can also inline any references to the processor count. By doing these kind of optimizations at install time, the kernel can obtain the best performance without using a hypervisor or similar mechanism to do the translating.
When booting, my bootstraper checks that the preconditions required for the kernel are met. If they aren't, it either temporarily uses a more generic kernel (if one is included in the boot module) or fails with an error message (if no sufficiently generic kernel is included). An install CD for my OS would boot a generic kernel, which would have slightly decreased performance, and then do the byte-code to native-code translation at install time based on the system it is being installed on.
So after booting, you end up with a precompiled kernel and bytecode runtime, and everything else is bytecode?
I assume the bytecode runtime is (includes) an interpreter for the bytecode?
My approach is somewhat different:
- At build time, I just use NASM the whole way...
- I haven't thoutght about any install process so far, but I'm planning on building a kernel for each potential architecture
- Instead of an interpreter, I'm "designing" a JIT compiler. Source code will be compiled when needed and the native code produced will be cached for later
- The syntax of the language will follow a 3ac dialect
- Processes that need to be arch-specific, as long as a few others, will be precompiled and persisted in the cache
I'm on a very early stage, so I'm not sure if any of the above will change in the process, but that's how I'm planning to go
