toth@tellab5.tellabs.CHI.IL.US (Joseph G. Toth Jr.) (05/30/89)
Come on guys - We're talking Apple //'s here. We're talking under ProDOS.
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.
To lump P-Code systems with Basic Interpreters is like comparing the hound
and the hare.
Why do I use this metaphore when we all know that the hare lost the race;
Because (like the hare, who was lazy and conceited) too many programs are
slow because the programmers did not know what they were doing or were
too lazy to look for the best method of doing things.
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.
P-Code is Much Much Much Faster than any BASIC because;
1) BASIC inetrpreters search chained lists for variables while P-Code has
a directly addressed variable storage methodology (the same as Native Code)
2) Basic GOTO's _ALWAYS_ search from the first line of code to find the line
of code to execute, while P-Code CALLS (and GOTO's if allowed) use a direct
pointer method to direct execution to the appropriate code statement.
3) The incredibly slow FREE command used in Applesoft that is used to
re-configure the variable storage to open up space used by variables that
have new values stored, is totally unnecessary in P-Code execution (see 1)
As a point of interest, Aztec "C" has been complained about on this group
for some time about its poor execution and display speed (Somebody re-coded
the printf routine to allow acceptable display performance).
Even programs written in assembly can be Veeeerrrry Slllooowwww if poor
programming practices are used... (read some of the articles that refer to
games, all written in an assembly language for speed, regarding poor quality
and response times).
Enough of my diatribe;
My main points of conjecture are that ;
A) a variety of languages that run under ProDOS are currently not available.
B) compilers that generate native code for the // line are VERY DIFFICULT
to create and maintain.
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.
D) The availability of High Level Language Programming on the // line
would have a huge market (Schools would not have to go to a different
machine to teach something useful).
If it's too slow for ya, assemble; but in many cases, the speed would be
acceptable.
At least those are my opinions.....
Users who feel that the super high speed is a requirement have either;
a) done a good job of programming in assembly language.
b) bought a new, high powered, computer.
--
------------------------------------------------+---------------------
Maybe I shouldn't have done it, sarcasm is so | Joseph G. Toth Jr.
seldom understood. Don't FLAME on me, please. | uunet!tellab5!tothtribby@hpindda.HP.COM (David Tribby) (05/31/89)
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
nelson@pro-europa.cts.com (Nelson Minar) (05/31/89)
att!tellab5!toth@ucbvax.berkeley.edu (Joseph G. Toth Jr.)?'s impassioned defense of a P-system does make me wonder.. What are the performance characteristics of a P-System? Isn't the kernal rather large? What sort of ballpark execution speed are we talking? Maybe 50% of assembled code? Also, I know there are a couple of P-Systems already out there - Beagle Basic, various Pascals. Any sort of P-system source code one could use (legally) as a starting point? toth's point is well taken - a slow system is better than no system. nelson@pro-europa.cts.com cogito ergo non sum ...!crash!pnet01!pro-nsfmat!pro-europa!nelson
delton@pro-carolina.UUCP (Don Elton) (06/01/89)
Network Comment: to #3221 by obsolete!pro-angmar!pro-europa!nelson
I think the best solution is that if you want to write commercial grade stuff
on an 8-bit Apple you need to learn assembly language. If you want a native
code compiler capable of serious work then you need a IIgs or Mac (or CP/M
card I suppose). So far as I know, ORCA Small C is the only 8-bit p-code
compiler I know of that you could use to write stand-alone SYS programs with
under ProDOS. Everything else requires a very restricted memory model with
lots of code overhead. Small C is pretty limited but can be enhanced by the
user (source code is included) and it's easy to interface with pure assembler
as needed.
UUCP: [ sdcsvax nosc ] !crash!pro-carolina!delton
ARPA: crash!pro-carolina!delton@nosc.mil
INET: delton@pro-carolina.cts.com
Pro-Carolina: 803-776-3936 (300-2400 baud, login as 'register')
US Mail: 3207 Berkeley Forest Drive, Columbia, SC 29209-4111paul@athertn.Atherton.COM (Paul Sander) (06/03/89)
In article <8905311619.AA04801@crash.cts.com>, nelson@pro-europa.cts.com (Nelson Minar) writes: > What are the performance characteristics of a P-System? Isn't the kernal > rather large? What sort of ballpark execution speed are we talking? Maybe 50% > of assembled code? Runtime support need not be large. No matter what we write, we'd need things like multiple-precision arithmetic (on a 6502, even 16-bit adds are double precision, but we all know that), string I/O, and so on. None of these things by themselves is large, and everything put together is only a couple of Kbytes. For example, Fig-Forth runs in less that 8K, I think, and I've implemented a Pascal subset that uses a P-code interpreter that runs around 4K (unoptimized). I've made no attempt to measure performance, but for what I do with the stuff the performance is reasonable (maybe even fast). > Also, I know there are a couple of P-Systems already out there - Beagle Basic, > various Pascals. Any sort of P-system source code one could use (legally) as a > starting point? Try checking Byte's back issues. August 1978 (I believe) contained the first of three articles that implemented a Pascal subset compiler in BASIC that produced P-code. Also included are Pascal source for a debugger, and some other stuff like loophole optimization techniques. Perhaps someone could use that as a starting point (with the articles' author's permission, of course). > toth's point is well taken - a slow system is better than no system. There are times when slow systems are worse than useless (i.e. manual systems are faster and work better for the task at hand) but IMHO this is not one of them. -- Paul Sander (408) 734-9822 | If a machine is powerful enough paul@Atherton.COM | to have a DWIM button, why bother {decwrl,sun,pyramid}!athertn!paul | with the button? -- Eric Black