Re: Java on the Apple2 and C64

[ol.sc@web.de (Oliver Schmidt)]

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.

>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 ?

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

Interesting aspect - at least to me - that this type of consideration
was/is applied to hardware designs as well - and especially that the
CISC vs. RISC discussion can be seen in this metrics.

Best, Oliver