Re: Java on the Apple2 and C64

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

David Schmenk wrote:
> Michael J. Mahon wrote:
>
> > Oliver Schmidt wrote:
> >
> > > Hi Michael,
> > >
> > >
> > > > > 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.
> > >
> > >
> > >
> > > You're surely right that this is something not done with Java byte
> > > code. But my statement above was targeted towards performance and not
> > > code density.
> >
> >
> > And code density is the point I was addressing, contrasted with
> > the relatively "looser" Java bytecode.
>
> Java bytecodes:
>
> iconst_m1    02        → -1    loads the int value -1 onto the stack
> iconst_0    03        → 0    loads the int value 0 onto the stack
> iconst_1    04        → 1    loads the int value 1 onto the stack
> iconst_2    05        → 2    loads the int value 2 onto the stack
> iconst_3    06        → 3    loads the int value 3 onto the stack
> iconst_4    07        → 4    loads the int value 4 onto the stack
> iconst_5    08        → 5    loads the int value 5 onto the stack
>
> from
>
> http://en.wikipedia.org/wiki/Java_bytecode
> and
> http://java.sun.com/docs/books/jvms/second_edition/html/Mnemonics.doc.html

That looks very good!  Perhaps I've misjudged the compaction objectives
of the Java designers.  (After all, it began life as a method for coding
for set-top boxes.  ;-)

> Here is the best p-code description I could find.
>
> http://homepages.cwi.nl/~steven/pascal/book/10pcode.html

This is, I believe, the original CDC 6500 ETH P-code compiler, for which
code uniformity was a higher objective than compaction.  The UCSD team
did many code compaction tunings to the bytecode.

> The JVM looks to have been created with a pretty reasonable attempt to 
> keep code density small.  There are both 16 bit and 32 bit 
> address/offset version of the opcodes.  Honestly, I never looked too 
> much into the JVM, but it looks like a viable platform for a 6502.  The 
> bigger question remains as to the quality of the Java compilers, but I 
> think Oliver is on to something here.
>
> > > > I presume that it doesn't really "decompile", but simply throws away
> > > > the compiled code and reverts to the still available bytecode
> > > > representation.
> > >
> > >
> > >
> > > You're presumption is correct for sure.
> > >
> > >
> > > > 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.
> > >
> > >
> > >
> > > This seems to decribe the same approach I described - or do I miss the
> > > point here ?
> >
> >
> > I agree--and I was pointing out that the practice is over 30 years
> > old, dating back to the very beginnings of time-sharing and interactive
> > computing.  Novelty is hard to come by in this field.  ;-)  Many recent
> > "discoveries" in computing are simply re-discoveries by folks who either
> > forgot about the past or never bothered to learn it.
>
> One interesting application of compiling a opcode comes from the 
> original Windows EGA/VGA driver.  A ROP3 code describes a bitwise 
> combination of source, pattern, and destination.  All 256 combinations 
> would have overwhelmed the computers of the time, so a routine was 
> compiled on the fly to implement the ROP3.  Nobody was sure why you 
> needed a ROP3, but in typical MS fashion, it was 1 better than the ROP2 
> used in other windowing systems of time.  I think they're up to ROP11 
> now (with apologies to Spinal Tap).

In the early days of Windows (or indeed of *any* GUI), the performance
of the "raster ops" was the fundamental limiter on the speed of screen
changes.  By all rights, this routine (and its uses) should have been
the full-time focus of a couple of brilliant engineers continuously
since the beginning of the project.

-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."