Re: Generating Java Bytecode

On Mon, 18 Nov 1996 gleeh@tulletts.sprint.com wrote:


> Does anyone have an opinion on generating bytecode for languages other
> than java ?


The answer is yes, you can produce a compiler to bytecode for all and
every language, indeed it is a hell of a lot easier than writing a
compiler to machine code. (Why? a) Real assembler languages have all
kinds of strange unfeatures and weird limitations and kookie register
files etc. etc. b) You choose the byte code and _design_ it to be easy
to compile to and easy to interpret.)


Next time you pass a calculator shop have a good look at the HP48G
series. It has a programming language called RPL (Reverse Polish Lisp)
To me this thing has been an epiphany. RPL is a full featured with
knobs on everything object oriented buzzword compliant programming
language that doesn't need a parser! (The trick is everything coming
by gets eval'd (unless quoted) and the result goes on the
stack. Functions collect their arguments off the stack and leave the
result on the stack after they're eval'd. Exactly like lisp but
instead of (fn arg arg arg) its arg arg arg fn. )


Now the point of this digression is that _syntax doesn't matter_. The
power or otherwise of a language is determined way down at byte code
level or semantic level. If the byte code can do it, then the it is
possible (but not neccessarily so) that the top-level language can do
it. If the byte-code can't, then the top-level language has no chance.


> So far as I can see it's not Java that the clever idea its the
> universal machine language (bytecode) that it produces.


Now this is where all this philosophy relates to Java. It is safe to
download an arbitary Java Applet and run it because all nasty
misbehaviour is forbidden at the byte code interpretor level (built
into the browser).


Conversely there may be some features in your favourite language that
could not be recreated in Java byte code. In which case you would be
stuck to a subset of that language. In particular, as John the
moderator points out, C's very unsafe pointer arithmetic, and also
access to C's very unsafe run time library.


> [Universal machine intermediate languages go back to the 1950s, and
> they've never worked. From what I've seen of the Java intermediate
> language, it works fine for Java, OK for Ada, not so great for anything
> else. In particular, it specifically doesn't include C's wild 'n' crazy
> pointer rules. -John]


The reason I can see for the failure of Universal Intermediate
Languages is that it would require in some sense a Universal
Semantics. Which would imply that there has been no fundamental
advances in language design since COBOL.


Yes, I am all too aware of the conjecture that all languages are of
equivalent "power" in the sense that anything that can be computed by
any language can be computed (in principle) by a Turing Machine. But,
and this is the big but, the whole point of an intermediate language
is to make the compilation/interpretation process easier. Thus
compiling C++ to Turing Machine is in principle possible but in
practice a horrible mess (but maybe easier than compiling to 80x86
;-)). Compiling C to Java byte code is in principle possible, but in
practice not so fun. (It can be done. Just declare memory as a huge
java array and C pointers are then integer indices into this memory.)




John Carter EMail: ece@dwaf-hri.pwv.gov.za
Telephone : 27-12-808-0374x194 Fax:- 27-12-808-0338
[Portable bytecode languages have been around for a long time and have been
quite popular. UCSD Pascal was the best known, but there were a lot of
application languages like the Dataflex database. The most unusual thing
about Java is the design that lets an interpreter do a lot of the validity
checking in one pass before it starts to interpret the bytes, combined with
the OOP multiple-domain stuff to let mutually hostile apps co-exist. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.