What exactly WAS Apple Pascal?
Zorin the Lynx
never actually found out exactly what Apple Pascal was, and references
online seem to be nonexistent.
It seemed to be a disk format, operating system, and possibly a
programming environment all built into one.. Hell, many utilities could
copy files to and from "Apple Pascal" format disks, but what was the
environment like?
Was it a full-featured Pascal compiler? An OS? A file format? Or all of
the above? Did anyone here develop in it? What was it like?
I had exactly ONE program that used Apple Pascal, and that was SmartCom
I, which drove my MicroModem IIe. (Note: This was the most useless comm
program ever. It had no industry-standard file transfer protocols and
had a goofy design. But hey, it got me on BBS's!)
A pointer to a FAQ or other document explaining Apple Pascal would be
great too...
- A curious Z
Don Bruder
If you know what CodeWarrior is on the Mac, then you've got the basic
idea of what Apple Pascal was - An early IDE, or "Integrated Development
Environment" that allowed the user to program the Apple II in Pascal
rather than BASIC. (Although I never encountered it personally, I did
hear rumours of a Fortran system that was identical to the Pascal
system, except that it had compiler/linker/library/etc. modules intended
for developing in Fortran. Another rumored variant I heard of but never
saw myself was COBOL package)
Whatever the language, it was a compiler that spit out "P-code" bytes -
Pseudo-assembly code for an imaginary (until later, when someone
actually cooked up a hardware CPU to match the specs of the until-then
purely emulated) processor, specced out by UCSD. It also had an editor
for creating files to feed to the compiler, a file manager that was more
or less the OS, libraries, a linker, a debugger, and an emulation module
that would run the P-code emitted by the compiler.
It used its own disk format, catalog structure, and so on, which
generally made accessing disks outside of the pascal system a pain in
the rump at best, and next to impossible at worst. Add the "sin" of
programs written with it not being proper "ready-to-run" standalone 6502
code (When you ran the program, you actually fired up what amounted to
an emulator for the pseudo-CPU, then it ran your program on the emulated
chip) and I thought it had some serious holes. At the same time, it
could be made quite useful, within its limitations.
--
Don Bruder - dak...@sonic.net - New Email policy in effect as of Feb. 21, 2004.
Short form: I'm trashing EVERY E-mail that doesn't contain a password in the
subject unless it comes from a "whitelisted" (pre-approved by me) address.
See <http://www.sonic.net/~dakidd/main/contact.html> for full details.
Hans Otten
>
>A pointer to a FAQ or other document explaining Apple Pascal would be
>great too...
http://www.threedee.com/jcm/psystem/ will give you some information where Apple
Pascal came from. Some keywords: Niklaus Wirth, ETH Zurich P2-P4 compiler,
P-code interpreter, UCSD Pascal
Hans, http://www.hansotten.com
Declan MacLeod
Zorin the Lynx <ya...@zorin.org> wrote:
The other replies have pretty much summed up what it was. The only
thing left to be mentioned was disk drives. The ideal number for using
Apple Pascal was "one more than you had." ;-)
--
Hey spambots! Harvest this! .!..
Unsolicited commercial email (uce) should be sent to: u...@ftc.gov
Paul Schlyter
Don Bruder <dak...@sonic.net> wrote:
> In article <cd7lc2$q52$1...@ottoman.cs.fiu.edu>,
> Zorin the Lynx <ya...@zorin.org> wrote:
>> A pointer to a FAQ or other document explaining Apple Pascal would be
>> great too...
>
> If you know what CodeWarrior is on the Mac, then you've got the basic
> idea of what Apple Pascal was - An early IDE, or "Integrated Development
> Environment" that allowed the user to program the Apple II in Pascal
> rather than BASIC. (Although I never encountered it personally, I did
> hear rumours of a Fortran system that was identical to the Pascal
> system, except that it had compiler/linker/library/etc. modules intended
> for developing in Fortran.
Yep, there was an Apple Fortran too, which was Apple Pascal whtih the
Pascal compiler and libraries exchanged with the equivalents for
Fortran instead. Apple Fortran implemented the Fortran-77 subset
version, which made it quite useless since the subset excluded double
precision and complex numbers, features wihch are quite useful to
people into number crunching. And since Fortran is good for number
crunching but hardly anything else, removing double precision and
complex numbers from Apple Fortran made Apple Fortran quite useless.
So I used Microsoft Fortran-80 on my Apple CP/M system instead: it
had double precision numbers but lacked complex numbers. After digging
in the internals of Fortran-80 for some time, I ended up adding complex
numbers to that compiler, both runtime library support and syntax and
code generation support for the compiler itself.
The UCSD system was a single language system. If you programmed in
Apple Pascal and wanted to switch to Apple Fortran, a reboot with a
different boot disk was necessary. This I considered another
disadvantage compared to e.g. CP/M: there you just started whatever
compiler or IDE for whatever programming language you had available
with a suitable command line and perhaps also a suitable disk change.
No reboot was evern necessary to switch languages.
> Another rumored variant I heard of but never saw myself was COBOL package)
That I think is just a rumor -- I never heard of any Cobol for the UCSD
system. You might confuse this with Microsoft Cobol-80: Microsoft sold
Apple versions of their Fortran-80, Cobol-80 MAC-80 (a macro assembler)
and Basic Compiler for CP/M, at substantially reduced prices. The MAC-80
Apple version even had the capability of assembling 6502 opcodes, a
capability the standard version of MAC-80 lacked.
> Whatever the language, it was a compiler that spit out "P-code" bytes -
> Pseudo-assembly code for an imaginary (until later, when someone
> actually cooked up a hardware CPU to match the specs of the until-then
> purely emulated) processor, specced out by UCSD. It also had an editor
> for creating files to feed to the compiler, a file manager that was more
> or less the OS, libraries, a linker, a debugger, and an emulation module
> that would run the P-code emitted by the compiler.
>
> It used its own disk format, catalog structure, and so on, which
> generally made accessing disks outside of the pascal system a pain in
> the rump at best, and next to impossible at worst. Add the "sin" of
> programs written with it not being proper "ready-to-run" standalone 6502
> code (When you ran the program, you actually fired up what amounted to
> an emulator for the pseudo-CPU,
That emulator for the pseudo-CPU (the "P-machine") always resided in RAM
though, in the language card, both banks.
The Apple P-machine also had an improved RWTS which allowed one track of a
floppy to be read at one revolution of the floppy, by doing the
de-nibblizing of the data "on the fly" while reading the data. Other
Apple OS'es (DOS 3.3, ProDOS) required 2 revolutions of a floppy to read
one track; Apple CP/M required 3 revolutions. And the sectors were
interleaved accordingly.
> then it ran your program on the emulated
> chip) and I thought it had some serious holes. At the same time, it
> could be made quite useful, within its limitations.
--
----------------------------------------------------------------
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/
Paul Schlyter
> I was an Apple II user for many years in the 80's and early 90's, but I
> never actually found out exactly what Apple Pascal was, and references
> online seem to be nonexistent.
>
> It seemed to be a disk format, operating system, and possibly a
> programming environment all built into one.. Hell, many utilities could
> copy files to and from "Apple Pascal" format disks, but what was the
> environment like?
Apple Pascal was a port of UCSD Pascal to the Apple II environment.
The idea of UCSD Pascal was to try to make also the binaries
portable. So UCSD Pasal defined a dialect of Pascal (several
extensions and a few restrictions compared to Wirth Pascal) where the
Pascal source code was compiled to a portable P-code, which in turn
was interpreted by a "P-machine". Almost all P-machines were
implemented in software only, the only exception was Western Digitals
"Pascal Micro Engine", a hardware CPU which executed P-code directly;
it wasn't successful.
Everyting in UCSD Pascal, except the P-machine, was written in UCSD
Pascal: the IDE, the editor, the Pascal compiler, the library
functions, the assembler. The assembler was named TLA (The Last
Assembler) and it was intended to be a universal assembler -
opcodes/etc for specific CPU's were defined in an accompanying data
file. The dream of those who wrote that assembler was obviously that
no other assembler would ever need to be written -- as we all now
know, this dream didn't come true.
UCSD Pascal was a 16-bit environment with all the limitations that
comes with such an environment such as max 64K address space. Even
the Z-machine (the interpreter used for Zork and other Infocom games)
had expanded a bit on that and used a 24-bit address space.
The UCSD Pascal file system was quite primitive: files had to always
be stored in one contiguous disk space. If disk space had become
too fragmented for a file to be stored even though there was enpugh
free disk space, there was a special "Krunch" command in the IDE
which moved files until all free space was gathered in one
contuguous part of the disk. Even Apple DOS 3.1 did better than
that and allowed files to be stored on any free sectors, contiguous
or not....
UCSD Pascal was ported to a number of systems. The Apple II and ///
port was called "Apple Pascal" and is perhaps the most well known of
the ports. In the earliest days of the IBM PC, you could choose
among three different OS'es when you bought it: Microsoft's MS-DOS,
Digital Research's CP/M-86, and UCSD Pascal. And it seems like there
was an UCSD Pascal for early Macintoshes too.
> Was it a full-featured Pascal compiler? An OS? A file format? Or all of
> the above?
All of the above....
> Did anyone here develop in it?
I played with it for awhile, but abandoned it as soon as Turbo Pascal
appeared which I got for my Apple CP/M system. Then I wrote - in
Turbo Pascal - a utility to tansfer Apple Pascal text files to CP/M
disks, transferred the few Apple Pascal files I had, and then I
hardly ever touched Apple Pascal again.
> What was it like?
Did you ever program in Turbo Pascal? Apple Pascal was similar, but
much much slower: the compile times were enormously longer (about
one source line per second, compared to Turbo Pascal's hundreds of
lines per seconds), and also the run time was some 10-30 times slower
in UCSD Pascal compared to Turbo Pascal.
And the floating-point precision was worse in UCSD Pascal, which used
4-byte floating-point numbers (7 digits of precision) while Turbo
Pascal used 6-byte floating-point numbers (12 digits of precision).
Even good ol' Applesoft used 5-byte floating-point numbers (9-10
digits of precision).
One significant difference between Apple/UCSD Pascal and Turbo Pascal
though was that in Turbo Pascal there was an "Exit" command by which
you could get out of the IDE and back to the OS. In Apple/UCSD
Pascal there was no way to get out of the IDE, except rebooting the
computer; that's of course because Apple Pascal also WAS the OS.
It's similar to the "SYSTEM" command which is available in Microsoft
MBASIC/BASICA/GWBASIC but is absent from Applesoft Basic (although
"CALL -151" is kind of a way out of Applesoft).
> I had exactly ONE program that used Apple Pascal, and that was SmartCom
> I, which drove my MicroModem IIe. (Note: This was the most useless comm
> program ever. It had no industry-standard file transfer protocols and
> had a goofy design. But hey, it got me on BBS's!)
>
> A pointer to a FAQ or other document explaining Apple Pascal would be
> great too...
>
> - A curious Z
A Google search on "Apple Pascal" found this:
http://www.callapple.org/apple2/software/tribby/apascal.html
http://member.nifty.ne.jp/apple2tree/manual/manual4.htm
http://www.threedee.com/jcm/psystem/
Gregory Weston
> I had exactly ONE program that used Apple Pascal, and that was SmartCom
> I, which drove my MicroModem IIe. (Note: This was the most useless comm
> program ever. It had no industry-standard file transfer protocols and
> had a goofy design. But hey, it got me on BBS's!)
That's perfectly in keeping with the package, since you had a Hayes
modem that wasn't controlled by the Hayes modem command set.
G (had one as well)
--
Standard output is like your butt. Everyone has one. When using a bathroom,
they all default to going into a toilet. However, a person can redirect his
"standard output" to somewhere else, if he so chooses. - Jeremy Nixon
exe...@nunya.biz
Paul Schlyter wrote:
The last version (1.3) utilized the 128K of the //c and IIe. It also
supported 3.5" disk drives. That 800K of storage was a big improvement
over 1-4 140K drives.
Roy
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
John B. Matthews
pau...@saaf.se (Paul Schlyter) wrote:
> In article <cd7lc2$q52$1...@ottoman.cs.fiu.edu>,
> Zorin the Lynx <ya...@zorin.org> wrote:
>
> > I was an Apple II user for many years in the 80's and early 90's, but I
> > never actually found out exactly what Apple Pascal was, and references
> > online seem to be nonexistent.
> >
>
[...]
>
> Everyting in UCSD Pascal, except the P-machine, was written in UCSD
> Pascal: the IDE, the editor, the Pascal compiler, the library
> functions, the assembler. The assembler was named TLA (The Last
> Assembler) and it was intended to be a universal assembler -
> opcodes/etc for specific CPU's were defined in an accompanying data
> file. The dream of those who wrote that assembler was obviously that
> no other assembler would ever need to be written -- as we all now
> know, this dream didn't come true.
Uh, the GNU Assembler, GAS, is largely table driven.
Apple Pascal was seminal: Pascal inventor Niklaus Wirth worked
with Apple to create Object Pascal. Similar to p-code, portable
bytecode is now all the rage. There was even a command-line
interpreter (Kernighan & Plaugher, Software Tools), as seen in
Linux and MacOS.
Everything old is new again!
John
----
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/
Martin Doherty
> The last version (1.3) utilized the 128K of the //c and IIe. It also
> supported 3.5" disk drives. That 800K of storage was a big improvement
> over 1-4 140K drives.
>
> Roy
I have version 1.2, and it also supports 128K. This is the first
version that came after the release of the //e (but unfortunately for
me, before the release of the 800K drives).
The standard package out of the box is for use on a 64K Apple, as for
the previous versions 1.0 & 1.1. It will also run fine on a 128K Apple
but will ignore the extra RAM.
However, on the APPLE3: volume there are two files, 128K.APPLE and
128K.PASCAL. Users have to create a new 128K system startup disk by
copying these files and renaming them to SYSTEM.APPLE & SYSTEM.PASCAL,
plus copying all the other needed files (SYSTEM.LIBRARY etc).
A Pascal 1.2 128K startup disk will not function on a 64K Apple. I
wonder if 1.3 did away with this fiddle faddle and just delivered a 128K
system as standard? Probably not, since this would have cut loose all
][+ owners.
Martin
Zorin the Lynx
> That's perfectly in keeping with the package, since you had a Hayes
> modem that wasn't controlled by the Hayes modem command set.
The big problem was lack of standard protocols like X-modem, Y-modem,
Z-modem for transferring files. I don't think Y-modem and Z-modem were
around yet at the time, but I think X-modem was, and so was Kermit.
Not supporting these file transfer protocols was pretty much
inexcusable. }:)
-Z
Zorin the Lynx
learn about the fascinating world of Apple Pascal. The fact that it's
interpreted explains why SmartCom I was on the slow side!
It's amazing how much they packed into the tiny memory capacity of the
Apple II back then. A Pascal compiler? Whoah. I have a hard time
imagining it these days with gigs of disk and memory available for us to
waste...
-Z
Paul Schlyter
> Paul Schlyter wrote:
>
>> UCSD Pascal was a 16-bit environment with all the limitations that
>> comes with such an environment such as max 64K address space. Even
>> the Z-machine (the interpreter used for Zork and other Infocom games)
>> had expanded a bit on that and used a 24-bit address space.
>
> The last version (1.3) utilized the 128K of the //c and IIe.
Perhaps by putting the P-machine in parts of it and using the rest
for disk buffers? However, the UCSD system used a 16-bit program
counter, which means the P-code coldn't occupy more than 64K.
CP/M+ did something similar: it used bank switching to store the
BDOS and BIOS in a different memory bank, making a larger part of
the main 64K memory bank available for applications. Although the
applications here executed 8080 machine code rather than P-code.
On the Apple II, the "CP/M Card" had its owh 64K and also used the
Apple's 48K or 64K RAM as the extra memory bank.
> It also supported 3.5" disk drives. That 800K of storage was a big
> improvement over 1-4 140K drives.
I can easily imagine....
A friend of mine patched Apple Pascal 1.1 to run on 80-track double
sided 5.25" floppies, which yielded not 800K but 640K -- but that too
was a huge improvement over the 140K standard Apple II diskettes.
I did the same to Apple DOS 3.3 and Apple CP/M (both Softcard CP/M
and Appli-Card CP/M). And here Apple Pascal and Apple CP/M showed one
big advantage over Apple DOS: one disk volume could be 640K large.
In Apple DOS one disk volume could not be larger than 400K....
Paul Schlyter
John B. Matthews <nos...@nospam.com> wrote:
> In article <cd8bk7$1sjg$1...@merope.saaf.se>,
> pau...@saaf.se (Paul Schlyter) wrote:
>
>> In article <cd7lc2$q52$1...@ottoman.cs.fiu.edu>,
>> Zorin the Lynx <ya...@zorin.org> wrote:
>>
>>> I was an Apple II user for many years in the 80's and early 90's, but I
>>> never actually found out exactly what Apple Pascal was, and references
>>> online seem to be nonexistent.
>>>
>>
> [...]
>>
>> Everyting in UCSD Pascal, except the P-machine, was written in UCSD
>> Pascal: the IDE, the editor, the Pascal compiler, the library
>> functions, the assembler. The assembler was named TLA (The Last
>> Assembler) and it was intended to be a universal assembler -
>> opcodes/etc for specific CPU's were defined in an accompanying data
>> file. The dream of those who wrote that assembler was obviously that
>> no other assembler would ever need to be written -- as we all now
>> know, this dream didn't come true.
>
> Uh, the GNU Assembler, GAS, is largely table driven.
...and GAS was written after TLA, right? Therefore GAS was another
confirmation that TLA wasn't The Last Assembler to be writtten....
I never claimed there would be no other table-driven assembler.....
> Apple Pascal was seminal: Pascal inventor Niklaus Wirth worked
> with Apple to create Object Pascal. Similar to p-code, portable
> bytecode is now all the rage.
....there's one important difference though: the Internet. Now
portable object code is really useful, since it can be transferred
from one computer to another, not only in theory bot also easily in
real life.
Also: the raw CPU power is now so great that it's far beyond what
most people actually need. Back when UCSD Pascal was released the
first time, the world's fastest supercomputer was the Cray-1 - it had
a computing power approximately equivalent to a 500 MHz Pentium-III.
The Cray-1 was quite expensive though -- had it been cheap enough
for anyone to buy and had the UCSD system been implemented for
the Cray-1, UCSD Pascal could have taken off too, perhaps.
> There was even a command-line interpreter (Kernighan & Plaugher,
> Software Tools), as seen in Linux and MacOS.
>
> Everything old is new again!
--
Michael J. Mahon
The "grand idea" behind the UCSD system was not portability
through P-code, since that was inherited directly from Wirth's P2
system, but _compactness_ that made it possible to host Pascal
on a 64KB microcomputer.
P-code and the P-code interpreter were the means to achieve the
needed memory efficiency, and the cost was somwhat slower speed.
A little later, Philippe Kahn saw other ways to achieve the required
compactness to fit a Pascal IDE into 64K, and he did it using
Z-80 machine code in Turbo Pascal.
BTW, putting the P-code interpreter into on-chip ROM, as the p-Engine
did, was hardly making a "hardware" implementation of a P-machine.
I'm reminded of a time in the early-1980s when some wonk at TI said
that now that they could burn software into ROM, making it "hardware",
the industry would finally be freed from software bugs! ;-)
-michael
Check out parallel computing for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/
Moll
> In article <40f7d453$1...@corp.newsgroups.com>, <exe...@nunya.biz> wrote:
>
>>It also supported 3.5" disk drives. That 800K of storage was a big
>>improvement over 1-4 140K drives.
>
>
> I can easily imagine....
>
> A friend of mine patched Apple Pascal 1.1 to run on 80-track double
> sided 5.25" floppies, which yielded not 800K but 640K -- but that too
> was a huge improvement over the 140K standard Apple II diskettes.
> I did the same to Apple DOS 3.3 and Apple CP/M (both Softcard CP/M
> and Appli-Card CP/M). And here Apple Pascal and Apple CP/M showed one
> big advantage over Apple DOS: one disk volume could be 640K large.
> In Apple DOS one disk volume could not be larger than 400K....
I'd like to see something like that. XD Especially since my emulator
supports a block device with 1.4 MB capacity... ^^;;;;;
Moll.
Michael Black
directly interpreted p-code. Instead of 6502 (or any CPU) op-codes, the CPU
would interpret p-code directly. I thought there was at least one very
fancy computer built in Europe that did this, and if I'm remembering, it
used common logic to build it up. But I also thought there was a bit-sliced
computer that interperted p-code directly too.
Michael
Hans Otten
>>
>It's been a long time, but I thought there was a computer or two that
>directly interpreted p-code. Instead of 6502 (or any CPU) op-codes, the CPU
>would interpret p-code directly. I thought there was at least one very
>fancy computer built in Europe that did this, and if I'm remembering, it
>used common logic to build it up. But I also thought there was a bit-sliced
>computer that interperted p-code directly too.
>
Western Digital made a cpu that was a real stack machine with the p-code
instruction set. Not a commecrcial succes, but an important part of the UCSD
Pascal history since it meant that the p-code machine was frozen because it was
not only an interpreter but also hardware.
The language designers of the 70ties and 80ties (e.g. Niklaus Wirth, Per Brinch
Hansen) really believed cpu's to become stack machines, close to what compilers
like the Pascal compilers of these days deliver. It did not happen.
Machines like Lilith and its successors at the ETH Zurich are perhaps what you
remember: also build to support the language where the operating system was
written in: Modula and Oberon.
UCSD Pascal and therefore Apple Pascal made it possible to do things in very
limited hardware enviroments, especially the limited amount of memory and slow
mass storage devices like floppies. P-code takes up little space in memory, much
less than native code. The speed penalty was severe alas with the cpu's of the
old days. The 6502 especially makes it difficult to work efficient as a 16 bit
stack machine. The same applies to current implementations of P-code: the Java
bytecode is also very compact so it is quickly transported over networks. The
slowness due to interpretation is acceptable thanks to the enormous amount of
cpu power available but still impacts java apps.
UCSD and Apple Pascal as an operating system are sub optimal, the Filer and the
on disk structure is quite primitive. Again because of the rigid standardization
in UCSD and the limits of the hardware.
UCSD Pascal played an important and influencal role!
Hans, http://www.hansotten.com
Don Bruder
et...@FreeNet.Carleton.CA (Michael Black) wrote:
I'm absolutely certain that there was a CPU that used P-code as its
native machine language. I'm also absolutely certain that it was
marketed as a (quite pricey, comparatively speaking) card to be plugged
into the Apple II. I *THINK* the card was sold under the name
"P-engine". What I'm not certain about is what the chip number was. For
some reason, the 68000 is ringing a bell, but I'm pretty sure that's not
right, 'cause that was the CPU for the original Mac/Lisa/Apple III, and
NONE of those use P-code natively.
Hans Otten
The Western Digital cpu (a chipset of more IC's, 5 or so) is called Pascal
Micro-Engine, codes were WD-90, WD-900, WD-9000 iirc
Hans, http://www.hansotten.com
Eric Smith
> I'm absolutely certain that there was a CPU that used P-code as its
> native machine language.
The Western Digital WD/9000 Pascal Microengine chipset. A microcoded
16-bit CPU with one data path chip, one control chip, and three
microcode ROMs. The chipset was used in the WD/90, SB1600, and ME1600
computers and WD/900 board-level product.
> I'm also absolutely certain that it was marketed as a (quite pricey,
> comparatively speaking) card to be plugged into the Apple II.
I don't think there was any way using the technology of the day to
package the WD/9000 chipset on an Apple II card, even an oversize (long)
one.
> I *THINK* the card was sold under the name
> "P-engine". What I'm not certain about is what the chip number was.
Perhaps you are thinking of the Stellation II "Mill" card, which used
the Motorola MC6809E processor. It was advertised as speeding up Apple
Pascal, though it did not execute p-code natively.
I've got a card, but no software for it. :-(
Michael J. Mahon
What I meant was that any machine that "runs P-code natively" is,
in fact, running a microcode interpreter of P-code. P-code, as imple-
mented in UCSD Pascal and related systems, is a profoundly hardware-
unfriendly encoding. It takes a great deal of state and several sequential
decoding steps to handle P-code, and the way that is done is by running
a microcode interpreter--as all CISC machines do.
"Machine code" is often quite different from the functional steps actually
performed by the hosting hardware, and in complex machine architectures,
it's microcode that interpretively closes the gap.
In RISC machines, there is no interpretive gap. The machine instruction
set is the hardware instruction set. The possiblity of replacing the on-chip
microcode ROM/PAL with instructions emitted by a compiler and running
in an instruction cache was the central observation that led to RISC machines.
As a further example, look at a typical bit-slice datapath. Examine the
operations directly supported. Those are the hardware operations. Anything
going beyond that in complexity or generality is done in microcode--which
is just another name for "software built into the chip".
Paul Schlyter
Well, it would take a lot of work. In the case of Apple Pascal, it
involved boot tracing, disassembly of the P-machine and then figuring
out how the disk access parts worked.
Apple DOS 3.3 would be simpler, since it's so well documented.
And CP/M is already adapted for configurations to disk drives of
various sizes - the CP/M alteration guide describes how the disk
parameter tables need to be modified to the disk size you want to
use. Some adaption need to be done at the BIOS level too.
Paul Schlyter
Michael J. Mahon <mjm...@aol.com> wrote:
> Zorin the Lynx wrote:
>
>> Thanks for the great answers.. I used them to do a bit more research to
>> learn about the fascinating world of Apple Pascal. The fact that it's
>> interpreted explains why SmartCom I was on the slow side!
>>
>> It's amazing how much they packed into the tiny memory capacity of the
>> Apple II back then. A Pascal compiler? Whoah. I have a hard time
>> imagining it these days with gigs of disk and memory available for us to
>> waste...
>
> The "grand idea" behind the UCSD system was not portability
> through P-code, since that was inherited directly from Wirth's P2
> system, but _compactness_ that made it possible to host Pascal
> on a 64KB microcomputer.
>
> P-code and the P-code interpreter were the means to achieve the
> needed memory efficiency, and the cost was somwhat slower speed.
>
> A little later, Philippe Kahn saw other ways to achieve the required
> compactness to fit a Pascal IDE into 64K, and he did it using
> Z-80 machine code in Turbo Pascal.
No, Philippe Kahn didn't do that. The one who did it was Anders
Hejlsberg from Denmark. Originally his compiler+IDE was sold in
Denmark under the name "Compas Pascal" (later "Poly Pascal") -
although the functionality was almost identical to Turbo Pascal, the
screen layout was a bit different. And the one-letter IDE commands
had to be followed by pressing the "return" key in Compas/Poly
Pascal; Turbo Pascal removed the requirement of pressing Return after
the one-letter commands.
Anders Hejlsberg also went to the US. He visited Microsoft and asked
if they were interested in his compiler, but Microsoft SAID NO !!!
(that's almost as when Decca Records said "no" to The Beatles in 1962).
So Anders looked for other US companies, and he found a little basement
company called Borland, which at that time consisted of hardly anyone
but Philippe Kahn. Kahn was interested - and the rest is history.
In the early days of Turbo Pascal, Compas Pascal and Poly Pascal was
sold in parallell, but only in Scandinavia I believe.
Anyway, nowadays Anders Hejlsberg has been bought back by Microsoft,
and the language C# is a creation by him. And just like Turbo Pascal
was a non-compliant Pascal, C# is a non-compliant Java. But C#
cannot be called "Turbo Java" or something which even contains "Java"
because then Microsoft would definitely be sued by Sun who holds the
copyright on that name. And the standardisation issue is opposite in
C# than it was in Turbo Pascal: while Turbo Pascal deviated from the
Pascal standard, C# ("Turbo Java") is now an ECMA standard while
Sun so far has refused to have Java standardized.
> BTW, putting the P-code interpreter into on-chip ROM, as the p-Engine
> did, was hardly making a "hardware" implementation of a P-machine.
> I'm reminded of a time in the early-1980s when some wonk at TI said
> that now that they could burn software into ROM, making it "hardware",
> the industry would finally be freed from software bugs! ;-)
>
> -michael
>
> Check out parallel computing for 8-bit Apples on my
> Home page: http://members.aol.com/MJMahon/
--
Roger Johnstone
>
> I'm absolutely certain that there was a CPU that used P-code as its
> native machine language. I'm also absolutely certain that it was
> marketed as a (quite pricey, comparatively speaking) card to be
> plugged into the Apple II. I *THINK* the card was sold under the name
> "P-engine". What I'm not certain about is what the chip number was.
> For some reason, the 68000 is ringing a bell, but I'm pretty sure
> that's not right, 'cause that was the CPU for the original Mac/Lisa/
> Apple III, and NONE of those use P-code natively.
Ahem, the Apple III used a 6502 CPU, not a 68000.
There were third-party 68000 cards for the Apple II though, and I know
some of the various coprocessor cards had patches to speed up BASIC by
allowing the CPU on the card to execute the floating-point calculations.
Maybe one of these had a patch to run p-code on the 68000?
--
Roger Johnstone, Invercargill, New Zealand
http://vintageware.orcon.net.nz/
________________________________________________________________________
No Silicon Heaven? Preposterous! Where would all the calculators go?
Kryten, from the Red Dwarf episode "The Last Day"
exe...@nunya.biz
Paul Schlyter wrote:
> In article <40f7d453$1...@corp.newsgroups.com>, <exe...@nunya.biz> wrote:
>
>>Paul Schlyter wrote:
>>
>>
>>>UCSD Pascal was a 16-bit environment with all the limitations that
>>>comes with such an environment such as max 64K address space. Even
>>>the Z-machine (the interpreter used for Zork and other Infocom games)
>>>had expanded a bit on that and used a 24-bit address space.
>>
>>The last version (1.3) utilized the 128K of the //c and IIe.
>
>
> Perhaps by putting the P-machine in parts of it and using the rest
> for disk buffers? However, the UCSD system used a 16-bit program
> counter, which means the P-code coldn't occupy more than 64K.
The 64K system allows 32 segments, the 128K system 64 segments (whatever
that means) In addition, 64K allows one library on line per program,
128K allows up to six libraries on line per program. The Editor has a
file capacity of 17920 characters in the 64K system, 32256 with the 128K
system. In the 64K system about 38K is available for P-code, 6502 code,
and data. They all share the same memory space. In the 128K system,
about 43K is available for 6502 code and data. An additional 38K or so
is available for P-code
The above are quotes from the Apple II Pascal 1.3 Workbench.
Roy
>
> CP/M+ did something similar: it used bank switching to store the
> BDOS and BIOS in a different memory bank, making a larger part of
> the main 64K memory bank available for applications. Although the
> applications here executed 8080 machine code rather than P-code.
> On the Apple II, the "CP/M Card" had its owh 64K and also used the
> Apple's 48K or 64K RAM as the extra memory bank.
>
>
>>It also supported 3.5" disk drives. That 800K of storage was a big
>>improvement over 1-4 140K drives.
>
>
> I can easily imagine....
>
> A friend of mine patched Apple Pascal 1.1 to run on 80-track double
> sided 5.25" floppies, which yielded not 800K but 640K -- but that too
> was a huge improvement over the 140K standard Apple II diskettes.
> I did the same to Apple DOS 3.3 and Apple CP/M (both Softcard CP/M
> and Appli-Card CP/M). And here Apple Pascal and Apple CP/M showed one
> big advantage over Apple DOS: one disk volume could be 640K large.
> In Apple DOS one disk volume could not be larger than 400K....
>
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
Don Bruder
Roger Johnstone <roj...@orcon.net.nz> wrote:
> In <%sWJc.2715$54.3...@typhoon.sonic.net> Don Bruder wrote:
> >
> > I'm absolutely certain that there was a CPU that used P-code as its
> > native machine language. I'm also absolutely certain that it was
> > marketed as a (quite pricey, comparatively speaking) card to be
> > plugged into the Apple II. I *THINK* the card was sold under the name
> > "P-engine". What I'm not certain about is what the chip number was.
> > For some reason, the 68000 is ringing a bell, but I'm pretty sure
> > that's not right, 'cause that was the CPU for the original Mac/Lisa/
> > Apple III, and NONE of those use P-code natively.
>
> Ahem, the Apple III used a 6502 CPU, not a 68000.
Gack! Correct you are. I should know that, too, since I just finished
dinking around inside a III that's certifiably Tango Uniform.
> There were third-party 68000 cards for the Apple II though, and I know
> some of the various coprocessor cards had patches to speed up BASIC by
> allowing the CPU on the card to execute the floating-point calculations.
> Maybe one of these had a patch to run p-code on the 68000?
I'm thinking that the card I was thinkgin of was the Stellation P-mill,
with the 6809, that someone else mentioned. That's not just ringing *A*
bell, it's got Quasimodo making triple overtime. :)
John B. Matthews
wrote:
> The 64K system allows 32 segments, the 128K system 64 segments (whatever
> that means) In addition, 64K allows one library on line per program,
> 128K allows up to six libraries on line per program.
Executables and libraries consist of code and (optional) data
segments. A code segment can be dynamically swapped into memory
as needed. You can use the program LIBRARY.CODE to create new
libraries by copying segments from other files. You can use the
program LIBMAP.CODE to examine existing executables.
For example, the program FORMATTER.CODE consists of just one
code segment (its data is in a separate file, FORMATTER,DATA):
LIBRARY MAP FOR formatter.code
Segment # 1:
System version = A2/1.3, code type is 6502
FORMATTE completely linked segment
In contrast, the pascal compiler itself is a mix of 6502 and
p-code segments:
LIBRARY MAP FOR system.compiler
COPYRIGHT 1979,1980,1983-1985 APPLE COMPUTER, INC. ALL RIGHTS
RESERVED
Segment # 1:
System version = A2/1.3, code type is 6502
PASCALCO completely linked segment
------------------------------------------------------------
Segment # 7:
System version = A2/1.3, code type is P-Code (least sig. 1st)
COMPINIT completely linked segment
------------------------------------------------------------
Segment # 8:
System version = A2/1.3, code type is P-Code (least sig. 1st)
DECLARAT completely linked segment
etc.
The SYSTEM.LIBRARY is especially revealing:
LIBRARY MAP FOR system.library
COPYRIGHT 1979,1980,1983-1985 APPLE COMPUTER, INC. ALL
RIGHTS RESERVED
Segment #30:
System version = A2/1.3, code type is 6502
LONGINTI library unit (LINKED INTRINSIC)
TYPE DECMAX = INTEGER[36];
STUNT = RECORD CASE INTEGER OF
2:(W2:INTEGER[4]);
3:(W3:INTEGER[8]);
4:(W4:INTEGER[12]);
5:(W5:INTEGER[16]);
6:(W6:INTEGER[20]);
7:(W7:INTEGER[24]);
8:(W8:INTEGER[28]);
9:(W9:INTEGER[32]);
10:(W10:INTEGER[36])
END;
PROCEDURE FREADDEC(VAR F: FIB; VAR D: STUNT; L: INTEGER);
PROCEDURE FWRITEDEC(VAR F: FIB; D: DECMAX; RLENG: INTEGER);
------------------------------------------------------------
Segment #31:
System version = A2/1.3, code type is P-Code (least sig. 1st)
PASCALIO library unit (LINKED INTRINSIC)
TYPE DECMAX = INTEGER[36];
STUNT = RECORD CASE INTEGER OF
2:(W2:INTEGER[4]);
3:(W3:INTEGER[8]);
4:(W4:INTEGER[12]);
5:(W5:INTEGER[16]);
6:(W6:INTEGER[20]);
7:(W7:INTEGER[24]);
8:(W8:INTEGER[28]);
9:(W9:INTEGER[32]);
10:(W10:INTEGER[36])
END;
PROCEDURE FSEEK(VAR F: FIB; RECNUM: INTEGER);
PROCEDURE FREADREAL(VAR F: FIB; VAR X: REAL);
PROCEDURE FWRITEREAL(VAR F: FIB; X: REAL; W, D: INTEGER);
PROCEDURE FREADDEC(VAR F: FIB; VAR D: STUNT; L: INTEGER);
PROCEDURE FWRITEDEC(VAR F: FIB; D: DECMAX; RLENG: INTEGER);
FUNCTION SUPER_MOD(A,B : INTEGER) : INTEGER;
FUNCTION SUPER_DIV(A,B : INTEGER) : INTEGER;
------------------------------------------------------------
Segment #28:
System version = A2/1.3, code type is P-Code (least sig. 1st)
CHAINSTU library unit (LINKED INTRINSIC)
PROCEDURE SETCHAIN(TYTLE:STRING);
PROCEDURE SETCVAL(VAL:STRING);
PROCEDURE GETCVAL(VAR VAL:STRING);
PROCEDURE SWAPON;
PROCEDURE SWAPOFF;
PROCEDURE SWAPGPON;
------------------------------------------------------------
Segment #29:
System version = A2/1.3, code type is P-Code (least sig. 1st)
TRANSCEN library unit (LINKED INTRINSIC)
FUNCTION SIN(X:REAL):REAL;
FUNCTION COS(X:REAL):REAL;
FUNCTION EXP(X:REAL):REAL;
FUNCTION ATAN(X:REAL):REAL;
FUNCTION LN(X:REAL):REAL;
FUNCTION LOG(X:REAL):REAL;
FUNCTION SQRT(X:REAL):REAL;
------------------------------------------------------------
Segment #20:
System version = A2/1.3, code type is 6502
TURTLEGR library unit (LINKED INTRINSIC)
TYPE
SCREENCOLOR=(none,white,black,reverse,radar,
black1,green,violet,white1,black2,orange,blue,white2);
PROCEDURE INITTURTLE;
PROCEDURE TURN(ANGLE: INTEGER);
PROCEDURE TURNTO(ANGLE: INTEGER);
PROCEDURE MOVE(DIST: INTEGER);
PROCEDURE MOVETO(X,Y: INTEGER);
PROCEDURE PENCOLOR(PENMODE: SCREENCOLOR);
PROCEDURE TEXTMODE;
PROCEDURE GRAFMODE;
PROCEDURE FILLSCREEN(FILLCOLOR: SCREENCOLOR);
PROCEDURE VIEWPORT(LEFT,RIGHT,BOTTOM,TOP: INTEGER);
FUNCTION TURTLEX: INTEGER;
FUNCTION TURTLEY: INTEGER;
FUNCTION TURTLEANG: INTEGER;
FUNCTION SCREENBIT(X,Y: INTEGER): BOOLEAN;
PROCEDURE DRAWBLOCK(VAR SOURCE;
ROWSIZE,XSKIP,YSKIP,WIDTH,HEIGHT,
XSCREEN,YSCREEN,MODE: INTEGER);
PROCEDURE WCHAR(CH: CHAR);
PROCEDURE WSTRING(S: STRING);
PROCEDURE CHARTYPE(MODE: INTEGER);
------------------------------------------------------------
Segment #21:
System version = A2/1.3, code type is P-Code (least sig. 1st)
TURTLEGR data segment
------------------------------------------------------------
Segment #22:
System version = A2/1.3, code type is 6502
APPLESTU library unit (LINKED INTRINSIC)
FUNCTION PADDLE(SELECT: INTEGER): INTEGER;
FUNCTION BUTTON(SELECT: INTEGER): BOOLEAN;
PROCEDURE TTLOUT(SELECT: INTEGER; DATA: BOOLEAN);
FUNCTION KEYPRESS: BOOLEAN;
FUNCTION RANDOM: INTEGER;
PROCEDURE RANDOMIZE;
PROCEDURE NOTE(PITCH,DURATION: INTEGER);
Michael J. Mahon
>> A little later, Philippe Kahn saw other ways to achieve the required
>> compactness to fit a Pascal IDE into 64K, and he did it using
>> Z-80 machine code in Turbo Pascal.
>
>No, Philippe Kahn didn't do that. The one who did it was Anders
>Hejlsberg from Denmark. Originally his compiler+IDE was sold in
>Denmark under the name "Compas Pascal" (later "Poly Pascal")
<snip>
Thanks, Paul, for setting me straight on that.
I think I recall hearing about Anders before, but blanked on it
because of Philippe's bigger profile. ;-)
Turbo Pascal was certainly a _tour de force_ in tight programming
and programmer-oriented interface design--he deserves accolades!