mdj wrote:
On Dec 4, 5:13 am, Eric <englere_...@yahoo.com> wrote:This sounds like a pretty full-featured JVM. I seriously doubt if you can be faster than Apple Pascal with this model but I do like what you're doing. I was alluding to the inappropriateness of this comparison in an earlier message. It's not fair to directly compare 2 things that are quite different. It would be extremely exciting to hear that you can even come close to the performance of Apple Pascal with a real garbage collection and multi-threading OS, but I just don't want you to be dismayed if that doesn't happen.There's at least a subset of JVM functionality that's directly comparable. Of course, once we factor in GC & dynamic binding it *will* be slower. Years ago I wrote a graph plotting program for the Apple II in Pascal. It worked well, but was a little too slow for my taste. To get around this I wrote a 'compiler' for the expression parser which dynamically generated a static evaluator in 6502. This plugged in via an assembly routine full of NOPS that I linked into the program. The resulting application was fast enough that you'd not be able to tell it was written in Pascal at all. While this is a greater optimisation than a hot-spot compiler can manage (at least for now), I've always preferred this approach to programming and am confident with some extensions Dave's work will result in a very interesting new 'platform' for the Apple II
That's interesting! In 1974, when the portable Pascal (p-code) compiler first became available, some folks a Burroughs became interested enough to writean interpreter for p-code to run it on our machines (B3500-B4500 at the time).
The problem is that it took over an hour to compile the compiler using the interpreter. So I decided to write a "back-end" that would read p-code and generate machine code. Needless to say, this resulted in substantial code expansion! But it compiled the compiler in about a minute--so overnight the code generator became the only way to run p-code on our machines. ;-) Considering that the target machines were *very* distant from the original target machine (CDC6400), with BCD data and addresses and a variable-size memory-to-memory architecture, I found the code generation problem to be quite interesting and rewarding. Ironically, one of the issues that had to be left to a one-time "thunk" at run time was pointer arithmetic--p-code made an assumption that an integer was one "storage unit", which made pointers essentially integers. On a digit-addressed machine, that was *not* true, so I had to determine that an arithmetic operator was actually working on a pointer, not an integer, at run time--which back-patched the generated code for future use. -michael NadaPong: Network game demo for Apple II computers! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it's seriously underused."