thoughts about Tunes OTOP & JavaVM

[Basile STARYNKEVITCH]

[[Faré réponds moi vite à tout ca STP]]

Hello All,

I do agree with Faré's interest in providing Tunes On Top Of Posix
[=OTOP] (actually Unix ou Linux).

Of course, making Tunes OTOP (or some kind of reflexive system OTOP)
is a different goal *in the short term* than making a Tunes from
scratch, running on commonly available naked PCs. Like Retro and other
want to do.

I am interested in both goals (ie a Tunes on bare naked metal [=OBNM]
& Tunes OTOP).

Actually, I'm even more than interested. I'm trying to code some
starting part of OTOP. (on the other OBNM side, I did try and failed
with KUT. This was in retrospect an interesting failure, since I
learned things. Perhaps I should have tried morer intensively using
OsKit)

My current tiny effort (called AARON -to avoid rude words in languages
I don't know, I'm now sticking to biblical names) is on the OTOP side,
but exclusively aimed to Linux on x86 PCs; it should have:

* a small precise generational copying garbage collector, capable of
  collecting code objects (this means handling the return address in
  stack frames as some kind of [offseted] object pointer). This is
  coded but not tested. The main -tricky- point is that the executed
  machine code itself belongs to garbage collected objects (that I call
  code objects). Since the GC is moving, it has to perform some
  relocation (ie a CALL x86 machine instruction should be relocated
  when either the callee or the called object is moved by the GC).

* a tiny persistent facility: currently I want to have what SML/NJ
  calls export: the full heap (at least all objects reachable from a
  given roots) is exported into an executable (Linux ELF) binary file.
  Aaron will produce an object .o file -containing the heap and its
  relocation- which could be linked with the runtime library. This is
  not fully coded, but I am working on it. (generating ELF
  relocatable objects involves some boresome tricks).

* a machine code generator. Nothing done yet (but the GC does require
  some coding convention at the machine code & binary layout
  level). I'll probably not have a stack machine as the intermediary
  format. Probably will compile some 3 address macroinstructions into
  machine code. I just have some crude design ideas. The generated
  code would be innefficient.

* some tiny (graphical or terminal) user interface. I don't want to
  code in Scheme (or any textual langage) since I do think that a good
  "intelligent" user interface is very important. Emacs is not good
  enough (I would like, for instance, type based dynamic symbol
  completion). Nothing done or even thought at this level. Perhaps
  I'll just code with Gtk some kind of "terminal" (like xterm in
  spirit) handling some kind of "XML" -or reduced HTML- (instead of
  tty or curses capabilities).

- As a disgression, I sometimes think that Tunes would need a low
  level (eg a bit more than C) langage but with high level interface:
  interactive syntactic and semantic checking, browsing,
  completion. But this by itself is a whole project.

Now my progress is quite slow... I was thinking that perhaps starting
from JavaVM would be better. Here are my random thoughts on it.

* I do hate Java (the langage). I don't like what Sun is doing with
  it. But JVM is a working intermediate level langage. JVM has a lot
  of defects, but it exists and is widely used and ported. (in that
  sense, JVM succeeded where ANDF failed, as a widely available
  intermediate level language).

* I have very few experience with Java and the JVM. (but I read the 3
  Java+JavaSpec+JVMspec books) I do know that it is not as portable as
  Sun claim it is. I don't know in practice how is Java nonportable
  (is it limited to system [eg filenames] & GUI issues?)

* Some good enough JVM exist on Linux, notably Kaffe (which has a
  rather slow JIT implementation, dynamically compiling methods into
  very bad x86 code).

* The JVM gives us at once what takes me weeks (of spare time) to
  code: a garbage collector and a code generator (or interpreter). The
  new JDK1.2 has some kind of object serialisation which might be
  useful for persistency

* Kawa (a Scheme above JVM) exists and more importantly have
  interesting packages (gnu.bytecode to write JVM .class files &
  gnu.expr to generate JVM bytecode from a Schemelike abstract
  langage).

* Java is supposed to have some easy GUI.

* a Tunes on top of Java could be very widely used (even if JVM is
  inefficient)

The big points against JVM are

* Java implementation is not free software!

* Java is not an interesting langage

* JVM is not a good intermediate langage (but it does exist)

* JVM Classes are perhaps not always GC-ed (but they should)

* To generate code one have to generate a JVM bytecode .class file (or
  bytearrey?) and load it into the JVM.

* JVM are inefficient. We are losing at least a factor of 3.

Again my point is not to code in Java, but to generate JVM classes
files and make a Tunes on top of JVM. This would be easier that Tunes
OTOP.

For Kawa see "http://sourceware.cygnus.com/kawa/" &
"http://www.cygnus.com/~bothner" &
"ftp://ftp.cygnus.com/pub/bothner/kawa-newest.tar.gz"

Also, tya  "ftp://gonzalez.cyberus.ca/pub/Linux/java/" is a JIT for Linux.

For Kaffee ((JVM with JIT) "http://www.kaffe.org" &
"ftp://ftp.transvirtual.com/pub/kaffe/"

Any thoughts about Tunes on top of JavaVM (=Tunes OTOJVM) instead of
Tunes on top of Posix - which would only be, in my opinion, Tunes on
top of Linux/x86 for some time.

(BTW, I'm still working on AARON: I didn't gave up yet, but I find the
progress very slow, and I'm working for weeks on non interesting non
reflective things)

-- 
Basile STARYNKEVITCH - 8 rue de la Faiencerie, 92340 BOURG LA REINE (France)
tel 01.46.65.45.53. email = basile point starynkevitch at wanadoo point fr
http://perso.wanadoo.fr/starynkevitch/basile 
antispam: <abuse@wanadoo.fr>