Re: P-Source: A Guide to the Apple Pascal System

["winston19842005@yahoo.com" <winston19842005@yahoo.com>]

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.

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...