Re: Java on the Apple2 and C64

["Michael J. Mahon" <mjmahon@aol.com>]

Oliver Schmidt wrote:
> Hi,
>
>
> > > Looking at the NanoVM 
> > > implementation and having looked at the code cc65 generates, I'm 
> > > actually amazed and impressed that it works so well.  I bet a hand tuned 
> > > 6502 JVM implementation would be close in performance to the 6502 
> > > p-machine.  Compiler differences would be interesting.  One would think 
> > > compiler technology had advanced in 20 years and the advantage a Java 
> > > compiler would have by running on *big iron* vs. a p-system based Pascal 
> > > compiler should give the edge to Java.  An intriguing subject.
> >
> > I would be very surprised to see *any* high-level implementation of
> > an interpreter get within a factor of two of the speed of a tuned
> > assembly version--particularly if the interpretive operations are
> > low semantic level, like "add 16-bit integer".
>
>
> I don't think that Java byte code is large or "loose", in fact in my
> opinion the opposite is true.

It's been years since I looked at Java bytecode, so I'll have to take
another look.  I presume that this is a very stable definition, since
portability would demand it.

> Writing a Java interpreter in 6502 assembly would most probably bring
> Java close to the p-machine.

IIRC, the p-machine has single-byte operations that push common
constants and designate parameters, for example, without an additional
operand byte.  These coding cases were chosen to minimize code size
in a way that few bytecodes attempt.

> > The problem with compiling "all the way" is that it takes a lot more
> > space than a compact bytecode.
>
>
> That's the key! At work I was several years dealing with analyzing and
> building Java VMs. The very advanced technology currently is Sun's
> HotSpot VM. It's a great example of not compiling all code but mixing
> interpretation and JIT compiling. Most people don't know that the
> HotSpot VM even 'decompiles' code, which means it throws away compiled
> native code and instead uses the interpreter again !

I presume that it doesn't really "decompile", but simply throws away
the compiled code and reverts to the still available bytecode
representation.

This is actually a quite venerable technique, known as "throwaway
compiling", and was originally part of a strategy in which compiled
code was kept in a size-limited buffer, and the least-recently-used
parts were simply thrown away when newer code needed to be generated.

So the compiled code was managed just like a page working set, or
a code cache.  Some CISC chip microarchitectures have taken a similar
approach to translating their advertised "machine code" into their
native RISC-like instructions.

The original RISC principle was to do as much as possible once, at
compile time rather than repeatedly at execution time, and these
techniques are points on a continuum of approaches between "fully
static" translation and "fully dynamic" execution.

-michael

NadaNet file server for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."