Separating bytecode interpreter and classes

[Andreas Koch]

Hi all,

just a weird idea.

I am developing an interpreted language (bytecode
interpreter) for a very limited machine.

Now, i could invent my own bytecode.
Or i could adapt java's bytecode engine.
I don't know very much about java bytecode yet;
Just that it is 32-bit stack orientated.

Note that the device is too limited to hold
more than an interpreter for an simple bytecode,
plus a minimalistic api (writechar,writeint,
readkey etc). It couldn't handle the class
libraries, not even the J2ME ones.

So

1) Can the java bytecode machine be separated
from the classes and other dependencies
(garbage collector?) so it can serve as "just an
intepreted stack based assembly language"

2) If this can be done, can the usual java
tools (read: java compilers, debuggers, etc) be used
to write code for this machine ?

 

[Chris Uppal]

1) Can the java bytecode machine be separated
from the classes and other dependencies
(garbage collector?) so it can serve as "just an
interpreted stack based assembly language"

I doubt it very much.

You could certainly generate bytecodes that made no use of anything but
primitive types, and in that sense you would be independent of the GC, etc.
But the JVM is intimately aware of the Java class library; it "knows" about
java.lang.Object and java.lang.String. It represents classes (to some degree)
by instances of java.lang.Class, and I think it may also be necessarily aware
of java.lang.ClassLoader. And, of course, all JVM code resides in methods, so
the JVM has no conception of executable code that is separable from the OO
world of classes, objects and methods.

Then too, the classfile format is not especially compact (which sounds as if it
may matter to you) nor especially easy to parse (which will affect the
complexity/size of the implementation).

In all I don't think you'd get very much from trying to use a JVM. The problem
(from the perspective of your application) is that JVM bytecodes are *not* a
low-level representation. In fact JVM bytecodes form a language that is at
least as high-level as Java itself (arguably higher).

What you *might* be able to do, though, is choose a subset of the JVM bytecodes
(the ones that do primitive arithmetic, array access, and stack ops) and write
a small interpreter for just that subset. That should be quite easy. With a
bit of messing around you could arrange that your tools generate either genuine
JVM classfiles (that "happen" only to use that subset) or whatever "classfile"
format you decide to use for your own project. Or perhaps it'd be easier to go
the other way, and use javac for compiling a subset of Java (that uses only
static methods and never directly creates objects) and then write your own
tools to extract the bytecodes from the resulting .class files. If you do that
then you may be able to leverage Java tools for *some* debugging, or even write
a real Java emulation of your target device that "executes" your instruction
set by loading it directly via a custom classloader.

Just a thought...

-- chris

 

[Thomas Weidenfeller]

Note that the device is too limited to hold
more than an interpreter for an simple bytecode,
plus a minimalistic api (writechar,writeint,
readkey etc). It couldn't handle the class
libraries, not even the J2ME ones.

Instead of Java, consider a FORTH machine as the
OS/interpreter/compiler/assembler (yes, all in one). There are still all
the free implementations for 8 bit microprocessors and 64k main memory
out there.

/Thomas