Re: Low-level vs. High-level programming (was My First Computer)

[pausch@saaf.se (Paul Schlyter)]

In article <nospam-EFADE7.15285117072003@clmboh1-nws3.columbus.rr.com>,
John B. Matthews <nospam@nospam.com> wrote:
 
> In article <bf6nmm$1vpr$1@merope.saaf.se>,
>  pausch@saaf.se (Paul Schlyter) wrote:
> 
>> In article <nospam-701F83.06305517072003@clmboh1-nws3.columbus.rr.com>,
>> John B. Matthews <nospam@nospam.com> wrote:
>> ......................
>>>The UCSD language extensions for strings and separate compilation 
>>> were implemented in scores of subsequent systems for Apple ///, 
>>> Lisa and Macintosh, not to mention Turbo Pascal and Delphi.
>>  
>> Turbo Pascal versions 1 to 3 didn't support separate compilation
>> though: the entire program had to logically reside in the same
>> source file.  The only way to split it up was through INCLUDE
>> directives.
> 
> Interesting. I used Turbo Pascal for only a short time on Mac. 
> When did Turbo Pascal come support the UCSD "use" clause? Or am 
> I misremembering?
 
You're not misremembering: separate compilation and units were
introduced in Turbo Pascal ver 4.  However, versions 4 and later
were never released for CP/M, only for MS-DOS and/or Windows.
 
>> I never liked Apple Pascal,
> 
> I loved it! It was sooo much better than Fortran:-)
 
Well, I was no fan of Apple Fortran either -- it was really a pig!
 
Instead I ran Microsoft Fortran-80 for CP/M for my Fortran needs.
Microsoft sold an Apple version of Fortran-80 for perhaps 1/3 the
price of the standard version of Fortran-80.  But it would run only
on the Microsoft Softcard - when I tried to run it on the Appli-Card
it refused to work; the compiler just terminated, producing no
output.  I suspected it checked the presence of a 6502 as it appeared
from the Softcard.  So I scanned the executable file for the byte
sequence which let the Z80 call a 6502 subroutine -- and found it at
exactly one place.  Next I started the executable in a debugger, put
a breakpoint there and single-stepped through the Z80 parts of the
code to figure out how it worked: the 6502 simply set a bit in a byte
somewhere.  So I replaced that 6502 call with Z80 code which set the
same bit -- and lo and behold, now the Apple version of Fortran-80
ran fine also on the Appli-Card !!!!
 
Next, I wrote a letter to Microsoft (this was back in 1981, when
Microsoft still was a small company, in Seattle) explaining my
problem and asking if there was a workaround.  A few weeks later I
got a reply, basically saying "Sorry but the Apple version of
Fortran-80 doesn't work on the Appli-Card. But the standard version
of Fortran-80 works on that card.".  Baiscally, they wanted me to buy
their compiler again, and this time for three times the price....
 
> Still, I've abandoned it in favor of Kyan Pascal under ProDOS.
> 
>> and my first serious experiences
>> with Pascal was on Turbo Pascal 1 running on Apple II CP/M:
>> it was ...s.o...m.u.c.h...f.a.s.t.e.r... - on the same hardware!
> 
> Can you speculate on how this came to be?
 
The reason is obvious and simple: pseudo-code versus native code.
 
Apple/UCSD Pascal compiled to P-code, which was interpreted by a
P-code interpreter at runtime.  And since the UCSD Pascal compiler
was written in UCSD Pascal, it suffered the same performance penalty
as any other UCSD Pascal program.
 
Turbo Pascal was written in assembly language (Z80 assembly for CP/M,
8086/88 assembly for MS/PC-DOS, 68K assembly for the Macintosh) and
generated native code as output.
 
This is precisely the same reason why Java is slower than C or C++.
In a way, Java is the "UCSD Pascal" of our times.  Of course today's
hardware is so much more powerful that this doesn't matter very much
(unless the program is heavily CPU intensive).  But it's the same
phenomenon -- and back around 1980, when a 1-2 MHz 8-bitter was the
norm, the speed penalty of pseudo-code mattered a lot!
 
> Apple's compiler and assembler were both disk based:
 
This of course added to the slowness of Apple Pascal, particularly
when floppy disks were used.  Turbo Pascal read the entire system
(editor, compiler, runtime library) into RAM and versions 1-3 managed
to squeeze that into an amazingly small part of RAM (28K on the CP/M
version, 32K on MS/PC-DOS).  The remainder was to be used for your
Pascal source and the object code.  However, the object code could be
directed to disk, and the source could be split up and read into disk
in segments using the INCLUDE directive -- if used like this, Turbo
Pascal got much slower, of course, but it was still faster than
Apple Pascal.
 
I remember one other Pascal compiler which was even slower than Apple
Pascal: JRT Pascal for CP/M.  It was sold by a company which had a
quite unorthodox view on software piracy -- in their ads, they
explicitly said "If you want, give copies of the disk and the
documentation to your friends; it's OK with us".  That compiler was
also heavily disk based.  Separate units got compiled into separate
object files on disk, which was read in, during runtime, only as
needed!  But the compilation was very slow, and during runtime it
was even slower.  The only advantage of JRT Pascal compared to Apple
Pascal was the floating-point accuracy: 14 digits vs 7 digits for
Apple Pascal....
 
> They were slow, but they scaled well. On a hard drive and with the
> speedup of the IIgs, they were quite suitable for larger projects.
 
I can imagine that UCSD Pascal scaled well on more powerful hardware.
Which is to be expected, since UCSD developed it on systems more
powerful than 8-bitters like the Apple II.
 
But on small systems (8-bit, max 64K RAM, only floppy disks) it did
not scale well -- at least not if you also consider scaling down and
not just scaling up.
 
UCSD Pascal wasn't unique in this respect.  On the CP/M side there
were several C compilers available -- but they were ports of larger
compilers to CP/M and didn't scale well at all on such a small
system.  They were large, and very slow at compiling, and didn't
produce code which ran that fast either.  But then Leor Zolman came
along and wrote BDS C, which immediately became a success in the CP/M
world: it was small, it was fast, and it produced quite fast code too
- because it was written in 8080 assembly.  It was not a perfect C
compiler of course -- it was non-standard, it lacked floating point,
and it had several idiosynchracies.  But it worked very fine in the
CP/M environment, and a lot of stuff was written using BDS C.  A user
group was formed which published a newsletter "The BDS C User's
Group".  Somewhat later the name was changed to "The BDS C User's
Journal".  Still later the "BDS" was dropped from the name and "C++"
was added -- and that publication is still around, under the name
"C/C++ User's Journal" -- you can visit their web site at
http://www.cuj.com if you want.
 
Small systems have different requirements than large systems.  And
if you port software from a larger system to a small system, it might
suffer from such a port just like Apple Pascal did.
 
When the IBM PC had been released in the early 1980's, there were
three different OS'es you could choose among: PC-DOS (which came with
the machine), CP/M-86 and UCSD Pascal (which had to be purchased as
extras).  I knew some software developers who developed for Apple
Pascal, with the explicit intention to later port their application
(an administrative system for small businesses) to UCSD Pascal on the
IBM PC and thus capture the PC market as well.  Alas, UCSD Pascal
turned out to be the least popular of the OS'es for the IBM PC.  And
it soon faded away in the Apple II world too, as ProDOS took over.
 
-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://www.stjarnhimlen.se/
         http://home.tiscali.se/pausch/