Re: Java on the Apple2 and C64

[mdj <mdj.mdj@gmail.com>]

On Aug 11, 4:26 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:

> Both bytecodes seem to have a very similar stack based architecture. The
> p-system was designed to run in 64k, so many concessions had to be made
> to create a full IDE written in itself as well as I/O.  Segment swapping
> was essential to getting just about anything to run.  Java never really
> had that kind of constraint placed on it.  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.

They are certainly very similar, yeah, the JVM didn't have keeping the
codesize small as a design consideration.

> I guess I have never been a fan of bytecoding.  For the p-system, it was
> a way to port to many different architectures without undo effort.  For
> Java, it was security.  However, for a memory constrained environment,
> it seems interpreting a tokenized language gives the most space saving
> and flexibility.  Having to compile to a bytecode ruins the
> interactivity and some semantics and still leaves you having to
> interpret the output, just at a lower level.  If you're going to
> compile, then go all the way.  If you're going to interpret, keep it
> close to the source.  JIT compilation would have a lot more to work with
> using a tokenized representation vs somebody's notion of what a CPU
> should look like.
>
> Well, that's what *I* would do if anyone asked.

I think in the case of Java et al, the obfuscation provided by the
compilation is a design requirement that extends from the need to keep
code proprietary in the commercial world. Speaking in purist terms,
the compaction benefit that it provides (or would provide in a
constrained environment) is outweighed by the inconvenience incurred
by the loss of interactivity in the development process.

It's interesting that the "big three" interpretive languages in the
open source world (Perl 6, Python, & Ruby) are starting to sprout
runtime systems of similar sophistication to JVM/.NET, and are getting
closer to having comparable performance. It shows very clearly that if
you don't care about source code obfuscation you can 'have your cake
and eat it too' ;-)

I very wise man I had a conversation with recently mentioned that
encrypted source was a better solution. I agree with this sentiment,
and believe it will not be too long before it becomes commonplace.

Matt