Pascal-M 2k1

Pascal-M 2K1

Pascal-M Compiler Linker Disassembler Loader system
Hans Otten, November 2021 Version 0.9
Applicable license: MIT license. Permission given by Mark Rustad.

Note that this version is still beta quality! Your feedback is appreciated!

Downloads for Windows, Ubuntu and Raspberry PI OS:
Pascal-M 2K1 programs
Pascal-M 2K1 sources

How the Pascal-M system works

The Pascal-M system will let you write Pascal programs and execute them on the 6502, e.g. the KIM-1 or the console of the PC.
The Pascal dialect is standard Pascal (no reals for example) as described in the second edition of ‘The Pascal User Manual and Report’. It can (could in older versions!) compile itself.

To get a Pascal program running on the KIM-1 the Pascal-M 2K1 system requires the following steps.

  1. Edit Write the text of the Pascal program
  2. Compile Repeat 1 and 2 until no compilation errors
  3. Load Convert the object M-code of the compiler output to binary code
  4. Link Combine the compiled binary and the 6502 interpreter to an executable KIM-1 program
  5. Run Load the Papertape file on the KIM-1 and run it

How to use

Step 1: Write a Pascal program with any text editor on your PC, create ASCII text files.
Save the Pascal source with extension .pas, and keep the editor open. I use Notepad++ on Windows, any editor will do.
Step 2 – 4: Start the PascalM2K1 program, a GUI program, and fill in the name of the Pascal source.
Press Compile and if the Pascal-M compiler sees no errors goto step 3 and press Load else go back to the editor.
Note the load address is needed to tell where the code should go in memory, the default is fine for now.
See the section on ‘Memory layout’.
Step 4 requires to fill in the name of the binary of the 6502 interpreter (default pascalmint2k1.bin, make sure it is found).
Also fill in the name you want for the 6502 program (Binary, a papertape version is produced also).
Fill in the upper memory RAM limit in your KIM-1. the default is for 32K RAM above $2000, max is $9FFF.
Press Link.
Step 5: Take the papertape file via a terminal emulator to the KIM-1 (in TTY mode) and run it from start address $2000

The example file test.pas contains the source:

program ctest ;


  writeln('hello world') ;

During the steps of PascalM2k1 many files are produced. If for example you start with helloworld.pas and finally link to runhelloworld.bin the following files will be present:

  • helloworld.pas The Pascal source program you have written
  • helloworld.lst Listing of the source program with compilation results
  • helloworld.obp Px code representation of the Mcode
  • helloworld.err Every step produces a file with the status, error or success.
    Also shown in the status field in PascalM2k1
  • helloworld.bin The Mcode loaded into a binary
  • helloworld.prc The Procedure table binary
  • helloworld.dlst The disassembled Mcode, see the Debug section
  • runhelloworld.bin The runnable program binary
  • runhelloworld.pap The MOS papertape version of he runnable program.

You will only have to keep the helloworld.pas and the resulting program runhelloworld.bin and pap, the others can be made again.

Command Line Utilities

The steps described above for PascalM2k1 can also be done with command line utilities. No argument given will prompt for answers.
Help given with -h. Functionality and steps identical to the PascalM2K1 program. Same files produced.

  • cpascalm2k1.exe Pascal-M compiler V2k1
    cpascalm2k1 <sourcefile> [V]
    produces sourcefile.err (status) and sourcefile.obp (object) files
    V shows errors on console
  • cpascalmload.exe Loader for Pascal-M 2K1
    cpascalmload <objectfile>[<loadaddress in hex>]
  • cpascalmlinker.exe Pascal-M linker 2K1
    cpascalmlinker <binfile from loader> <start adress> <interpreter binary><binary startaddres> <linked program file> <upper memory>
  • cpascalmdis.exeDisassembler for Pascal-M 2K1, see the Debug section
    cpascalmdis <objectfile> <loadaddress in hex>

Pascal-M limitations

Pascal-M is close to standard Pascal, but there are limits due to the P2 origin (close to the second ‘Pascal User Manual and Report’,
recommended as description for Pascal-M) and the limitations to make a small compiler for an 8 bit target.
When you read the compiler source ( you will see it is a real language, and can compile itself
(if you strip all enhancements made by me, see SMPASCAL.PAS on the website for the last version that compiles on the KIM-1!)).

This list sums up the important limitations:

  • Identifiers are unique in the first 8 characters
  • No reals
  • Only text files (7 max)
  • 16 bit integers
  • max store size 32768 bytes
  • set max 63 members
  • max 100 procedures/functions, call depth max 12

Memory layout

A Pascal-M program requires RAM from $2000 and up.
The upper limit is variable and can be maximum $DFFF.
The memory layout of a Pascal-M 2K1 system is:

Interpreter start  $2000 - $2F00 : Pascal-M 6502 interpreter
                   $2F00 - $2FFF : procedure buffer 
Load address       $3000 - + size of M-code
          heap growing up
          stack growing down
                         - $9FFF = Upper memory 
                           (can be $DFFF for a 48K system) 

