mdj

On Nov 29, 6:04 pm, "winston19842...@yahoo.com"
<winston19842...@yahoo.com> wrote:
> On Nov 29, 2:54 am, mdj <mdj....@gmail.com> wrote:
>
>
>
> > 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.
>
> Umm - you mean for Apple Pascal (and versions before UCSD IV.0) right?
>
> I'm pretty sure IV.0 and up had a real heap. You are probably talking
> MARK and RELEASE? IV.0 had new and dispose.

Yes, that's what I meant. It was frustrating when writing more
sophisticated applications - on more than one occasion I cobbled
together my own garbage collection regime.

> I run IV.0 on a TI-99, which had a lot less space than an Apple (of
> any variety). Yes, it does a lot of segment loading when running the
> compiler, for example...

I don't have any experience with IV.0, since Apple Pascal stopped at
UCSD II, unfortunately.

Matt