[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Java on the Apple2 and C64

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.


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.


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.


Of course, this applies primarily to CISC processors, for which the
major complexity is in their firmware rather than the usually RISCy
underlying hardware.  The x86 processors are a prime example.

The dynamic compilation approach that has the most practical promise
at the moment is dynamic optimization of running machine code, directed
by real-time profiling.

Since most programs now involve very high frequencies of module-
crossings, and most modules are independently compiled, it is only
at runtime that the actual content of many loops becomes evident,
and only then that calls can be in-lined and optimized.

Perhaps in the future we will see automatic parallelism "extractors"
that can begin to capitalize on the dozens of processors that will
soon be in mass-market chips.  It seems pretty clear that we will
take much longer to get most programmers up to speed on efficient
parallel computing.  ;-(

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