The interpreter starts at $2000, point the monitor there and Go. After the Jump the memory layout is found: first location of M-code (default $3000), end of memory (default $9FFF) and end of M-code/start of heap (dependent on the size of the M-code).
The linker fills these addresses.

Console interpreter and debugger

cpascalmint2k1.exe is a command line Mcode interpreter and debugger.
pascalmint2k1 [<name of Mcode object>] [debug]

Without the optional debug parameter the Mcode program is executed:

D:\myfiles\development\PascalM\PascalM2k1\pascal interpreter&amp;amp;gt;pascalmint2k1.exe test.obp
hello world

With the debug parameter a command line drive debugger is started. Use also the Mcode disassembly output to see what is happening in the Mcode machine.

D:\pascalmint2k1.exe test.obp debug
Program ctest    Loaded

PC    = 7CFC
M-Debug &gt;?

Available debug commands :

  B = Breakpoint commands
  C = Show stack contents
  D = Display store
  E = Show stack contents
  G = Continue without debugger
  H = Show heappointer
  I = Insert in store
  M = Show markpointer
  N = Next instruction executed
  P = Show programcounter
  S = Show stackpointer
  T = Show procedure table
  X = Exit interpreter

PC    = 7CFC
M-Debug &gt;
Break subcommand &gt;?

Available Break commands :

  C = Clear all breakpoints
  D = Show  all breakpoints
  S = Set breakpoint

Compiling and building the programs from source


  • A modern PC and operating system. Windows 10 is where the software has been developed, Raspberry OS /Linux have seen limited tested for now. MacOS may work, untested
  • Development (Compile and run everywhere!) with Freepascal and Lazarus IDE (2.x) see
    Any version above 2.0 will be OK, No OS dependent functions are used a.f.a.i.k.
  • The archives with the KIM-1 Simulator sources (or higher version).
  • Unpack in a folder, avoid blanks in folder and filenames
  • Start the IDE by clicking on the relevant .lpi file.
  • Build with Run – Build

The system is made up of main programs that ‘include’ the actual functionality. This way the command line utilities and the GUI pascalM2k1 share the code.
If a change is made to an .inc file both vcalling programs may need attention and tests.
No extra components are used, standard Lazarus will do.
Note that the ‘mode’ of the units is important, the compiler needs mode $delphi.

The 6502 interpreter is living in the folder 6502interpreter.
No special assembler syntax is used, TASM 32 bit for Windows command line is included.

tasm -65 pascalmint2k1.asm -b pascalmint2k1.bin
TASM 6502 Assembler.      Version 3.2 September, 2001.
 Copyright (C) 2001 Squak Valley Software
tasm: pass 1 complete.
tasm: pass 2 complete.
tasm: Number of errors = 0

will produce the pascalmint2k1.bin file required

Port to other systems

The Pascal-M system is easy to port to other systems. Another 6502 system is quite easy, adaptations on the assembler source will be:

  • Character I/O, replace the KIM TTY in/out (note the ‘echo’ adaptation, so no hardware echo on the KIM-1!) with the relevant character I/O routines of the new target
  • Take look at the memory layout of the new target, adapt lower and upper memory address in use. It is possible to let the interpreter be independent in memory from the M-code.
    The Pascal-m2K1 does not support this, you will have to manage the binary files and memory management in the interpreter yourself

Another platform is a bit more work. Use an assembler or compiler, the interpreter needs to be written for the new target. Take the Pascal interpreter as example, it is well documented.

Introduction and history

How I spent 40 years on getting so far ….
Pascal-M is the name of the Pascal compiler written by Mark Rustad, around 1977.
It was based (and mostly identical) to the portable P2 Pascal compiler, from the ETH Zurich group led by Niklaus Wirth.
The Px Pascal compilers are portable compiler-interpreters, quality compilers and easy to adapt interpreter to new hosts.

The adaptations by Mark Rustad were in the code production, the M-code is byte oriented and more efficient in memory demands.
File I/O was stripped as was floating point. Only chars, integers 16 bit and booleans. Uppercase only. Input/output was for a teletype, so input was either the keyboard or a HSR (High Speed Reader), output a printer or a HSP( High Speed Punch) via a software
Mark Rustad told me he ported the compiler to 6800 and 6809. G.J. van der Grinten did work on the interpreter part for the KIM-1 and wrote a 6502 interpreter.
The Micro Ade editor was adapted to produce Pascal text files.

In 1978 I received from the KIM Club in the Netherlands a version of this Pascal-M system, consisting of a KIM-1 tape with the compiler and interpreter and Micro Ade,
listings of the compiler (in Pascal), preliminary M-code description, the interpreter (in 6502 assembler) and the Micro Ade patches.
It was never made into a product for the KIM club, it was a nightmare to use. From entering text to running a program, all from audio cassette files, it took around an hour.
The old days of papertape and cards were gone already. But the time of cross-compiling or floppy drives connected to the KIM-1 was not there yet.
I got no further than a ‘Hello world’ program once and gave up.

In 1983 I started typing in the source on a PDP-11 with RSX-11M Pascal. And moved on to VAX/VMS with the excellent VMS Pascal. After some years I had the compiler, an interpreter
written in Pascal with debugger and the original 6502 interpreter on tape. This system produced for the second time, in 1986, a running ‘Hello world’ on the KIM-1.
I started expanding the compiler, bringing back P2 functionality like file handling, text files are now supported. Lowercase also. Bugs fixed.

