Who's right??

[Kemp]

Nope ;D I'd be a very happy person if I had it nailed to the point of being able to take screenshots (and in fact a graphical interface is the very last thing on my list). Most of it is on frantically scribbled pages of my own wierd style of pseudo-code, I've set myself a rule that I won't write up the kernel before I get the bootloader sorted otherwise I'll spend all my time tweaking the kernel and get complacent using someone else's loader and end up never fixing it.

[mystran]

Now, let's make it clear:

Any programming language that can be implemented on a general purpose computer can be compiled. The theoretically most simple way is to partially evaluate the interpreter of the language with the program to be compiled as it's partial input. In practice, this way works, but might be suboptimal, and is everything but simple (unless you assume that you already have a suitable partial evaluator).

Now that we know that we can compile (to binary, native opcodes, whatever you want) any programming language whatsoever that ever can be implemented at all (see G?del's Incompleteness Theorem), we can concentrate on what exactly we need from a programming language in order to implement an OS with it.

One thing is that unless we are willing to write a runtime system with some other language (say, assembler) we require that we can compile the program into a form which requires no runtime system. This is much stronger property than mere compilation, although it too can be satisfied quite simply: require that the interpreter to be partially evaluated (yeah right) actually implements any and all of the required runtime. Seriously, the need for runtime is the real reason why most languages aren't that good for OS development.

Finally, it'd be nice if we could predict what happens on the machine level when we compile certain code. C language is remarkably nice in this, as anyone familiar with both C and Assembler can certainly translate most C expressions into equivalent blocks of assembler. GCC inline assembler constraints also help in this, because you can assume that certain registers hold certain values.

PHP actually isn't very hard to compile. In fact, it's more or less comparable with C++, Java or pretty much any other block-structured language. Dynamic typing adds some performance overhead ofcourse. For long running computations (like an OS kernel) you'd also need some runtime like garbage collection, although it might be possible to write that runtime in PHP itself (at least if we also wrote the compiler). I think some Scheme compiler actually did that, don't remember which one though (T?).

Why one would want to use PHP is beyond me though. PHP is a pretty ugly language, and lives mostly because it has a superb standard library. Take the library away, and the language sucks.

[Pype.Clicker]

Considering all i can find when googling for "PHP compiler" is programs that "makes your PHP script standalone by embedding them altogether with a PHP interpreter in a .EXEcutable", i really wonder why i haven't locked this thread yet.

Probably because noone worries about alix-vs-iceo kiddies question.

[Candy]

Then allow me to finish this thread off. It's served its purpose and does not hold any future purpose, except educational (and it can do that in the far historic reaches of Mega-Tokyo instead of on the first page).