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

["Michael J. Mahon" <mjmahon@aol.com>]

David Schmenk wrote:
> Michael J. Mahon wrote:
>
> > 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.
> > > >
> > > > 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.
> >
> >
> > 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
>
>
> I'm not sure how you came to that number.

It's just a rule of thumb.  If the overhead of a system is more than
half the total memory, then it's likely that the point of diminishing
returns has been reached for the functionality of the system as seen
by a user.

Appleworks on an unextended, unenhanced //e is a counterexample, though
many would argue that 12KB is not enough data space to make the full
functionality of Appleworks very useful.  ;-)

BTW, since an OS is typically just the "foundation" for an environment,
my rule of thumb is that the resident part of an OS should not exceed
a fourth of the available memory space.  (So ProDOS is just about the
practical limit for an Apple II.)

>  I certainly hope to use less 
> than 32K for a VM.  Each environment has its practical size.  Apple 
> Pascal used about 20K for the interpreter and OS.  Even at that, editing 
> and compiling moderate sized programs was a chore. For Java, I'm sure a 
> 64K machine will be an exercise in futility for all but the simplest of 
> programs.  Hopefully a 128K machine with swapping will be actually 
> useful for something.

That sounds right.  If Pascal had used 30K, it would have been a
real problem even to fit the compiler's p-code!

The trick to getting more functionality is to use a space-saving
encoding, like p-code, to express as much functionality as possible
without compromising performance too much.  Because the dynamic
frequency of code execution is so skewed, judicious use of this
technique can be very effective in packing more function into
less memory while still preserving a lot of speed.

> ..
>
> > > 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.
>
> Since I don't want to write a special assembler on top of everything 
> else, I'm using Merlin.  Getting relocatable 6502 code into a Java class 
> file is more than I'm willing to tackle.  I want code to be managed on 
> the heap like everything else - it needs to be position independent.  I 
> can currently generate a Merlin source file from a Java class file. 
> Replace bytecode with 6502 assembly and presto - a native class (also 
> have to change the code attribute name so the class loader knows its 
> native).  I haven't tried writing a full class in position independent 
> code, so maybe it isn't feasible.

I'd expect that you wouldn't need much of the functionality of an
assembler when generating 6502 code from byte code.  Direct generation
from "macro" templates shouldn't be hard.  As I suggested earlier, I'd
expect it to be more like copying a code template while filling in
addresses.

For short code sequences, an address relocation table would also be
quite short, and easily manipulated by a dynamic relocator (which I
would expect to be seldom-used).

Of course, I don't know the full set of design tradeoffs you are dealing
with, so this may not be applicable.

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