But then I bought a CP/M system and the KIM-1 was put aside. Pascal-M forgotten for several years, Pascal compiler technology not.

I came back in MS-DOS times to the Pascal-M system with the compiler running as a Turbo Pascal (1994, 2003). Then Delphi arrived and the Pascal-M system was brought to live again as Delphi console applications.
In 2020 this was compiled in Freepascal, the compiler was cleaned up (and the original source restored also).

And now in 2021 a Lazarus shell around the steps required to produce a working program was programmed. The 6502 interpreter was finally assembled from source again.
Pressing a couple of buttons is now all it takes to produce a program running on the KIM-1 (and as console on the PC).
The command line utilities are refreshed also. So a ‘Hello World’ takes a a couple of minutes from source editing to running on the KIM-1 (Simulator).
The motivation for the KIM-1 Simulator was mostly for being able to test the Pascal-M system!

Error messages from the compiler

     2 Syntax: identifier expected             
     3 Syntax: Program expected                
     4 Syntax: &quot;)&quot; expected                    
     5 Syntax: &quot;:&quot; exepected                   
     6 Syntax: illegal symbol                  
     7 Syntax: actual parameter list           
     8 Syntax: OF expected                     
     9 Syntax: &quot;(&quot; expected                    
    10 Syntax: type specfication expected      
    11 Syntax: &quot;[&quot; expected                    
    12 Syntax: &quot;&quot; expected                    
    13 Syntax: end expected                    
    14 Syntax: &quot;;&quot; expected                    
    15 Syntax: integer expected                
    16 Syntax: &quot;-&quot; expected                    
    17 Syntax: begin expected                  
    18 Syntax: error in declaration part       
    19 Syntax: error in field list             
    20 Syntax: &quot;,&quot; expected                    
    21 Syntax: &quot;*&quot; expected                    
    50 Syntax: &quot;error in constant              
    51 Syntax: &quot;:=&quot; expected                   
    52 Syntax: then expected                   
    53 Syntax: until expected                  
    54 Syntax: do expected                     
    55 Syntax: to/downto expected              
    56 Syntax: if expected                     
    58 Syntax: ill-formed expression           
    59 Syntax: error in variable               
   101 Identifier declared twice               
   102 Low bound exceeds high-bound            
   103 Identifier is not a type identifier     
   104 Identifier not declared                 
   105 Sign not allowed                        
   106 Number expected                         
   107 Incompatible subrange types             
   110 Tag type must be an ordinal type        
   111 Incompatible with tag type              
   113 Index type must be an ordinal type      
   115 Base type must be scalar or subrange    
   116 Error in type of procedure parameter    
   117 Unsatisfied forward reference           
   118 Forward reference type identifier       
   119 Forward declared : repetition par. list 
   120 Function result: scalar,subrange,pointer
   122 Forward declared: repetition result type
   123 Missing result type in function declar. 
   125 Error in type of standard function par. 
   126 Number of parameters disagrees with decl
   129 Incompatible operands                   
   130 Expression is not of SET type           
   131 Test on equality allowed only           
   132 Inclusion not allowed in set comparisons
   134 Illegal type of operands                
   135 Boolean operands required               
   136 Set element must be scalar or subrange  
   137 Set element types not compatible        
   138 Type must be array                      
   139 Index type is not compatible with decl. 
   140 Type must be record                     
   141 Type must be pointer                    
   142 Illegal parameter substitution          
   143 Illegal type of loop control variable   
   144 Illegal type of expression              
   145 Type conflict                           
   147 Case label and case expression not comp.
   148 Subrange bounds must be scalar          
   149 Index type must not be an integer       
   150 Assignment to standard function illegal 
   152 No such field in this record            
   154 Actual parameter must be a variable     
   155 Control variable declared interm. level 
   156 Value already as a label in CASE        
   157 Too many cases in CASE statement        
   160 Previous declaration was not forward    
   161 Again forward declared                  
   169 SET element not in range 0 .. 63        
   170 String constant must not exceed one line
   171 Integer constant exceeds range(32767) 
   172 Too many nested scopes of identifiers   
   173 Too many nested procedures/functions    
   174 Index expression out of bounds          
   175 Internal compiler error : standard funct
   176 Illegal character found                 
   177 Error in type                           
   178 Illegal reference to variable           
   179 Internal error : wrong size variable    
   180 Maximum number of files exceeded        

50 years of Pascal

By Niklaus Wirth
Communications of the ACM, March 2021, Vol. 64 No. 3, Pages 39-41

In the early 1960s, the languages Fortran (John Backus, IBM) for scientific, and Cobol (Jean Sammet, IBM, and DoD) for commercial applications dominated. Programs were written on paper, then punched on cards, and one waited a day for the results. Programming languages were recognized as essential aids and accelerators of the programming process.

In 1960, an international committee published the language Algol 60.1 It was the first time a language was defined by concisely formulated constructs and by a precise, formal syntax. Two years later, it was recognized that a few corrections and improvements were needed. Mainly, however, the range of applications should be widened, because Algol 60 was intended for scientific calculations (numerical mathematics) only. Under the auspices of IFIP a Working Group (WG 2.1) was established to tackle this project.

The group consisted of about 40 members with almost the same number of opinions and views about what a successor of Algol should look like. There ensued many discussions, and on occasions the debates ended even bitterly. Early in 1964 I became a member, and soon was requested to prepare a concrete proposal. Two factions had developed in the committee. One of them aimed at a second, after Algol 60, milestone, a language with radically new, untested concepts and pervasive flexibility. It later became known as Algol 68. The other faction remained more modest and focused on realistic improvements of known concepts. After all, time was pressing: PL/1 of IBM was about to appear. However, my proposal, although technically realistic, succumbed to the small majority that favored a milestone.

Figure. A poster of Pascal's syntax diagrams strongly identified with Pascal.

It is never sufficient to merely postulate a language on paper. A solid compiler also had to be built, which usually was a highly complex program. In this respect, large industrial firms had an advantage over our Working Group, which had to rely on enthusiasts at universities. I left the Group in 1966 and devoted myself together with a few doctoral students at Stanford University to the construction of a compiler for my proposal. The result was the language Algol W,2 which after 1967 came into use at many locations on large IBM computers. It became quite successful. The milestone Algol 68 did appear and then sank quickly into obscurity under its own weight, although a few of its concepts did survive into subsequent languages.

But in my opinion Algol W was not perfectly satisfactory. It still contained too many compromises, having emerged from a committee. After my return to Switzerland, I designed a language after my own preferences: Pascal. Together with a few assistants, we wrote a user manual and constructed a compiler. In the course of it, we had a dire experience. We intended to describe the compiler in Pascal itself, then translate it manually to Fortran, and finally compile the former with the latter. This resulted in a great failure, because of the lack of data structures (records) in Fortran, which made the translation very cumbersome. After this unfortunate, expensive lesson, a second try succeeded, where in place of Fortran the local language Scallop (M. Engeli) was used.


Like its precursor Algol 60, Pascal2 featured a precise definition and a few lucid, basic elements. Its structure, the syntax, was formally defined in Extended BNF.3 Statements described assignments of values to variables, and conditional and repeated execution. Additionally, there were procedures, and they were recursive. A significant extension were data types and structures: Its elementary data types were integers and real numbers, Boolean values, characters, and enumerations (of constants). The structures were arrays, records, files (sequences), and pointers. Procedures featured two kinds of parameters, value-and variable-parameters. Procedures could be used recursively. Most essential was the pervasive concept of data type: Every constant, variable, or function was of a fixed, static type. Thereby programs included much redundancy that a compiler could use for checking type consistency. This contributed to the detection of errors, and this before the program's execution.

Just as important as addition of features were deletions (with respect to Algol). As C.A.R. Hoare once remarked: A language is characterized not only by what it permits programmers to specify, but even more so by what it does not allow. In this vein, Algol's name parameter was omitted. It was rarely used, and caused considerable complications for a compiler. Also, Algol's own concept was deleted, which allowed local variables to be global, to "survive" the activation of the procedure to which it was declared local. Algol's for statement was drastically simplified, eliminating complex and hard to understand constructs. But the while and repeat statements were added for simple and transparent situations of repetition. Nevertheless, the controversial goto statement remained. I considered it too early for the programming community to swallow its absense. It would have been too detrimental for a general acceptance of Pascal.

Pascal was easy to teach, and it covered a wide spectrum of applications, which was a significant advantage over Algol, Fortran, and Cobol. The Pascal System was efficient, compact, and easy to use. The language was strongly influenced by the new discipline of structured programming, advocated primarily by E.W. Dijkstra to avert the threatening software crisis (1968).

Rapidly computers became faster, and therefore demands on applications grew, as well as those on programmers.

Pascal was published in 1970 and for the first time used in large courses at ETH Zurich on a grand scale. We had even defined a subset Pascal-S and built a smaller compiler, in order to save computing time and memory space on our large CDC computer, and to reduce the turnaround time for students. Back then, computing time and memory space were still scarce.

Pascal's Spread and Distribution

Soon Pascal became noticed at several universities, and interest rose for its use in classes. We received requests for possible help in implementing compilers for other large computers. It was my idea to postulate a hypothetical computer, which would be simple to realize on various other mainframes, and for which we would build a Pascal compiler at ETH. The hypothetical computer would be quickly implementable with relatively little effort using readily available tools (assemblers). Thus emerged the architecture Pascal-P (P for portable), and this technique proved to be extremely successful. The first clients came from Belfast (C.A.R. Hoare). Two assistants brought two heavy cartons of punched cards to Zurich, the compiler they had designed for their ICL computer. At the border, they were scrutinized, for there was the suspicion that the holes might contain secrets subject to custom fees. All this occurred without international project organizations, without bureaucracy and research budgets. It would be impossible today.

An interesting consequence of these developments was the emergence of user groups, mostly of young enthusiasts who wanted to promote and distribute Pascal. Their core resided under Andy Mickel in Minneapolis, where they regularly published a Pascal Newsletter. This movement contributed significantly to the rapid spread of Pascal.

Several years later the first microcomputers appeared on the market. These were small computers with a processor integrated on a single chip and with 8-bit data paths, affordable by private persons. It was recognized that Pascal was suitable for these processors, due to its compact compiler that would fit into the small memory (64K). A group under Ken Bowles at the University of San Diego, and Philippe Kahn at Borland Inc. in Santa Cruz surrounded our compiler with a simple operating system, a text editor, and routines for error discovery and diagnostics. They sold this package for $50 on floppy disks (Turbo Pascal). Thereby Pascal spread immediately, particularly in schools, and it became the entry point for many to programming and computer science. Our Pascal manual became a best-seller.

This spreading did not remain restricted to America and Europe. Russia and China welcomed Pascal with enthusiasm. This I became aware of only later, during my first travels to China (1982) and Russia (1990), when I was presented with a copy of our manual written in (for me) illegible characters and symbols.

Pascal's Successors

But time did not stand still. Rapidly computers became faster, and therefore demands on applications grew, as well as those on programmers. No longer were programs developed by single persons. Now they were being built by teams. Constructs had to be offered by languages that supported teamwork. A single person could design a part of a system, called a module, and do this relatively independently of other modules. Modules would later be linked and loaded automatically. Already Fortran had offered this facility, but now a linker would have to verify the consistency of data types also across module boundaries. This was not a simple matter!

Modules with type consistency checking across boundaries were indeed the primary extension of Pascal's first successor Modula-24 (for modular language, 1979). It evolved from Pascal, but also from Mesa, a language developed at Xerox PARC for system programming, which itself originated from Pascal. Mesa, however, had grown too wildly and needed "taming." Modula-2 also included elements for system programming, which admitted constructs that depended on specific properties of a computer, as they were necessary for interfaces to peripheral devices or networks. This entailed sacrificing the essence of higher languages, namely machine-independent programming. Fortunately, however, such parts could now be localized in specific "low-level" modules, and thereby be properly isolated.

No reference to any computer or mechanism should be necessary to understand it.

Apart from this, Modula contained constructs for programming concurrent processes (or quasiparallel threads). "Parallel programming" was the dominant theme of the 1970s. Overall, Modula-2 grew rather complex and became too complicated for my taste, and for teaching programming. An improvement and simplification appeared desirable.

From such deliberations emerged the language Oberon,5 again after a sabbatical at Xerox PARC. No longer were mainframe computers in use, but powerful workstations with high-resolution displays and interactive usage. For this purpose, the language and interactive operating system Cedar had been developed at PARC. Once again, a drastic simplification and consolidation seemed desirable. So, an operating system, a compiler, and a text editor were programmed at ETH for Oberon. This was achieved by only two programmers—Wirth and Gutknecht—in their spare time over six months. Oberon was published in 1988. The language was influenced by the new discipline of object-oriented programming. However, no new features were introduced except type extension. Thereby for the first time a language was created that was not more complex, but rather simpler, yet even more powerful than its ancestor. A highly desirable goal had finally been reached.

Even today Oberon is successfully in use in many places. A breakthrough like Pascal's, however, did not occur. Complex, commercial systems are too widely used and entrenched. But it can be claimed that many of those languages, like Java (Sun Microsystems) and C# (Microsoft) have been strongly influenced by Oberon or Pascal.

Around 1995 electronic components that are dynamically reprogrammable at the gate level appeared on the market. These field programmable gate arrays (FPGA) can be configured into almost any digital circuit. The difference between hardware and software became increasingly diffuse. I developed the language Lola (logic language) with similar elements and the same structure as Oberon for describing digital circuits. Increasingly, circuits became specified by formal texts, replacing graphical circuit diagrams. This facilitates the common design of hardware and software, which has become increasingly important in practice.

Comments and Conclusion

The principal purpose of a higher-level language is to raise the level of abstraction from that of machine instructions. Examples are data structures vs. word arrays in memory, or conditional and repetitive statements vs. jump instructions. A perfect language should be defined in terms of mathematical logic, of axioms and rules of inference. No reference to any computer or mechanism should be necessary to understand it. This is the basis of portability. Algol's designers saw this goal; but it is most difficult to achieve without sacrificing power of expression. Yet, any new language must be measured on the degree to which it comes close to this goal. The sequence Pascal—Modula—Oberon is witness to my attempts to achieve it. Oberon is close to it. Yet, nothing is perfect.


1. Naur, P. Revised report on the algorithmic language Algol 60. Commun. ACM 6, (Jan. 1963), 1–17.

2. Wirth, N. and Hoare, C.A.R. A contribution to the development of ALGOL. Commun. ACM 9 (June 1966), 413–432.

3. Wirth, N. The programming langage Pascal. Acta Informatica 1, (1971), 35–63;

4. Wirth, N. What can we do about the unnecessary diversity of notation for syntactic definitions? Commun. ACM 20, 11 (Nov. 1977).

5. Wirth, N. Programming in Modula-2. Springer-Verlag 1982.

6. Wirth, N. The Programming Language Oberon. Software–Practice and Experience 18, (Jul. 1988), 671–690;


Edsger Dijkstra

Page on Edsger Dijkstra has seen an update, Books and such on this amazing scientist, who lived in Nuenen long time ago, 10 km from where i live now. Last time I have seen him was in 1980 in Utrecht, where he gave a speech together with Niklaus Wirth and Tony Hoare at the University.

Apple Pascal

These pages on Apple and Pascal are limited to Apple Pascal for the Apple ][ and III, where the UCSD p-System was used.

But there was much more Pascal history at Apple, as is show on the next article.

History of Apple and Pascal (DTC 1992)


Apple’s involvement with the Pascal language was extensive during the 1980 ‘s. From Apple’s introduction to Pascal on the Apple II computer in 1978, it has advanced to the powerful Macintosh 680×0 series Pascals of 1992.
Since 1988 Apple’s reliance on Pascal has been eclipsed by the emergence of C/C++ as Apple’s preferred system and application development language. Tho Pascal will have the support of a small but vocal minority at Apple, C/C++ will be the dominant development language for Apple and outsiders for the next decade.

A Brief History of Apple Computer’s Work with the Pascal Language
Written by David T. Craig 07 October 1992


This document provides a concise history of the work that Apple Computer has done with the Pascal computer language. This history was written so that this rather interesting bit of computer technology would be recorded for those with an interest in technical histories like this.
The author has never worked for Apple Computer, but has been involved with software development for Apple’s many computers since 1978 and has extensively used all of Apple’s Pascal implementations. As such, the facts contained herein are based upon personal memories and Apple technical documents and may be inaccurate. The author hopes that those in the know about Apple’s Pascal work will correct and extend upon this paper so that the history of Apple’s Pascals will be made complete.

See the Apple Pascal II page.
Apple first became involved with the Pascal language for its Apple ][ computer series around 1978. At this time Apple’s software development efforts were based upon the BASIC and 6502 assembly languages.
The key players in bringing Pascal to the Apple ][ were Bill Atkinson and Jef Raskin. Atkinson convinced Apple’s management that the Pascal language would be much better for Apple’s own software development activities than either BASIC or 6502 assembly. Atkinson and Raskin licensed the Pascal language and development system from the University of California at San Diego (UCSD) and began an internal Pascal development group.
Apple’s ][ Pascal system included a Pascal compiler, modal editor, 6502 assembler, a powerful filer, and several utility programs (e.g. program segment mapper). The system was controlled via a command line user interface.

The Apple ][ Pascal compiled to P-Code which was based upon byte codes and a stack architecture. This P-Code was interpreted by an interpreter written in 6502 assembly. 6502 assembly language routines could also be linked with P-Code programs. Identifiers in ][ Pascal were recognized only up to 8 characters, a painful limitation which Apple did not remove until its Macintosh MPW Pascal. Pascal’s memory use was restricted to 64k bytes due to the Apple ][ hardware architecture. ][ Pascal supported program modules called UNITs which could be either regular or shared (a. k. a. intrinsic). Units could be segmented so that they would reside in memory only when needed. ][ Pascal also supported a fairly sophisticated graphics unit called Turtle Graphics created by Atkinson.

Technical documentation for ][ Pascal was reasonably good and consisted of a language reference and an operating system manual.
Several major Apple ][ programs were developed in Apple ][ Pascal, including Apple’s Apple Presents the Apple and
PFS File by PFS Inc.
Apple produced several versions of Apple ][ Pascal: 1.0, 1.1, 1.2, 1.3. As of the middle 1980′ s Apple seems to have abandoned Pascal for the Apple ][. Current Apple ][ Pascal work is done via an Apple-developed Macintosh cross-development system called Macintosh Programmer’s Workshop.

See the Apple Pascal III page.
When Apple developed its Apple /// computer (1980 – 1985) 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.

The 68000-based Lisa computer (1979 – 1985) was unique in that the majority of its system and application software was written in a powerful extended version of Pascal called Lisa Pascal. This software included the operating system (90^000 lines), the Workshop development environment (100,000 lines), 7 application programs (each around 50.000 lines [e.g. LisaWrite, LisaCalc]), and an avalanche of development support programs (e.g. mouse-based editor, telecommunications program, and Pascal language utilities).

Apple’s Lisa Pascal developments began from scratch for Apple when it licensed in 1981 a Motorola 68000 native code Pascal compiler from Silicon Valley Software in California. This compiler was based upon the older P4 compiler from Niklaus Wirth of ETH in Switzerland and consisted of two general passes. Pass 1 produced I-Code, a low-level representation of the high-level Pascal constructs. Pass 2, the code generator, converted the I-Codes to optimized 68000 object code. Apple even considered early in the Lisa’s development using a custom Apple processor which would execute P-Code directly, but the expense of developing such a chip was too much for Apple’s accountants and this project was dropped.

All Lisa development was done with the Lisa Workshop, a command line based development environment similar to Apple’s earlier ][ and /// Pascal systems. The Workshop provided an excellent development environment with its Pascal compiler, mouse-based editor, 68000 assembler, and an extensive collection of utility programs (e.g. Format, XRef, ProcNames). The Workshop supported other languages which included BASIC, COBOL, and C.

Apple produced several versions of Lisa Pascal: 1.0, 2.0, 3.0. Version 3. was the last version and supported the creation of intrinsic units which allowed a single copy of a unit to exist in the system and be used by several programs simultaneously. All versions supported language extensions such as otherwise clause in case statements, longint 32 bit integers, § operator for data addresses, data type coercion, and relaxed ordering of const/type/var sections. A lot of bit-based -functions were also
supported (e. g. BITAND to make bit bashing easier. Inline 68000 assembly code could also be used.

Like the Apple /// Pascal, Lisa Pascal also supported SANE, Apple’s IEEE floating-point implementation. In addition to SANE Apple developed a fairly comprehensive math package called MathLib.
Apple also developed an IEEE floating-point test program which attempted to ring out the bugs in SANE (Jerome Coonen of Apple wrote this test program and its associated test vectors).

Lisa Pascal was a superset of Apple’s older ][ and /// Pascals and, as such, was able to compile ][ and /// Pascal programs which did not make any ][ or /// system calls. Lisa Pascal could also produce a compilation listing complete with the Pascal source code interleaved with the generated 68000 assembly statements.

Apple also developed the Lisa QuickDraw (a. k. a. LisaGraf ) graphics library which formed the heart of what was called Lisa Technology. Though written in 68000 assembly^ Apple provided an extensive Pascal interface to this rather remarkable graphics environment (QuickDraw was later patented by Apple and Bi11 Atkinson. QuickDraw’s creator).

When Apple introduced the Macintosh computer in 1984 all Macintosh programming by Apple and others was done with Lisa Pascal and the Lisa Workshop. For this activity Apple created an extensive set of libraries containing the Macintosh toolbox interfaces. Many important Macintosh programs were written in Lisa Pascal, including MacPaint, MacWrite, MacDraw, and MacTerminal.

The key players behind Lisa Pascal were Ira Rubin and Al Hoffmann.
Apple provided extensive documentation for the Lisa Workshop and Lisa Pascal which included a language manual, an operating system manual, and a Workshop manual. Many internal memos were also released by Apple which described special features of Lisa Pascal.

Lisa Pascal was also used by Apple to develop the Lisa Clascal object-oriented language and the Clascal-based Toolkit class library.

Apple discontinued the Lisa in 1985 in favor of the Macintosh and when Apple’s native Macintosh development environment (MPW) became operational in 1986 Apple dropped support for Lisa Pascal and the Lisa Workshop. Therefore, Lisa Pascal lasted from 1981 to 1986, an eternity in the field of microcomputer languages.

Apple’s first foray into the world of object-oriented programming was with the Lisa Clascal (Classes + Pascal) language. Developed from 1983 to 1985 Clascal was an extension of Lisa Pascal which included several new keywords such as methods and subclass. The main concepts behind Clascal were derived from Simula and Smalltalk. Xerox PARC’s experimental object-oriented language.
In addition to Clascal Apple also developed an extensive set of class libraries which were collectively called the Lisa Toolkit. This class library allowed Lisa developers to create Lisa desktop applications (a. k. a. tools) in a fairly short time frame.

Though really used only internally by Apple for its own research efforts Clascal was made available to external developers but without any support by Apple (David Redhed of Seattle Washington created an independent Clascal/Toolkit support group called the Toolkit User’s Group [TUG], but this unfortunately did not last too long). Apple considered enhancing ClascaL but this Clascal-85 effort was extinguished by Apple’s work with Object Pascal for the Macintosh.
Several significant programs were developed with Clascal and the Toolkit including a calendar program, Apple’s Lisa-to-tlacintosh data conversion program, a desktop publishing program, and a fuzzy logic program.
The key player behind Clascal was Larry Tesler, one of the Lisa computer’s designers, and several former Xerox Smalltalk experts.

When Apple dropped all support for Clascal and the Toolkit it provided the Toolkit source code to the public, but the source code to the Clascal compiler was, alas, not made public.

Apple’s Pascal for the Macintosh computer (1984 – present) was a port of Apple’s earlier Lisa Pascal compiler. When Apple began development of the Macintosh (1982) Apple used Lisa Pascal and the Lisa Workshop for system software development.
With the introduction by Apple of the Macintosh Programmer’s Workshop (MPW) in 1986 Apple had a very professional development environment which from an extendability perspective surpassed the Lisa Workshop. MPW tools could be written that would be executed by selecting their names in a mouse-based window environment and performing the do-it command by pressing the Enter key on the keyboard (shades of Smalltalk). MPW provided a Pascal compiler 680×0 series assembler, an improved 680×0 linker, and a cornucopia of source code utility programs (e.g. PasMat, PasRef). Many languages were also supported, both from Apple and outsiders (e.g. a FORTRAN, COBOL, Modula-2).
MPW Pascal extended Lisa Pascal by supporting the newer Motorola 68000 processors, the 68020, 68030, and 68040. Also supported were the Motorola floating-point and memory management chips. Conditional compilation directives allowed MPW Pascal to support the direct generation of floating-point chip instructions so that floating-point speed could be as fast as possible. Identifiers in Pascal programs were recognized up to 63 characters, a limitation which existed in all prior Apple Pascals beginning with Apple ][ Pascal.
Several versions of MPW Pascal existed: 1.0, 2. 0, 3. 0, 3. 2. Version 3.2, the current 1992 version, was created to support development of System 7 programs and had several extensions to make this compiler support very large programs and support the calling of C functions with variable number of parameters.
MPW Pascal has improved upon the optimization of object code and includes such features as peep hole optimization and better register allocation of local and global constants.
Extensive documentation exists for MPW and MPW Pascal.
MPW Pascal was enhanced to support object-oriented programming and was renamed to Object Pascal. This extended version was used by Apple to develop the Macintosh class library called MacApp.
Apple also contracted with THINK Technologies who created an interactive Pascal learning environment that was called Macintosh Pascal (this interpreter was later turned into a real compiler).
Around 1988 Apple started to use the C and C++ languages for its own Internal software development. The ascendancy of C/C++ at Apple has initiated a marked descendancy of Pascal at Apple and by outside developers.

Object Pascal for the Macintosh was developed by Apple starting in 1985 to support more rapid and more standardized development of Macintosh programs. Available for only MPW, Object Pascal is a descendant of the Lisa Clascal compiler.
The key Apple player behind Object Pascal was Larry Tesler who recruited the help of Niklaus Wirth, the creator of Pascal, to clean up the syntax of Clascal.
Object Pascal was used to develop the extensive MacApp class library. This library was fully documented by Apple via several books and the source code for MacApp was provided to developers.
Object Pascal is being eclipsed by C/C++ at Apple and most outside developers are following Apple’s lead. The Object Pascal MacApp class library has been rewritten in C++.

Apple’s involvement with the Pascal language was extensive during the 1980 ‘s. From Apple’s introduction to Pascal on the Apple ][ computer in 1978, it has advanced to the powerful Macintosh 680×0 series Pascals of 1992.
Since 1988 Apple’s reliance on Pascal has been eclipsed by the emergence of C/C++ as Apple’s preferred system and application development language. Though Pascal will have the support of a small but vocal minority at Apple, C/C++ will be the dominant development language for Apple and outsiders for the next decade.

P5 Pascal

The next text and files are by Scott Moore, and
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:
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.


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:
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 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:
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 }

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

{ !!! remove this next statement for self compile }

{ !!! remove this next statement for self compile }

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:

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

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:
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:// 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 < source.pas
pint 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
October 1974 Stanford Pascal/360 Implementation Guide, contains source of compiler (4665 lines)
Stanford1979.pdf 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


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

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.

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

Model Helicopter Control

Automatic Control of Model Helicopter

In 1995 Wirth joined a project undertaken at the Institute of Automatic Control and Measurement. The goal was the development of a system to allow a model helicopter to fly autonomously a preprogrammed path. Wirth designed an on-board computer system with a Strong-ARM processor at its core. Aside from the hardware, he also programmed various software tools, including an Oberon subset compiler with additional features for real-time programming. The computer board was built by I. Noack.
The resulting computer system, called Olga, made use of experience with programmable gate arrays, and used the novel Xilinx-Algotronix 6200 fine-grained FPGA for the generation and sensing of pulse-width modulated signals to control the servos. Furthermore, the computer was connected to a compass, a global positioning system (GPS), and a data link via several standard RS-232 interfaces. This system resulted in a drastic reduction of weight and power consumption, and an increase in computing performance compared to the one used before, inspite of the fact that floating-point arithmetic was to be programmed based on integer arithmetic.

The helicopter carrying Olga weighs about 15 kg and is powered by a 35ccm engine. Wirth pushed for a second project based on a downsized helicopter model with a weight of less than 5 kg and a conventional 10ccm engine. This was realized with a considerably smaller computer board, but the same Strong-ARM core and software base. The large FPGA was replaced by several small PLDs. This project, Horla, was confined to the more modest goal of using the computer only to stabilize the inherently unstable craft, while position, speed and direction would remain under remote control by the pilot.

Both projects collected in a remarkable way the various techniques and tools on which Wirth had worked during the past decade: Compiler, operating system, programmable devices (FPGA, PLD) and their design tools including the language Lola, and circuit design in general. Both projects were successful, although only after several years of effort – and patience.


Helicopter Flight Control Report 1 The Hardware Core
Helicopter Flight Control Report 2 The Programming Language Oberon SA
Helicopter Flight Control Report 3 The Software Core
Helicopter Flight Control Report 6 The Oberon Compiler for the Strong-ARM Processor
Software for Model Helicopter Flight Control
An Oberon Compiler for the ARM Processor, 2007
/Interrupts and Traps in Oberon-ARM, 2008
SET: A neglected data type, and its compilation for the ARM, 2007
Differences between Revised Oberon and Oberon
The Programming Language Oberon Revision 1.10.2013 / 3.5.2016
Oberon-07 (Revised Oberon) (Oberon at a glance), 2013
Porting the Oberon Compiler from Oberon to Oberon-07, 2007