Re: Lua OS!

[David Given <dg@...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 23/12/09 18:39, Lyndon Nerenberg (VE6BBM/VE7TFX) wrote:
[...]
> How would you compare this to Inferno and Styx? In particular, were
> things like drivers coded in they byte machine as well, or did you
> have to implement C/asm stubs for the low-level stuff?

Everything was written in bytecode, called VP (virtual processor). It
was a kind of mutant machine code for a machine with 5*2^16 registers:
the five banks were integers, longs, floats, doubles and pointers.
Addressing modes were arbitrarily complex, allowing complete expressions
to be used anywhere you could use a value. Saving registers on procedure
calls was done automatically by the 'hardware' (actually the translator
emitted code to do it). Multiple return parameters were, of course,
supported. And the awesome macro assembler supported high-level
structured constructs. The end result was... peculiar, but powerful. The
total amount of native code needed for a port was usually only a few
hundred lines. We could even write interrupt handling code in VP.

Oh, yeah, plus we had a framework in place that would automatically
translate Java classes into VP, which would then be translated into
native machine code at load time. Yes, there was a JVM JIT *for free*.

There's an example on the 99 Bottles Of Beer page:

http://99-bottles-of-beer.net/language-vp-180.html

...which, er, I wrote.

C and C++ was supported, but C's semantics didn't match VP very well.
The biggest issue was that intent was based around things called tools,
which were small loadable chunks of code, which were translated into
machine code at load time (although you could also write tools in native
machine code). Tools code be called like functions. In that example,
each printf was actually a macro that would push the arguments onto the
stack and call lib/printf.

- From C's point of view, a tool was kind of a program, but only kind of.
Actually working with them was really cumbersome. Tools were referred to
by path, which wouldn't map cleanly onto C identifiers, making them a
pain to call; our VP APIs all used multiple return values, which were a
pain to use; and our statics model was *nothing like* C's... *shudder*

This was one of the things that did for intent at the end: we suddenly
realised that our huge codebase was written in three different dialects
of VP, about four different dialects of idiosyncratic C, and at least
two different dialects of idiosyncratic C++. The end result was that
nobody could maintain (or even understand) our code base except for us,
which is not a good place to be.

- -- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "Under communism, man exploits man. Under capitalism, it's just the
│ opposite." --- John Kenneth Galbrith
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFLM0VDf9E0noFvlzgRAqDbAJ44XXR+BAGj9DELiFb137AS3W0jmACgoeGN
vQhpyfAHz21U+3NR6QqosTg=
=4ROV
-----END PGP SIGNATURE-----