Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!motcsd!hpda!hpcuhb!hpindda!tribby
From: tribby@hpindda.HP.COM (David Tribby)
Newsgroups: comp.sys.apple
Subject: Re: P-Code System
Message-ID: <6230029@hpindda.HP.COM>
Date: 30 May 89 17:25:45 GMT
References: <1366@tellab5.tellabs.CHI.IL.US>
Organization: HP Information Networks Group/Cupertino CA
Lines: 51

toth@tellab5.tellabs.CHI.IL.US (Joseph G. Toth Jr.) writes...
> When you talk about speed and the kind of things the home programmer would
> do, super high speed isn't all that important, reasonable speed is a expected.
>    ...
> P-Code systems are somewhat slower than Assembly Programming due to the
> fact that the P-Code is read and interpreted to determine what function to
> perform, however, well written functions are not slow and the amount of time
> used by a GOOD P-Code interpreter to select the function is very small.
>    ...
>   C) P-Code systems (Apple Pascal, hyperC) do exist in forms that provide
>      reasonable execution speed (10 to 100, or more, times faster than
>      Applesoft) with full language capabilities, but use their own DOS base.
>    ...
> If it's too slow for ya, assemble;  but in many cases, the speed would be
> acceptable.

All excellent points! My experiences match your conclusions, Joseph. When I
bought my ][+ back in '81, I got Apple Pascal because I wanted to program in
a block-structured language and easily go in and out of assembly language.
I found Pascal programs were much faster than equivalent Applesoft programs.

Of course, any upper-level language will be less efficient than hand-coded
assembler. Plus, the interpreter takes at least 10 instructions for each 
p-code instruction.

But it was easy to re-code inner loop procedures from Pascal into assembler. 
I de-bugged the algorithm in the Pascal version, then wrote a new version in
assembler. The p-system relocated the assembly language in memory, so I 
didn't have to worry about absolute code locations. Parameters were passed 
through the stack.  (A terminal emulation program I wrote had no problems 
keeping up with a 1200 baud line.)

The p-system programs Murph mentioned as being too slow may have been
written for maximum portability, and thus did not use any assembler. Or
their algorithms may have been designed or implemented without any
concern for performance. 

The main problem with the p-system was its unique file system. Most
Apple II software is written for ProDOS, and it's hard to use data from
those applications in a p-system program. As features were added to the
II (double hi-res, for example), Apple didn't make them all available
from Pascal.

When I got a IIGS, I very quickly moved to TML Pascal. The programs
ported fairly easily, and were much faster since they compiled to native
(16-bit) code. And with ProDOS file calls, I feel as if I'm in the
mainstream of Apple II development.

--Dave Tribby
                                   - - - - -
        ARPA: tribby%hpda@hplabs.HP.COM   UUCP: hplabs!hpda!tribby