mdj

On Nov 29, 5:16 pm, David Schmenk <dschm...@YUCH.gmail.com> 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.

Great minds... :-)

> > I think the really interesting improvements would come from a runtime
> > profiler/compiler that applied all the the feasible dynamic
> > optimisations.
>
> > Matt
>
> I 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. 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.

Yeah. I'm interested to see how you manage the heap - with so little
space it could potentially thrash really badly. The p-system got
around this problem by 'disposing' the dispose procedure and simply
having a stack instead, but for Java that's not an option.

Matt