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

mdj wrote:
On Nov 27, 5:48 pm, "Michael J. Mahon" <mjma...@xxxxxxx> 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.

Particularly since both of these optimization steps are a lot like a
a "transliteration with address substitution". That's why a budget of
100 cycles per generated byte is probably realizable.

(BTW, I'm a big believer in setting time and space "budgets" for
functions prior to implementation--so you know when you've gone off
the deep end. ;-)

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!

I would love to see a serious attempt made. But don't underestimate
the effort put into optimizing the p-system. They achieved most of
their objectives (which many regarded as impossible at the time) and
only failed to achieve their non-objectives. ;-)

We've learned a few things since then, but we've forgotten so much.. ;-)

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

Relevant Pages

  • Re: P-Source: A Guide to the Apple Pascal System
    ... Something like p-code (or in the case Java bytecode) unfortunately ... straddles the line where most of the really interesting optimisations ... Temporary allocation is important since Java at the ... running on the Apple II is a great follow-up to Apple Pascal. ...
    (comp.sys.apple2)
  • Re: P-Source: A Guide to the Apple Pascal System
    ... Temporary allocation is important since Java at the ... language level only supports dynamic allocation for objects, ... these optimisations would still be very fruitful for the 'hot' path, ...
    (comp.sys.apple2)
  • Re: Optimise my ray tracer
    ... What major optimisations are missing from my program (e.g. in C++, ... I'm finding that your Java code runs faster than your C++ ... I'm comparing the Java running on the server JVM from Sun's JDK 1.5 ...
    (comp.lang.java.programmer)