In article <nospam-701F83.06305517072003@clmboh1-nws3.columbus.rr.com>,
John B. Matthews <nospam@nospam.com> wrote:
In article <ShnRa.14919$kI5.9342@nwrddc02.gnilink.net>,
"Michael Pender" <mpender@hotmail.com> wrote:
......................
Umm, the Fortran compiler was written in Pascal and assembler to
run under the p-system, not the other way around. It was
copy-protected, slow, buggy and never got updated. Although the
number of open files was never a serious limitation, the
primitive disk allocation scheme was prone to fragmentation.
The rest of the system was quite robust: Apple Pascal disk I/O
was very efficient; it was the forerunner of ProDOS. The
p-system was used to develop scores of widely used applications,
including PFS, Jack, VersaForm, QuickFile, Smartcom, Apple
Business Graphics, Wizardry and the AppleWorks tutorial. 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.
I never liked Apple Pascal, 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!
I also liked Turbo Pascal's floating-point format, which was 6 bytes,
a good compromise between the usual 4 bytes (too imprecise) and 8
bytes (too slow). OTOH Applesoft with its 5-byte floating-point
format was quite good too. Here Apple Pascal was a definite step
back, to 4-byte floating-point numbers. And Apple Fortran was no
better, since it implemented only the subset standard of Fortran-77
and thus lacked e.g. DOUBLE PRECISION floating-point numbers - quite
a serious omission in a language supposedly intended for number
crunching!
To me, the most compelling feature was being able to mix low-
and high-level code cleanly.
Here Turbo Pascal did shine. If you wanted to access absolute memory
locations in Apple Pascal, you had to play some tricks with pointers
and variant records. In Turbo Pascal it was much much simpler: it
had a non-standard extension -- the mem[] array (of type "byte",
another Turbo Pascal non-standard extension) was predefined in
Turbo Pascal and _was_ the physical memory! So if you wanted to
read the keyboard directly in Turbo Pascal (Address $C000 for the
6502; it was remapped to 0E000h for the Z80) you just used 0E000h
as an index into the mem[] array.
In Turbo pascal you could also add machine code directly through
the "emit" statement (still another non-standard Turbo Pascal
extension). However, TP lacked a full-fledged inline assembler,
you had to supply the hex opcodes yourself.
I wrote a Turbo Pascal utility once which did read Apple Pascal disks
and transferred the Pascal source files (or any other text file) over
to CP/M disks, to make them accessible to Turbo Pascal. After having
transferred all my Apple Pascal source files over to CP/M, I almost
never touched Apple Pascal again.