[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Java on the Apple2 and C64
mdj wrote:
On Aug 10, 8:04 am, Tristan Mumford <xtristan.xmumf...@xgmail.xcom>
wrote:
Tsk, you've totally missed the point...
To give me horrible nightmares?
Very good work though. I never would have expected anything Java within a
stone throw (or serial cable) of an 8-bitter.
Well really, the JVM isn't that far removed from the UCSD p-System it
was (partly) inspired by. The degree of inefficiency implied by the
degree of indirection inherent in object oriented programs probably
implies that the paradigm has little practical use on such a small
machine, whether bytecode interpreted or not.
However, the Apple II p-System is very heavily optimized for the
"under 64KB" environment. In particular, the bytecodes are very
tightly encoded to improve code compaction.
The encoding of Java bytecodes is much looser, and so should be
much less space efficient for typical under-64KB programs.
Applesoft, often maligned for its incomplete interpretive coding,
is actually relatively compact in its code representation--though
it pays for it in rutime inefficiencies. (I occasionally wonder
how much faster it would be if variable and statement addresses
were "backpatched" into the code during execution, eliminating the
painful linear searches to resolve them...)
If it serves to break the "Java/.NET/VM" languages are inefficient
meme, then this project has a practical use that I applaud.
Of course, interpretation is only inefficient when used in a way
that results in slower overall execution than not using it. If an
application can run slowly in an interpretive system, but cannot
run at all in a non-interpretive environment, then interpretation
is much faster. ;-)
In any memory-constrained system, there is a good chance that
interpretation, full or partial, can be used to increase code
compaction to a significant degree. In many cases, this might
make the difference between practicality and impracticality.
In fact, interpretation is just a particular way of factoring out
chunks of code that are frequently used. Other related methods
are threaded code and procedure calls.
-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."