[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: P-Source: A Guide to the Apple Pascal System
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."