Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!att!tellab5!toth
From: toth@tellab5.tellabs.CHI.IL.US (Joseph G. Toth Jr.)
Newsgroups: comp.sys.apple
Subject: P-Code System
Keywords: Faster than Aztec "C" / Programability is the REAL issue
Message-ID: <1366@tellab5.tellabs.CHI.IL.US>
Date: 29 May 89 21:02:08 GMT
Organization: Tellabs, Inc. Lisle, IL
Lines: 61

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!toth