Re: What exactly WAS Apple Pascal?

[mjmahon@aol.com (Michael J. Mahon)]

Don Bruder replied:

>In article <cd955v$2l6$1@freenet9.carleton.ca>,
> et472@FreeNet.Carleton.CA (Michael Black) wrote:
>
>> Michael J. Mahon (mjmahon@aol.com) writes:
>> > 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.
>> > 
>> > 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!  ;-)
>> > 
>> 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.
>> 
>>    Michael
>> 
>
>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.

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".

-michael

Check out parallel computing for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/