Apple III Pascal

When Apple developed its Apple /// computer (1980 – 1985, 6502 CPU, 2 MHZ), it developed most of its software for this machine with Pascal.
Apple used the Apple ][ Pascal system to create the Apple /// Pascal system. As such, /// Pascal generated P-Codes for a stack-based architecture. The ///’s Pascal language syntax was extended (e. g. otherwise clause in case statements) and like Apple ][ Pascal also supported separate program units. Access to the ///’s native 6502-based operating system, SOS (Sophisticated Operating System, or Sara’s OS), also existed via a special Pascal unit called SOSIO. This OS unit also allowed programmers access to the ///’s larger memory, 256k bytes vs. 64k bytes for the ][ computer.
Apple produced several versions of Apple /// Pascal: 1. 0, 1. 1, 1. 2, 2.0.
Version 2.0 of /// Pascal was unique in that it came with extensive technical documentation called the /// Pascal Workbench and consisted of around 1,000 pages. Version 2. 0’s Pascal compiler also produced a compilation listing consisting of the generated P-Code interleaved with the Pascal source code lines. /// Pascal also supported via a conditional compilation directive the compilation of Apple ][ Pascal programs and produced Apple ][ format code files.

Documentation for the /// Pascal system was excellent. This included a language manual, an operating system manual, and a very detailed runtime architecture manual which also listed all the P-Codes.
For /// Pascal Apple developed a very sophisticated floating-point implementation called SANE (Standard Apple Numeric Environment). SANE was based upon the IEEE floating-point standard. /// Pascal versions 1.0 and 1.1 supported only 4 byte REAL numbers, version 1.2 supported the higher quality 8 byte EXTENDED numbers. SANE went on to become the floating-point engine for Apple’s Lisa and Macintosh computers.

Most of Apple’s software for the /// was developed with the Pascal system. This included the System Utility Program and Backup ///.
The key players for Apple /// Pascal were Ira Rubin and Al Hoffmann. Support for /// Pascal ended when Apple discontinued the /// computer in 1985. From this date onwards Apple seems to have ended its involvement with Pascal which generated P-Code, opting
instead to deal fully with native code generators.

Documents on Apple III Pascal

Introduction, Filer and Editor
Programmer’s Manual Volume 1
Programmer’s Manual Volume 2
Apple III Pascal 1.1 Update
Pascal Technical Reference Manual.
Scanned by Dave Schmenk
Apple III Pascal – Technical Reference Manual
suppplement SOS
Numerics Manual:
A Guide to Using the Apple III
Pascal SANE and Elems Units.
Scanned by Dave Schmenk

Apple III Pascal software

In PRODOS format, inspect with Ciderpress.
Apple 3 Pascal version 1.0 Disk 1 – Bad Filer program
Apple 3 Pascal version 1.0 Disk 2
Apple 3 Pascal version 1.0 Disk 3
Apple 3 Pascal version 1.1 Disk 1
Apple 3 Pascal version 1.1 Disk 2
Apple 3 Pascal version 1.1 Disk 3
Apple 3 Pascal version 1.2 Update Disk 1
Apple 3 Pascal version 1.2 Update Disk 2
Apple 3 Pascal Toolkit Version 1.0B Volume 1
Apple 3 Pascal-Based SOS Access Routines – Source (Paul Hagstrom)

Apple III Pascal Technotes

RPS File Space Allocation
Printing from BASIC and Pascal
Mapping of SOS error codes
SOS Error Codes
SYSTEMP0000X files
Passing strings to and from functions in Pascal III
Reading special keyboard characters (1 of 2)
Reading special keyboard characters (2 of 2)
Apple II Parallel Printer Interface Cable Issue
Changing text modes
Comparison to Apple II Pascal (1 of 2)
Comparison to Apple II Pascal (2 of 2)
Error code summary
Pascal III Editor: Inserting control characters
Listing large directories
SEEK
Accessing the extra memory (1 of 5)
Accessing the extra memory (2 of 5)
Accessing the extra memory (3 of 5)
Accessing the extra memory (4 of 5)
Accessing the extra memory (5 of 5)
Typeahead Killer
Intrinsic Units
Regular Units
Apple III: Pascal ToolKit
Apple III: Console Driver–Screen Mode Switching Program
Apple III: Console Driver–Changing the Character Set
Apple III: Manual Errata–Standard Device Drivers Manual

Test Apple Pascal III

A real Apple III is a collectors item and hard to find in working state.
There is a working emulator with pre-installed Apple pascal and more as part of the MESS suite.
Here is a link to the emulator

post

Pascal-M 1978 Cross compiler

The original 1978 version of Pascal-M, a P2 descendent, has been restored. Original source, which can compile itself, is now available, as a cross compiler, an interpreter in Pascal with debugging facilities, a binary loader for the KIM-1 6502 interpreter and a disassembler for M-code. Together with the already available source of the KIM-1 V1 interpreter all parts of the 1978 compiler are now available in source and compiled/assembled format.

Though compiling itself is a very good test of the compiler, which showed many bugs from typing in and some original present bugs, not too much testing has been done.

I start working now on V1.5 of the cross compiler and leave this V1.0 version as ‘completed’ and ‘historical purposes’.

P5 Pascal

The next text and files are by Scott Moore, www.standardpascal.org/p5.html and https://sourceforge.net/p/pascalp5/wiki/Home/
Local copy here.
He deserves all the honours of making this public available! The “I’ is Scott, not me!

The P5 compiler

Pascal-P5 is available on sourceforge here:
https://sourceforge.net/projects/pascalp5/
Local copy here.
The P5 compiler has existed for a long time as an idea. P4, the last of the Zurich series P-system compilers, left off before the ISO 7185 standard in 1982. It was not only not standard Pascal compliant, it also was only a subset, abeit a substantial one, of full revised Pascal. As an example, or "model" implementation of Pascal, it would have made sense to update the compiler to ISO 7185 status, and that was basically done as "A Model Implementation of Standard Pascal" [Welsh&Hay] before 1986. In fact, the project was designed to support the ISO 7185 project. However, there were a few reasons that a true P5, a straightforward update of the old p4, was a good idea. First, the source code of the "Model Implementation" is not generally available. Second, the "Model Implementation" is a complete scratch rewrite of the compiler, and shares virtually nothing in common with the original P4. This was important because several books, articles and online resources exist for the P4 compiler What I wanted for p5 was a compiler that both accepted ISO 7185 standard Pascal, and was also written in it. The compiler is an extended version of P4 and uses the same intermediate codes where possible. P5 now accepts the full ISO 7185 language, and also has been remade as a byte oriented machine, similar to what was done for both the UCSD compiler and the "Model Implementation". This is is the key to achieving a high efficiency implementation that runs with compact code. P5 also runs the PAT or Pascal Acceptance test, and also self compiles. P5 correctly runs the BSI, or British Standards Institute tests.

The meaning of P5

P5 is a very important milestone for Pascal. To understand why, it is a good idea to review why P4 was important. P4 was to accomplish:

  • Gave an example compiler for the Pascal language.
  • Gave a "model" of Pascal more complete than any description
    (i.e., the effect of any program construct could ultimately be determined
    by running it on P4).
  • Provided a bootstrapping kit to create new Pascal compilers.

To understand why P5 is important, you must understand that P4 didn’t completely accomplish the above goals. First of all, P4 was a subset of the full language. It was never designed to run the full language, only a minimal subset that could be ported to a new machine. The idea was to finish out the full language on the target machine.
Unfortunately, that meant there was not a concrete model of some of the more advanced (and hard to implement) features of full Pascal, for example interprocedural gotos, and procedure and function parameters. These and other features of Pascal left out of P4 were often left out of target compilers, and when they were implemented, they were implemented wrong. The other issue is that P4 was designed to be a minimal bootstrap implementation. If you examine P4, you will see that it makes little use of strings, and keeps them short. This is because it is very inefficient when it comes to storing them in memory. They are stored one character to a word (60 bits on the CDC 6000). Pascal has packing, but that is not implemented in P4. Finally, P4 is very much oriented to the CDC 6000 that it originated on. Everything is stored in 60 bit words, and there is a packing system designed to store two instructions per word.
The reason P4 had these limitations is that memory was very limited back in the 1970s, when P4 came about. Even on the CDC 6000. The authors of P4 worked hard to get P4 down in size and memory requirements so that it would self compile. By the time of the ISO 7185 standard, many people understood that P4 was limited for its purposes. The "Model Implementation of Standard Pascal" [Welsh & Hay] was the answer, and it contained a compiler for the full ISO 7185 Pascal language. Further, it implemented the interpreter as a byte oriented machine (sometimes called a "bytecode machine"). Unfortunately, it got sucked up into the BSI, who have effectively killed it (there appear to be no internet copies of it, and the BSI has not been forthcoming concerning it). Another issue with the "Model Implementation" (with apologies to Jim Welsh and Atholl Hay), is that the MI is written in the "self documented" form (avocated by D. E. Knuth and others) where the entire documentation exists in the same file, intermixed with the code. This is a beautiful method to present code as a finished product, but it tends to be fairly difficult to work on an change. Finally, the MI was a complete break with P4, and had nothing in common with it. This meant that MI used completely new methods and documentation, whereas P4 was already documented in the common media and well understood. P5 is both a break with the past and an embrace of it:

  • P5 is a straighforward extention of P4, and so most of the documentation
    and methods used with P4 are applicable to P5.
  • P5 completely implements ISO 7185.
  • P5 serves as a complete model for the implementation of Pascal.
  • P5 can be used to bootstrap both new compilers, and can efficiently
    self compile without limitations.
  • P5 is oriented toward byte machines, which is virtually all machines
    available today.
  • P5 can be used as a working interpreter, useful for running real programs.

The PAT and PRT

The PAT or Pascal acceptance test is a series of tests in one file that go through each feature of ISO 7185 Pascal. If a ISO 7185 Pascal implementation can compile and run this correctly, then it is substantially compliant with ISO 7185 Pascal.
There are two types of tests, the PAT and the PRT, or Pascal Rejection Test. The PAT test should compile and run correctly, and is a "positive" indication that the implementation compiles standard structures and gives standard results. The PRT is the opposite. It is designed to either fail to compile or generate runtime errors or both. It is a "negative" test that makes sure that the implementation rejects non-standard structures. The PAT only is represented here (for now).

Relationship to the BSI test suite

The BSI test suite [covered in Wichmann&Ciechanowicz] includes both positive and negative testing, and appeared in original version in the Pascal User’s Group. After a great deal of trouble I was able to OCR a copy of that test, which was published free and clear of restrictions. However, the both the test suite and bore copyright notices at one point, and both were given to the BSI (British Standards Institute) to keep and distribute. The BSI no longer distributes either, at any price, and whether they have kept it is also in doubt. In fact, recently I have been calling them about once a month to find out any information about the pair of programs. Both of them were created at universities outside of the BSI, and both were intended to be distributed, not locked in a vault to be eventually discarded. I don’t and won’t distrubute the BSI test without permission, and I don’t have access to the model compiler. Even with the BSI status of "openly published, but rights kept", I don’t feel comfortable putting it up on this site. However, because it was in fact openly published, I don’t feel that I, as an individual, am unable to run the tests, either. Now, the reason that all of this matters is that with P5, we have effectively replaced the material imprisoned by the BSI. P5 upgrades P4, which never bore a copyright, was public domain, and was distributed openly. I put my own work into upgrading P4 into P5, but I donate that work back to the public domain. As P4 was, P5 is free of copyright and charges. Use as you see fit. The PAT was created entirely by me and is original work. However, I also donate this to public domain. It was created back in the early 1990’s, and used to validate both mine and other Pascal compilers. The PAT effectively replaces the positive testing side of the BSI. I also intend to create a negative test, the PRT, and also make that public domain. Further, the PAT and PRT form a collection point for tests, including test that were made in reaction to the failures seen while running the BSI tests. In other words, if the BSI test found a failure, then an equivalent test was added to the PAT (not copied from the BSI!). This is a work in progress, so not all failure points have yet been addressed. Thus, the PAT and PRT are designed to be full replacements for the BSI tests. Format and working of the PAT The PAT is designed to execute a small amount of code, then print the results. Each "test point" tests one feature of ISO 7185 Pascal,and is numbered according to type and sequence. Here is an example from the test:

  write('Control6: ');
  if true then write('yes') else write('no');
  writeln(' s/b yes');

This prints:

Control 6: yes s/b yes

So you see the number and type of the test, control structures number 6, the result, ‘yes’, and finally what the result should be. The PAT is designed to be verified manually, that is, you read it and check that the printed results equal the "should be" collumn. The PAT can be easily automated for regression purposes by redirecting the output to a file, then comparing a saved "gold" version of the result file to the current file.

Self compile

P5 is capable compiling itself. This takes different steps for each of the sections, pcom and pint. The resulting intermediate files are listed in the files section below.

pcom

I was able to get pcom.pas to self compile. This means to compile and run pcom.pas, then execute it in the simulator, pint. Then it is fed its own source, and compiles itself into intermediate code. Then this is compared to the same intermediate code for pcom as output by the regular compiler. Its a good self check, and in fact found a few bugs.
The Windows batch file to control a self compile and check is:
cpcoms.bat
What does it mean to self compile? For pcom, not much. Since it does not execute itself (pint does that), it is simply operating on the interpreter, and happens to be compiling a copy of itself.

Changes required

pint

Pint is more interesting to self compile, since it is running (being interpreted) on a copy of itself. Unlike the pcom self compile, pint can run a copy of itself running a copy of itself, etc., to any depth. Of course, each time the interpreter runs on itself, it slows down orders of magnitude, so it does not take many levels to make it virtually impossible to run to completion. Ran a copy of pint running on itself, then interpreting a copy of iso7185pat. The result of the iso7185pat is then compared to the "gold" standard file. As with pcom, pint will not self compile without modification. It has the same issue with predefined header files. Also, pint cannot run on itself unless its storage requirements are reduced. For example, if the "store" array, the byte array that is used to contain the program, constants and variables, is 1 megabyte in length, the copy of pint that is hosted on pint must have a 1 megabyte store minus all of the overhead associated with pint itself. The windows batch file required to self compile pint is:
cpints.bat
As a result, these are the changes required in pint:

{ !!! Need to use the small size memory to self compile, otherwise, by 
  definition, pint cannot fit into its own memory. }
maxstr = 2000000; { maximum size of addressing for program/var }
 {maxstr = 200000;} { maximum size of addressing for program/var }

and
{ !!! remove this next statement for self compile }
prd,prr : text;(*prd for read only, prr for write only *)

and
{ !!! remove this next statement for self compile }
reset(prd);

and
{ !!! remove this next statement for self compile }
rewrite(prr);

All these changes were made in the file pintm.pas.
Pint also has to change the way it takes in input files. It cannot read the intermediate from the input file, because that is reserved for the program to be run. Instead, it reads the intermediate from the "prd" header file. The interpreted program can also use the same prd file. The solution is to "stack up" the intermediate files. The intermediate for pint itself appears first, followed by the file that is to run under that (iso7185pat). It works because the intermediate has a command that signals the end of the intermediate file, "q". The copy of pint that is reading the intermediate code for pint
stops, then the interpreted copy of pint starts and reads in the other part of the file. This could, in fact, go to any depth. All of the source code changes from pint.pas to pintm.pas are automated in cpints.bat.

Self compiled files and sizes

The resulting sizes of the self compiled files are:

pcomm.p5
Storage areas occupied
=====================================
Program             0-114657( 114658)
Stack/Heap   114658-1987994 (1873337)
Constants   1987995-2000000 (  12005)

pintm.p5
Storage areas occupied
=====================================
Program             0- 56194 ( 56195)
Stack/Heap    56195-1993985 (1937791)
Constants     1993986-2000000 ( 6014)

Files for the P5 system

Pascal-P5 is entirely hosted on sourceforge now. Please see the site for all sources:
https://sourceforge.net/projects/pascalp5/
Local copy here.
This lets you access my development link for Pascal-P5. You can use this to:

  • download the entire source tree.
  • browse individual files
  • retrieve old versions
  • File bugs or requests
  • Track the status of or find existing problems/issues
  • Become a co-developer

And much more.
For versioned files (releases) see the files area. The current version is always archived as pascal-p5.tar.gz. The current and previous versions are named as:

pascal-p5_<major version>_<minor version>

That is, each time I create a new version, I make a copy of it using the naming system above. This allows each version to be recovered and used. To get a current development copy of Pascal-P5 source, simply have GIT installed on your system, and execute the following in the directory where you wish to install P5: git clone ssh://samiam95124@git.code.sf.net/p/pascalp5/code pascalp5-code This will get the entire P5 file tree and place it into the target directory "p5".

A note about versioning

My common practice is to "bump" the version numer after any changes are made to a certified release. The idea is that the new version number will be the version of the next release to come. This of course can cause confusion. However, the rule, is: if it is not in the above release list, then it is a development version.

Getting started

For all versions see the readme.txt file in the root directory.

Compiling and using P5

The P5 compiler/assembler is much easier than P4 in one respect. There are no limitations to remember verses ISO 7185 Pascal. If it is legal Standard Pascal, it will compile and run.

To run P5, use the following format:

pcom intermediate.int < source.pas
pint intermediate.int program.out

All files must be specified. This is what the batch file p5.bat given above does.

What is.. and is not in P5

While upgrading P4 to P5, I specifically tried to avoid any temptation to "improve" the code, such as add functions or features, or reformat the code to be more presentable, etc. There is a time and place for that. I simply wanted P5 to be a full language compiler for Pascal, instead of a subset compiler. The one exception I allowed for is the addition of a routine that dumps all of the error codes that were used in the source compile along with their text equivalents. I have found this to be a great improvement on trying to search the various documents for what error code means what. Of course, virtually all implementations improve on the original Pascal, including the original CDC 6000 compiler. The extensions consist of a combination of features best left defined to a particular implementation, and also usablity extentions to Pascal in general. There’s a lot more that can be done with P5. However, I have left that for the P6 project. P6 is the next step for the P-series, and includes a series of extentions to the base ISO 7185 language.

For more information contact: Scott A. Moore

Stanford Pascal 360

The Stanford Pascal 360 (1979 version) is a modified version of the P2 Compiler, and except for a few minor extensions, processes the same language. The compiler itself is a 5000 lines Pascal program that translates to P-code. A post processor then translates P-code to IBM assembly code.

The later Stanford Pascal compiler is an offspring of the original Pascal P4 compiler.

A compiler based on the Pascal-P4 compiler, which created native binaries, was released for the IBM System/370 mainframe computer
by the Australian Atomic Energy Commission; it was called the “AAEC Pascal Compiler” after the abbreviation of the name of the Commission.

The AAEC compiler later became the Stanford Pascal compiler (in 1979 ca.), and later again, it was maintained by the McGill university in Montreal, Canada (from 1982 on).

New Stanford Pascal:

CS-TR-79-731.pdf Stanford Pascal Verifier User Manual, March 1979
TN164_A_Pascal_P-Code_Interpreter_for_the_Stanford_Emmy_Sep79.pdf
October 1974 Stanford Pascal/360 Implementation Guide, contains source of compiler (4665 lines)
pcode_1978.pdf
Stanford1979.pdf
pascal_master.zip many original sources (and later improved versions of Stanford Pascal, part of the Bernd Oppolzer initiative.

PDP-11 Pascal compiler

Archive with the DECUS DEC PDP-11 Pascal compiler, including sources.

This compiler is a descendent of the ZürichPascal compilers.

            DECUS Pascal for PDP-11
	          ===========================

	          Version 6.3,  November 1985


Abstract:

This compiler implements the Pascal programming language on PDP-11s
running RSX-11 and on other systems that can run RSX tasks (eg. RSTS,
VAX AME).

The main features of this Pascal are:
  - can optionally compile programs to use any arithmetic hardware
  - useful language extensions: default case, loop statement, variable
    length string parameters, substring parameters, structured function
    results, boundless array parameters, and more
  - enhanced I/O facilities for creating and accessing files of
    various types
  - standard file for terminal I/O
  - separate compilation of procedures/functions
  - linkage to external FORTRAN or MACRO routines
  - source "include" facility
  - development aids: statement trace, statement execution profiler,
    conditional compilation
  - high level interactive symbolic debugger and symbolic dump
  - all source and tools provided for maintaining the compiler and
    runtime library (compiler can only be re-compiled on RSX-11).

This release introduces several minor corrections and enhancements.
In particular it now runs on the latest versions of RSTS and RSX.


Restrictions:
Several deviations from the ISO/ANSI Pascal Standard.  (Conformance
report in user manual.)

PICL

The Language PICL and its Implementation, Niklaus Wirth, 20. Sept. 2007

PICL is a small, experimental language for the PIC single-chip microcomputer. The class of computers which PIC represents is characterized by a wordlength of 8, a small set of simple instructions, a small memory of at most 1K cells for data and equally much for the program, and by integrated ports for input and output. They are typically used for small programs for control or data acquisition systems, also called embedded systems. Their programs are mostly permanent and do not change.
All these factors call for programming with utmost economy. The general belief is that therefore programming in a high-level language is out of the question. Engineers wish to be in total control of a program, and therefore shy away from complex languages and compiler generating code that often is unpredictable and/or obscure.
We much sympathize with this reservation and precaution, particularly in view of the overwhelming size and complexity of common languages and their compilers. We therefore decided to investigate, whether or not a language could be designed in such a way that the reservations would be unjustified, and the language would indeed be beneficial for programmers even of tiny systems.
We chose the PIC processor, because it is widely used, features the typical limitations of such single-chip systems, and seems to have been designed without consideration of high-level language application. The experiment therefore appeared as a challenge to both language design and implementation.
The requirements for such a language were that it should be small and regular, structured and not verbose, yet reflecting the characteristics of the underlying processor.

Documents:
A Microcontroller System for Experimentation, description, parts of which are published on this page.
PICL: A Programming Language for the Microcontroller PIC, EBNF
The Language PICL and its Implementation, Code generation.
PICL Scanner, Oberon source
PICL Parser, Code Generator, Oberon source

The Language PICL
The language is concisely defined in a separate report. Here we merely point out its particular characteristics which distinguish it from conventional languages. Like conventional languages, however, it consist of constant, variable, and procedure declarations, followed by statements of various forms. The simplest forms, again like in conventional languages, are the assignment and the procedure call. Assignments consist of a destination variable and an expression. The latter is restricted to be a variable, a constant, or an operator and its operand pair. No concatenation of operations and no parentheses are provided. This is in due consideration of the PIC’s simple facilities and ALU architecture. Examples can be found in the section on code patterns below. Conditional and repetitive statements are given the modern forms suggested by E. W. Dijkstra. They may appear as somewhat cryptic. However, given the small sizes of programs, this seemed to be appropriate.

Conditional statements have the form shown at the left and explained in terms of conventional notation to the right.

[cond -> StatSeq]                     IF cond THEN Statseq END
[cond -> StatSeq0|* StatSeq1 ]        IF cond THEN Statseq0 ELSE StatSeq1 END
[cond0 -> StatSeq0|cond1 -> StatSeq1] IF cond0 THEN Statseq0 ELSIF cond1 THEN StatSeq1END

Repetitive statements have the form:

{cond -> StatSeq}                     WHILE cond DO Statseq END
{cond0 -> StatSeq0|cond1 -> StatSeq1} WHILE cond0 DO Statseq0 ELSIF cond1 DO StatSeq1END

There is also the special case mirroring a restricted form of for statement. Details will be
explained in the section on code patterns below.

{| ident, xpression -> StatSeq}

The PICL Compiler
The compiler consists of two modules, the scanner, and the parser and code generator. The scanner recognizes symbols in the source text. The parser uses the straight-forward method of syntax analysis by recursive descent. It maintains a linear list of declared identifiers for constants, variables, and procedures.

Example

MODULE RepeatStat;
  INT x, y;
BEGIN
  REPEAT x := x + 10; y := y - 1 UNTIL y = 0;
  REPEAT DEC y UNTIL y = 0
END RepeatStat.

0 0000300A MOVLW 10
1 0000078C ADDWF 1 12 x := x + 10
2 00003001 MOVLW 1
3 0000028D SUBWF 1 13
4 0000080D MOVFW 0 13 y := y - 1
5 00001D03 BTFSS 2 3 = 0 ?
6 00002800 GOTO 0
7 00000B8D DECFSZ 1 13 y := y – 1; = 0?
8 00002807 GOTO 7

Example

The following procedures serve for sending and receiving a byte. Transmission occurs over a 3-wire connection, using the conventional hand-shake protocol. Port A.3 is an output. It serves for signaling a request to receive a bit. Port B.6 is an input and serves for transmittithe data. B.7 is usually in the receiving mode and switched to output only when a byte is to be sent. In the idle state, both request and acknowledge signals are high (1).

PROCEDURE Send(INT x);
  INT n;
BEGIN ?B.6;                     wait for ack = 1
  !S.5; !~B.7; !~S.5; n := 8;   switch B.7 to output
  REPEAT 
    IFx.0 -> !B.7 ELSE !~B.7 END; apply data
    !~A.3; issue request
    ?~B.6; wait for ack
    !A.3; ROR x; reset req, shift data
    ?B.6; DEC n wait for ack reset
  UNTIL n = 0;
  !S.5; !B.7;!~S.5 reset B.7 to input
END Send;

PROCEDURE Receive;
  INT n;
BEGIN d := 0; n := 8; result to global vaiable d
  REPEAT
    ?~B.6; ROR d;     wait for req
    IF B.7 THEN !d.7 ELSE !~d.7 END ; sense data
    !~A.3;           issue ack
    ?B.6;            wait for req reset
    !A.3; DEC n      reset ack
  UNTIL n = 0
END Receive;

Another version of the same procedures also uses three lines. But it is asymmetric: There is a master and a slave. The clock is always delivered by the master on B.6 independent of the direction of the data transmission on A3 and B7.

When sending, the data is applied to A.3, when receiving, the data is on B.7. The advantage of this scheme is that no line ever switches its direction, the disadvantage is its dependence on the relative speeds of the two partners. The clock must be sufficiently slow so that the slave may follow. There is no acknowledgement.

Master                              Slave
PROCEDURE Send(INT x);              PROCEDURE Receive;
  INT n;                              INT n;
BEGIN n := 8;                       BEGIN d := 0; n := 8;  result to global vaiable d
  REPEAT                              REPEAT ?~B.6; !>d;   wait for clock low
    IF x.0 THEN !A.3 ELSE !~A.3 END;    IF B.7 THEN !d.7 ELSE ~d.7 END; sense data
    !~B.6; !>x; !B.6; DEC n             ?B.6; DEC n        wait for clock high
  UNTIL n = 0                         UNTIL n = 0
END Send;                           END Receive;

PROCEDURE Receive;                  PROCEDURE Send(INT x);
  INT n;                              INT n;
BEGIN d := 0; n := 8;               BEGIN n := 8;
  REPEAT !~B.6; ROR d;                REPEAT ?~B.6;        wait for clock low
    IF B.7 THEN !d.7 ELSE ~d.7 END;     IF x.0 THEN !A.3 ELSE !~A.3 END; apply data
    !B.6; DEC n                         ROR x ?B.6; DEC n  wait for clock high
  UNTIL n = 0                         UNTIL n = 0
END Receive;                        END Send;

Conclusions
The motivation behind this experiment in language design and implementation had been thequestion: Are high-level languages truly inappropriate for very small computers? The answer is: Not really, if the language is designed in consideration of the stringent limitations. I justify my answer out of the experience made in using the language for some small sample programs. The corresponding assembler code is rather long, and it is not readily understandable. Convincing oneself of its correctness is rather tedious (and itself error-prone). In the new notation, it is not easy either, but definitely easier due to the structure of the text.
In order to let the regularity of this notation stand out as its main characteristic, completeness was sacrificed, that is, a few of the PIC’s facilities were left out. For example, indirect addressing, or adding multiple-byte values (adding with carry). Corresponding constructs can easily be added.
One might complain that this notation is rather cryptic too, almost like assembler code. However, the command (!) and query (?) facilities are compact and useful, not just cryptic. Programs for computers with 64 bytes of data and 2K of program storage are inherently short; their descriptions should therefore not be longwinded. After my initial doubts, the new notation appears as a definite improvement over conventional assembler code.
The compiler was written in the language Oberon. It consists of a scanner and a parser module of 2 and 4 pages of source code respectively (including the routines for loading and verifying the generated code into the PIC’s ROM). The parser uses the time-honored principle of top-down, recursive descent. Parsing and code generation occur in a single pass.

P2 Pascal Compiler

As the name implies, P2 is the second version of the Portable Pascal compiler. It seems to be the first one widely distributed and also the first one to have surviving sources.

One of the distributions of P2 went to California, UCSD. And that version evolved into the UCSD Pascal system.

Mark Rustad took the P2 source, stripped it (no reals e.g.) and changed the p-code to a compact bytecode in Pascal-M.

 (*********************************************************         
  *                                                       *         
  *                                                       *         
  *     STEP-WISE DEVELOPMENT OF A PASCAL COMPILER        *         
  *     ******************************************        *         
  *                                                       *         
  *                                                       *         
  *     STEP 5:   SYNTAX ANALYSIS INCLUDING ERROR         *         
  *               HANDLING; CHECKS BASED ON DECLARA-      *         
  *     10/7/73   TIONS; ADDRESS AND CODE GENERATION      *         
  *               FOR A HYPOTHETICAL STACK COMPUTER       *         
  *                                                       *         
  *                                                       *         
  *     AUTHOR:   URS AMMANN                              *         
  *               FACHGRUPPE COMPUTERWISSENSCHAFTEN       *         
  *               EIDG. TECHNISCHE HOCHSCHULE             *         
  *               CH-8006 ZUERICH                         *         
  *                                                       *         
  *                                                       *         
  *                                                       *         
  *     MODIFICATION OF STEP 5 OF PASCAL COMPILER         *         
  *     *****************************************         *         
  *                                                       *         
  *     THE COMPILER IS NOW WRITTEN IN A SUBSET OF        *         
  *     STANDARD PASCAL  -  AS DEFINED IN THE NEW         *         
  *     MANUAL BY K. JENSEN AND N. WIRTH  - AND IT        *         
  *     PROCESSES EXACTLY THIS SUBSET.                    *         
  *                                                       *         
  *     AUTHOR OF CHANGES:   KESAV NORI                   *         
  *                          COMPUTER GROUP               *         
  *                          T.I.F.R.                     *         
  *                          HOMI BHABHA ROAD             *         
  *                          BOMBAY - 400005              *         
  *                          INDIA                        *         
  *                                                       *         
  *     THESE CHANGES WERE COMPLETED AT ETH, ZURICH       *         
  *     ON 20/5/74.                                       *         
  *                                                       *         
  *                                                       *         
  *********************************************************)        

Original P2 compiler source
Original P2 interpreter source

Scott Moore’s ISO7185 version of P2