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

[mdj <mdj.mdj@gmail.com>]

On Nov 27, 5:48 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:

> >> For most programs, this approach can net a program whose code is less
> >> than twice the size of p-code alone but within 10%-20% of being as fast
> >> as pure (machine-generated) machine code!
>
> > I would consider that more along the lines of compilation, but of course
> > optimization has many faces.
>
> "Optimization" is pretty generic--meaning changing something to make
> something better.  ;-)

Something like p-code (or in the case Java bytecode) unfortunately
straddles the line where most of the really interesting optimisations
have to be done with runtime profiling. Of course, as you point out,
this could be done externally, which would be quite interesting (and
fun!)

JVM's do two classes of optimisation in the JIT stage which have
tremendous performance benefits: multi-level inlining and temporary
object allocation. Temporary allocation is important since Java at the
language level only supports dynamic allocation for objects, but a
'smart' JIT can identify object references that have only single-tier
scope and allocate them on the stack instead. I would imagine both of
these optimisations would still be very fruitful for the 'hot' path,
even on a very small machine. Applying these techniques and *then*
doing a native code transform could yield a pretty good improvement,
and it's certainly feasible even on a limited machine.

> > So I don't see how Java, as a platform, fits in to the modern computer
> > world.  Its all too busy being the enterprise solution for your server
> > and entertainment solution for the cell-phone.  But, nobody asked me and
> > it seems to be everywhere.
>
> That is, of course, it's intended purpose--since Sun introduced it
> precisely to drive a wedge between Wintel platforms and the code that
> runs on them.
>
> Notice that the "incumbent" is never interested in portability, only
> the "wannabe".  ;-)

Speaking as someone who's done several years of server side
programming, Java's portability has been an absolute boon in the
heterogenous data centres of today. This has been its principle area
of success. It's been only recently that client end applications in
Java have become common, since it's only been recently that the UI
layers have become optimised and deeply integrated enough to deliver
decent end-user applications.

> > Having said that, I think having a JVM (or KVM, using Java EE
> > micro-edition 3.1415926 or is that Java Version 6p?, nomenclature)
> > running on the Apple II is a great follow-up to Apple Pascal.  Within
> > limits, of course.  The Apple II makes the nano Java devices look like
> > big iron.  As soon as I finish working out some issues with the garbage
> > collector (I don't like automatic garbage collectors) I should have
> > something to try out.
>
> I completely agree.  I think that Java is a pretty "heavyweight" way
> of programming a 64KB, 1MHz device.  For that matter, so is Pascal, but
> the p-System (especially with RAM disk and an accelerator ;-) almost
> makes it bearable.
>
> Seen from the top down, the problems that have a size and complexity
> that would require Java's structure and richness are typically much
> larger than those that can be run usefully on an Apple II.
>
>  From the bottom up, disciplined low-level programming is sufficient
> to avoid complexity collapse for an application that runs in 64KB.
> And the space and speed advantages of doing so are worth a lot.  ;-)

I agree completely with this. I do however think there's a class of
'pascal sized' applications that could be written in Java instead, and
finding creative solutions to the optimisation problems sounds like a
really fun academic exercise. There's certainly room to do far better
than the p-machine implementations did!

Matt