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

Michael J. Mahon

David Schmenk wrote:
> mdj wrote:
>
>> On Nov 19, 3:03 pm, David Schmenk <dschm...@sbcglobal.net> wrote:
>>
>>> Anyone have a copy of this book, hardcopy or otherwise? It has some
>>> relevance to my latest project. Thanks,
>>
>>
>> Mine is packed away and not easily retrievable. If you've got specific
>> questions about Apple Pascal I can probably answer most of them
>> however ...
>>
>> Matt
>
>
> There is a chapter on optimizing the p-code interpreter. I was curious
> as to what they were. I've been looking at the Apple Pascal 1.3
> interpreter (thanks to Paul Santa-Maria!). I'm always interested in
> what others find to optimize.

For a *really* effective optimization, profile the p-code and translate
the "sufficiently hot" p-code to direct calls to the "execute" routines
or, if "extremely hot", translate the p-code to 6502 machine code.

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!

This isn't easy, but for a compiler/interpreter programmer it's not
too hard, either. The cutoff on how much you can optimize how far is
the available memory, since both optimizations are progressively larger
than the p-code translated.

Further complicating things is the fact that many applications will
run slower or not at all with much less available memory for data.

This problem can be reduced for many programs by simply generating
code for "hot p-code" into a fixed-size cache, invalidating older
code on a LRU basis--an approach that used to be called "throwaway
compiling". (For fast machines, re-generating code is usually faster
than "paging in" non-resident generated code.)

If these approaches had been integrated originally, Java may not
have been necessary. ;-) Of course, the "machine code" optimization
is fully machine-dependent, so it's easy to see how the p-system
creators may not been interested in going there.

In the 1960s, at least one little compiler company (DigiTek) and
their successor (whose name I forget) *did* approach compilation
in this frame of mind, and as a result, they had the world's fastest
small compilers (or the world's smallest fast compilers , but they
kept the method pretty much to themselves as a competitive advantage.

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

David Schmenk

Michael J. Mahon wrote:
> David Schmenk wrote:
>> mdj wrote:
>>
>>> On Nov 19, 3:03 pm, David Schmenk <dschm...@sbcglobal.net> wrote:
>>>
>>>> Anyone have a copy of this book, hardcopy or otherwise? It has some
>>>> relevance to my latest project. Thanks,
>>>
>>>
>>> Mine is packed away and not easily retrievable. If you've got specific
>>> questions about Apple Pascal I can probably answer most of them
>>> however ...
>>>
>>> Matt
>>
>>
>> There is a chapter on optimizing the p-code interpreter. I was
>> curious as to what they were. I've been looking at the Apple Pascal
>> 1.3 interpreter (thanks to Paul Santa-Maria!). I'm always interested
>> in what others find to optimize.
>
> For a *really* effective optimization, profile the p-code and translate
> the "sufficiently hot" p-code to direct calls to the "execute" routines
> or, if "extremely hot", translate the p-code to 6502 machine code.
>
> 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. Java bytecode is about as compact as
p-code so even replacing a single byte opcode (the majority) with a
three byte jump would add considerable code space. As you can imagine,
memory is extremely scarce in this environment. Perhaps implementing an
external bytecode->6502 compiler would be interesting for those cases
that needed more performance. Doing hot-spot compilation on a 6502
seems like a lot of work for questionable trade-off.

> This isn't easy, but for a compiler/interpreter programmer it's not
> too hard, either. The cutoff on how much you can optimize how far is
> the available memory, since both optimizations are progressively larger
> than the p-code translated.
>
> Further complicating things is the fact that many applications will
> run slower or not at all with much less available memory for data.
>

Not to mention the size of the optimizer. In fact, the size of the
optimizer would probably approach that of the entire interpreter.
Looking at about 12K for the interpreter, that leaves about 8K for
bytecode and data :-)

> This problem can be reduced for many programs by simply generating
> code for "hot p-code" into a fixed-size cache, invalidating older
> code on a LRU basis--an approach that used to be called "throwaway
> compiling". (For fast machines, re-generating code is usually faster
> than "paging in" non-resident generated code.)
>

Running at a blazing 1 MHz here :-)

