David Schmenk wrote:
mdj wrote: [snip]We've learned a few things since then, but we've forgotten so much.. ;-)Oh, I doubt it's possible to get more than a few percent improvement out of the interpreters execution speed. Certainly big chunks of the OS itself could do with an overhaul, but one of the advantages of going for the JVM approach would be building it from scratch to run under ProDOS (and possibly be able to relocate itself into the Auxiliary Language Card *hint hint*)There will probably be a 64K version and a 128k version, just like Apple Pascal 1.3. For the 128K version, I'm planning on putting the bytecode interpreter in the AUX language card and data in AUX mem. 6502 and bytecode would go in main mem. This is somewhat backward from Apple Pascal 1.3 where p-code went into AUX mem. I'm planning on doing a lot more code swapping, so using main mem for methods seems like a good idea. But I'm not fixed on the idea, as I'm going to implement the 64K version first.I think the really interesting improvements would come from a runtime profiler/compiler that applied all the the feasible dynamic optimisations. MattI think it would be really interesting just to see it work ;-) For Java, the bytecode interpreter is just a piece of the pie. The memory manager/garbage collector probably has as much impact on performance. Just a functional JVM is going to be a tight sqeeze, much less any runtime hotspot optimizations. Although a method profiler might be pretty easy and not take much space.
The hotspots are frequently a small part of a method--though if methods are all very small, I suppose it's moot. The profile histogram itself is usually the space consumer. A good "absolute maximum" space budget for any resident interpreter/ profiler/compiler is half of memory.
A real class compiler for bytecode->6502 shouldn't be too hard. There will be a fairly easy way for native methods to interface to the runtime. At the moment I think it will have to be position independent code, which is an interesting exercise on a 6502.
If you arrange never to *move* the code, then it can be generated absolute. This is one of the advantages of "throwaway" compiling. -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."