> If these approaches had been integrated originally, Java may not
> have been necessary. ;-) Of course, the "machine code" optimization
> is fully machine-dependent, so it's easy to see how the p-system
> creators may not been interested in going there.
>
> In the 1960s, at least one little compiler company (DigiTek) and
> their successor (whose name I forget) *did* approach compilation
> in this frame of mind, and as a result, they had the world's fastest
> small compilers (or the world's smallest fast compilers , but they
> kept the method pretty much to themselves as a competitive advantage.
>
> -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."

After reading through most of the book, Randy fixes the 6502 p-code
interpreter, more than optimizes it. Some of the original code
sequences were quite bizarre for doing comparisons. Other changes
simply involved using PLA instead of adjusting the stack pointer through
the X register. Still, its useful to review what he did.

There are some interesting benefits to keeping the bytecode interpreted
on the Apple II. The 6502 is a pretty good interpreter machine; better
than a native compile target, I think. In either case, signed
comparisons are messy and the hardware stack is small. If you look at
the generated code from cc65, it makes so many jumps to routines to
manipulate the stack and do comparisons, it looks much like compiled
bytecode.

Another benefit is that pre-emptive threading is a simple exercise.
Without a time-based interrupt, threading 6502 code requires
cooperation. Pre-emptively threading bytecode can involve calling the
scheduler after a fixed number have been emulated.

One thing I've found out during this exercise is that current Java
technology has really segmented itself. There are all sorts of versions
out there to try and satisfy each market. A small device that runs Java
has megabytes of memory and a 32 bit processor. Nano device have ~200K
memory and 16 bit processors. Many of the small devices and almost all
the nano devices have specialized build procedures that massage the Java
class files into a more palatable native format. Doesn't that run
counter to the write once, debug everywhere goal? The standard class
library gets progressively smaller as the device shrinks, too. In the
end, I think its a testament what the p-system was able to pull off with
the technology available.

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.

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.

Dave...

Michael J. Mahon

David Schmenk wrote:
> Michael J. Mahon wrote:
>
>> David Schmenk wrote:
>>
>>> mdj wrote:
>>>
>>>> On Nov 19, 3:03 pm, David Schmenk <dschm...@sbcglobal.net> wrote:
>>>>
>>>>> Anyone have a copy of this book, hardcopy or otherwise? It has some
>>>>> relevance to my latest project. Thanks,
>>>>
>>>>
>>>>
>>>> Mine is packed away and not easily retrievable. If you've got specific
>>>> questions about Apple Pascal I can probably answer most of them
>>>> however ...
>>>>
>>>> Matt
>>>
>>>
>>>
>>> There is a chapter on optimizing the p-code interpreter. I was
>>> curious as to what they were. I've been looking at the Apple Pascal
>>> 1.3 interpreter (thanks to Paul Santa-Maria!). I'm always interested
>>> in what others find to optimize.
>>
>>
>> For a *really* effective optimization, profile the p-code and translate
>> the "sufficiently hot" p-code to direct calls to the "execute" routines
>> or, if "extremely hot", translate the p-code to 6502 machine code.
>>
>> 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. ;-)

> Java bytecode is about as compact as
> p-code so even replacing a single byte opcode (the majority) with a
> three byte jump would add considerable code space. As you can imagine,
> memory is extremely scarce in this environment. Perhaps implementing an
> external bytecode->6502 compiler would be interesting for those cases
> that needed more performance. Doing hot-spot compilation on a 6502
> seems like a lot of work for questionable trade-off.
>
>> This isn't easy, but for a compiler/interpreter programmer it's not
>> too hard, either. The cutoff on how much you can optimize how far is
>> the available memory, since both optimizations are progressively larger
>> than the p-code translated.
>>
>> Further complicating things is the fact that many applications will
>> run slower or not at all with much less available memory for data.
>>
>
> Not to mention the size of the optimizer. In fact, the size of the
> optimizer would probably approach that of the entire interpreter.
> Looking at about 12K for the interpreter, that leaves about 8K for
> bytecode and data :-)

For dynamic translation, that's true. But great results can be
achieved (see DigiTek) with a completly static optimization based
on dynamic frequencies acquired during a profiling run.

>> This problem can be reduced for many programs by simply generating
>> code for "hot p-code" into a fixed-size cache, invalidating older
>> code on a LRU basis--an approach that used to be called "throwaway
>> compiling". (For fast machines, re-generating code is usually faster
>> than "paging in" non-resident generated code.)
>>
>
> Running at a blazing 1 MHz here :-)

And originally doing 5.25" disk I/O at a whopping 10KB/sec.

That means if you can generate a byte in less than 100 cycles
(on average), re-generation is a win. ;-)

>> If these approaches had been integrated originally, Java may not
>> have been necessary. ;-) Of course, the "machine code" optimization
>> is fully machine-dependent, so it's easy to see how the p-system
>> creators may not been interested in going there.
>>
>> In the 1960s, at least one little compiler company (DigiTek) and
>> their successor (whose name I forget) *did* approach compilation
>> in this frame of mind, and as a result, they had the world's fastest
>> small compilers (or the world's smallest fast compilers , but they
>> kept the method pretty much to themselves as a competitive advantage.
>>
>> -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."
>
>
> After reading through most of the book, Randy fixes the 6502 p-code
> interpreter, more than optimizes it. Some of the original code
> sequences were quite bizarre for doing comparisons. Other changes
> simply involved using PLA instead of adjusting the stack pointer through
> the X register. Still, its useful to review what he did.

I've seen tortuous sequences for compares and certain shifts, etc.,
in code translated from non-6502 architectures. There's something to
be said for familiarity with the idioms...

> There are some interesting benefits to keeping the bytecode interpreted
> on the Apple II. The 6502 is a pretty good interpreter machine; better
> than a native compile target, I think. In either case, signed
> comparisons are messy and the hardware stack is small. If you look at
> the generated code from cc65, it makes so many jumps to routines to
> manipulate the stack and do comparisons, it looks much like compiled
> bytecode.

Not only is the 6502 a good interpreter host, it's also a pretty bad
direct-compile host--primarily due to its lack of a variable stack and
a 16-bit register + 8-bit displacement addressing mode.

Most high-level language compilers take a "heavy runtime" approach,
which leads to something very much like "threaded code".

> Another benefit is that pre-emptive threading is a simple exercise.
> Without a time-based interrupt, threading 6502 code requires
> cooperation. Pre-emptively threading bytecode can involve calling the
> scheduler after a fixed number have been emulated.

Right--but I can't think of any languages that used this approach.

> One thing I've found out during this exercise is that current Java
> technology has really segmented itself. There are all sorts of versions
> out there to try and satisfy each market. A small device that runs Java
> has megabytes of memory and a 32 bit processor. Nano device have ~200K
> memory and 16 bit processors. Many of the small devices and almost all
> the nano devices have specialized build procedures that massage the Java
> class files into a more palatable native format. Doesn't that run
> counter to the write once, debug everywhere goal? The standard class
> library gets progressively smaller as the device shrinks, too. In the
> end, I think its a testament what the p-system was able to pull off with
> the technology available.

As it has always been, there is a tradeoff between portability and
efficiency--particularly for very small (but bigger than Apple II's)
platforms.

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

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

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

mdj

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

mdj

On Nov 27, 3:38 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:

> One thing I've found out during this exercise is that current Java
> technology has really segmented itself. There are all sorts of versions
> out there to try and satisfy each market. A small device that runs Java
> has megabytes of memory and a 32 bit processor. Nano device have ~200K
> memory and 16 bit processors. Many of the small devices and almost all
> the nano devices have specialized build procedures that massage the Java
> class files into a more palatable native format. Doesn't that run
> counter to the write once, debug everywhere goal? The standard class
> library gets progressively smaller as the device shrinks, too. In the
> end, I think its a testament what the p-system was able to pull off with
> the technology available.

Yeah, the only real advantage is having one source language across
virtually every device, but you're right, the 'tiny' implementations
are pretty light on for class libraries.

Having said that, it's interesting to note that what was a 'tiny'
device a few short years ago (eg. a Cell Phone) can, thanks to
technology progression, now run the entire J2SE implementation, so the
benefits become greater as technology improves and today's embedded
device matches yesterdays desktop for computing power.

Matt

Michael J. Mahon

mdj wrote:
> On Nov 27, 3:38 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>
>
>>One thing I've found out during this exercise is that current Java
>>technology has really segmented itself. There are all sorts of versions
>>out there to try and satisfy each market. A small device that runs Java
>>has megabytes of memory and a 32 bit processor. Nano device have ~200K
>>memory and 16 bit processors. Many of the small devices and almost all
>>the nano devices have specialized build procedures that massage the Java
>>class files into a more palatable native format. Doesn't that run
>>counter to the write once, debug everywhere goal? The standard class
>>library gets progressively smaller as the device shrinks, too. In the
>>end, I think its a testament what the p-system was able to pull off with
>>the technology available.
>
>
> Yeah, the only real advantage is having one source language across
> virtually every device, but you're right, the 'tiny' implementations
> are pretty light on for class libraries.
>
> Having said that, it's interesting to note that what was a 'tiny'
> device a few short years ago (eg. a Cell Phone) can, thanks to
> technology progression, now run the entire J2SE implementation, so the
> benefits become greater as technology improves and today's embedded
> device matches yesterdays desktop for computing power.

Riding the Moore's "Law" wave has become such a way of life in
the software business that it's hard to believe that anyone ever
struggled to produce finely crafted code. ;-)

And now it will be hard to adapt to the new reality:

We can no longer expect that the processing capacity of our code
will be sped up by a relentless increase in thread execution speed.
Now that the uniprocessor wave is over, we need to be planning for
larger, and variable, numbers of processors running our (still very
serialized) code--like, more than 50...

Unfortunately, "threads" as currently conceptualized, are a relatively
poor abstraction for expressing the fractal parallelism that is needed.

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

Michael J. Mahon

mdj wrote:
> 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.

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

mdj

On Nov 28, 6:42 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> mdj wrote:
> > On Nov 27, 3:38 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>
> >>One thing I've found out during this exercise is that current Java
> >>technology has really segmented itself. There are all sorts of versions
> >>out there to try and satisfy each market. A small device that runs Java
> >>has megabytes of memory and a 32 bit processor. Nano device have ~200K
> >>memory and 16 bit processors. Many of the small devices and almost all
> >>the nano devices have specialized build procedures that massage the Java
> >>class files into a more palatable native format. Doesn't that run
> >>counter to the write once, debug everywhere goal? The standard class
> >>library gets progressively smaller as the device shrinks, too. In the
> >>end, I think its a testament what the p-system was able to pull off with
> >>the technology available.
>
> > Yeah, the only real advantage is having one source language across
> > virtually every device, but you're right, the 'tiny' implementations
> > are pretty light on for class libraries.
>
> > Having said that, it's interesting to note that what was a 'tiny'
> > device a few short years ago (eg. a Cell Phone) can, thanks to
> > technology progression, now run the entire J2SE implementation, so the
> > benefits become greater as technology improves and today's embedded
> > device matches yesterdays desktop for computing power.
>
> Riding the Moore's "Law" wave has become such a way of life in
> the software business that it's hard to believe that anyone ever
> struggled to produce finely crafted code. ;-)
>
> And now it will be hard to adapt to the new reality:
>
> We can no longer expect that the processing capacity of our code
> will be sped up by a relentless increase in thread execution speed.
> Now that the uniprocessor wave is over, we need to be planning for
> larger, and variable, numbers of processors running our (still very
> serialized) code--like, more than 50...

While the current wave may be over, I think there's probably another
one beyond photo lithography based approaches but that's potentially
decades away.

> Unfortunately, "threads" as currently conceptualized, are a relatively
> poor abstraction for expressing the fractal parallelism that is needed.

Agreed. I'm relatively confident (in fact, have long predicted) a
pivot in the software unwieldiness trend. Far more sophisticated tool
chains down the track, with the thread execution speed cap becoming
the driver. I fit in to the "Languages aren't abstract enough" camp,
and not just for parallel computing but imperative programming
languages in general; there is still a very big gap between the 'minds
eye' view of a piece of code and its physical representation.

Once we're firmly into the parallel era another personal axiom becomes
pertinent: "For any program x, there will be a workload y in which x
performs (relatively) poorly"

Unless... :-) (You get the idea)

Matt

mdj

On Nov 28, 6:50 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:

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

Agreed.

> (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. ;-)

I have similar views - I usually code with the rule that a function
should more-or-less fit on the screen. If it's bigger than that, then
it is probably > 1 functions :-)

I have however been accused of being an indirectionaholic in past, but
the newer runtime systems have shown I can have my cake and eat it too
so I'm not backing down on that one anytime soon :-)

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

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*)

I think the really interesting improvements would come from a runtime
profiler/compiler that applied all the the feasible dynamic
optimisations.

Matt

David Schmenk

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

Dave...