Personal tools
You are here: Home → Projects → BCPL
Navigation
Log in


Forgot your password?
 
Document Actions

History of BCPL

by Paul McJones — last modified 2024-12-24 13:05

 

Paul McJones, editor - paul@mcjones.org - http://www.mcjones.org/dustydecks/
Software Preservation Group
Computer History Museum

 

Introduction

The goal of this project is to preserve and present primary and secondary source materials (including specifications, source code, manuals, and papers discussing design and implementation) from BCPL, a portable system programming language designed by Martin Richards and ported to many systems by him and by a number of others. Comments, suggestions, and donations of additional materials are welcome.

The implementations are organized by the place where the work was done. Some machine types were targetted in more than one place. The places are ordered in an approximation to the time of BCPL's first arrival. Early work began in the USA, but the bulk of the work took place in the UK after Richards returned home.

BCPL—the languages and systems built with it—connects the first few generations of computer scientists and software engineers, spanning mainframes to minis to micros. It was driven from the UK, but with a tributary into the heart of US research institutions, where it begat C, the most popular systems programming language of all time.

 

Contents

 

MIT Project MAC: IBM 7094, Compatible Timesharing System

This was the first implementation of BCPL. It ran on the IBM 7094 under MIT's Compatible Time-Sharing System.

"The first BCPL compiler was implemented in Doug Ross’s AED-0 since it was the only language available at MIT, other than LISP and SNOBOL, that provided recursion. When reimplemented in BCPL, this first compiler was a mere 1000 lines long." [Richards 2000]

- - -

"This compiler was originally developed to implement the language CPL (Combined Programming Language) on a number of different machines. The central feature of the system is the bootstrapping language BCPL.

BCPL is derived from CPL by removing those features of the full language which make compilation difficult: namely, the type and mode matching and the variety of definition structures and their associated scope conventions. The large number of conditional commands and expression operators do not present a problem and are all included. The BCPL compiler was itself written in BCPL and serves as an example of the recommended style of programming for the other compilers of the system.

Great care has been taken to ensure that the BCPL compiler is as machine independent as possible. To demonstrate this, it is being implemented on the following five machines: the IBM 7094, 360/65, KDF9, Atlas 2, and GE 645." [Richards 1967a]

- - -

"Strachey visited Jack Wozencraft at MIT when he was designing a new course to introduce first year students to computer programming. The outcome was that both Peter Landin and I moved to MIT and helped to design a form of sugared λ-calculus, based on the language ISWIM (If you See What I Mean) described by Landin in “The next 700 programming languages” [Landin 1966]. Landin produced a prototype implementation in LISP using his SECD machine as described in “The mechanical evaluation of expressions” [Landin 1964]. When I arrived at MIT in December 1966, I quickly constructed a BCPL compiler that ran on the timesharing system CTSS and set about using it to implement a variant of Landin’s system called PAL [Evans 1968] that was then used in the new course. This language was a form of sugared λ-calculus but its syntax was somewhat related to CPL. Based on the SECD machine it was dynamically typed with every value carrying its data type at run time. Like LISP, it required a garbage collector. ..." [Richards 2016]

Documentation

  • Martin Richards. The BCPL Reference Manual. Memorandum-M-352, Project MAC, Massachusetts Institute of Technology, 21 July 1967.
    1. Peter G. Neumann's copy via Dennis Ritchie's BCPL history page. The example program in section 8 is missing.
    2. Karl Kleine's copy (originally from http://www.eah-jena.de/~kleine/history/). It includes the example program in section 8, and one reference. PDF

Papers

  • Martin Richards. The BCPL Compiler System. In Project MAC Progress Report IV, July 1966-July 1967, Programming Linguistics section, pages 134-135. Online at apps.dtic.mil
  • P. J. Landin. The mechanical evaluation of expressions. Computer Journal, 6(4):308–320, 1964. Oxford Academic
  • P. J. Landin. The next 700 programming languages. Comm. ACM, 9(3):157–166, 1966. ACM Digital Library
  • A. Evans, Jr. PAL - A language designed for teaching programming linguistics. In Proceedings of 1968 23 ACM Conference, pp 395-403 August 1968. Thompson Book Company, Washington, DC, 1968. ACM Digital Library

Source code

Applications

See: PAL.

 

Cambridge: Various systems

"BCPL: ... In use on Cambridge Titan October 1968 and subsequently on IBM 370 series. (Also used for Tripos operating system on PDP11, CA LSI4 etc.) Retired from local IBM mainframe in 1994, but still in use elsewhere." [David Wheeler, Events in the early history of the Computer Laboratory]

Documentation

  • M. Richards. The BCPL Reference Manual. Technical Memorandum 69/1, Computer Laboratory, University of Cambridge, January 1969. Online at Gesellschaft für Informatik
  • Martin Richards. BCPL: a tool for compiler writing and system programming. In Proceedings of the May 14-16, 1969, Spring Joint Computer Conference (AFIPS '69 (Spring)). Association for Computing Machinery, New York, NY, USA, 557–566. ACM Digital Library1476793.1476880
  • M. Richards. INTCODE - An Interpretive Machine Code for BCPL. Computer Laboratory, University of Cambridge. December 1972 (revised August 1975). PDF

    From bcpl/icint.doc in archive at https://aminet.net/package/dev/lang/BCPL4Amiga.

  • M. Richards. Bootstrapping the BCPL Compiler using INTCODE. Computer Laboratory, University of Cambridge, August 1973. PDF

    From bcpl/booting.doc in archive at https://aminet.net/package/dev/lang/BCPL4Amiga.

  • M. Richards. The BCPL Programming Manual. Computer Laboratory, University of Cambridge.

    "The overall layout and organisation of this manual is based on a manual written by J.H. Morris of the University of California, Berkeley, which itself was based on a well-written memorandum by R.H. Canaday and D.M. Richie of Bell Telephone Laboratories. ... The machine code library was implemented for the 370 by J.K.M. Moody and many of the language extensions for the 370 were implemented with the assistance of H.C.M. Meekings. Many of the extensions were first designed and implemented by J.L. Dawson."

  • M. D. Middleton. A Proposed Definition of the Language BCPL. 1 October 1979. PDF

    "This document sets out a proposal for the definition of a standard BCPL and was prepared by M.D. Middleton in collaboration with
       R. Firth (HPAC Ltd.)
       M. Richards (University Cambridge)
       I. Willers (CERN Geneva)
    who are members of the BCPL Standards Committee elected at the BCPL User Meeting on 7th March 1979 in Cambridge."

    From oldbcpl/obcpl-0.9.8/doc/standard.txt in Archive at https://www.cl.cam.ac.uk/~mr10/Archive.html.

  • Martin Richards and Colin Whitby-Strevens. BCPL - the language and its compiler, 1979. Online at archive.org
  • Martin Richards. The BCPL Cintcode System Users’ Guide. Computer Laboratory, University of Cambridge, 11 December 2003, 132 pages. PDF at cl.cam.ac.uk via archive.org
  • Martin Richards. The BCPL Cintsys and Cintpos User Guide. Computer Laboratory, University of Cambridge, November 2023, 296 pagees. PDF at cl.cam.ac.uk

Papers

  • M. Richards. The Portability of the BCPL Compiler. Software-Practice and Experience, 1 (2), pp. 135-146, 1971. Wiley Online Library
  • Martin Richards. How BCPL Evolved from CPL. The Computer Journal, Volume 56, Issue 5, May 2013, pages 664–670. PDF at cl.cam.ac.uk / Oxford Academic
  • Martin Richards. Christopher Strachey and the Development of CPL. Given at the Strachey 100 Celebration in Oxford, 19 November 2016.
  • Martin Richards. Christopher Strachey and the Cambridge CPL Compiler. Higher-Order and Symbolic Computation, Volume 13, Issue 1-2, April 2000, pages 85–88. SpringerLink

Source code

Applications

TRIPOS

TRIPOS was used at Cambridge and was the basis for AmigaDOS.

  • M. Richards, A. R. Aylward, P. Bond, R. D. Evans, and B. J. Knight. TRIPOS—a Portable Operating System for Mini-Computers. Software: Practice and Experience. Volume 9, Number 7, pages 513–526. Wiley Online Library
  • tripos Github repository. Source code from Cambridge. Public. Online at github.com/borb/tripos

Cintpos portable operating system

 

Multics, Bell Telephone Laboratories: GE 635, GECOS III, and GE 645 and Honeywell 6180

"Having arrived at Bell Labs at the end of 1967 and a wanting a fresh start, I instantly withdrew from theory and also at first resisted involvement in Multics work. Instead I helped Rudd Canaday port the BCPL compiler to GECOS and reimplemented Ken Thompson's QED editor on GE-TSS. ... During the remainder of 1968 and into 1969 I helped port the BCPL compiler to Multics ..." [Dennis Ritchie, BTL Leaves Multics, alt.os.multics, 6 January 1994]

- - -

"Dennis Ritchie and Rudd Canaday of BTL ported CTSS BCPL to Multics. Ken Thompson wrote a version of QED in BCPL, and Doug McIlroy and Bob Morris wrote Multics runoff [McIlroy 1969] in BCPL based on Jerry Saltzer's MAD version of RUNOFF for CTSS.

Robert F. Mabee maintained Multics BCPL after the divorce from Bell Labs. The BCPL runoff command was used by Honeywell documentation to produce Multics manuals for years, until they switched to compose. Bob Daley wrote the Multics qedx command in PL/I to replace the BCPL qed command."
[Tom Van Vleck, Multics Software Features: BCPL, multicians.org]

- - -

"Dennis Ritchie and I implemented a BCPL compiler. I wrote the compiler and Dennis wrote the supporting routines for input and output and the mathematical library (routines for doing mathematics). I wrote the user’s manual. (I wish I still had a copy.) ..." [Rudd Canaday, How C Came to Be, ruddcanaday.com] [But see Morris 1969.]

- - -

"Thompson: ... After UNIX was up, or, simultaneous with UNIX coming out, BCPL was just emerging and that was a clear winner with both of us. Both of us were really taken by the language and did a lot of work with it. [But see Morris 1969].

Mahoney: How did you come up with it, it’s an English language wasn’t it?

Thompson: Ah yes, but the guy who did, Martin Richards, actually developed it at MIT. It was available in a very informal way, on CTSS and we pulled it off of CTSS and got a version running on GECOS here and did system programming there. It was too big a language to run on the UNIX machines that were 4K machines. That’s when B was developed. ..." [Ken Thompson interviewed by Michael Mahoney, 1989]

Documentation

  • M. Richards. The BCPL Reference Manual. Multics Repository Document M0099, 15 May 1968. Cited in [Canaday, BZ.6.00].
  • R. H. Canaday. A BCPL Compiler for Multics - Overview. Multics System Programmers' Manual, Section BZ.6.00, 18 June 1968, 3+cover page. PDF at multicians.org
  • R. H. Canaday. Language description. Multics System Programmers' Manual, Section BZ.6.01, [1968].
  • R. H. Canaday. BCPL-Multics library routines. Multics System Programmers' Manual, Section BZ.6.02, 18 June 1968, 4 pages. PDF at multicians.org
  • R, H. Canaday. Additions and amendments to the BCPL run-time library, BZ.6.02. Multics System Programmers' Manual, Section BZ.6.02a, 20 September 1968, 3 pages. PDF at multicians.org
  • R. H. Canaday. Accessing the Multics BCPL compiler through MRGEDT. Multics System Programmers' Manual, Section BZ.6.03, 12 July 1968, 1 page. PDF at multicians.org
  • R. H. Canaday. BCPL-Multics compiler - code generation. Multics System Programmers' Manual, Section BZ.6.04, 12 July 1968, 17 pages. PDF at multicians.org
  • R. H. Canaday. Executing BCPL code under Multics. Multics System Programmers' Manual, Section BZ.6.05, [1968].
  • D. M. Ritchie. The BCPL command. Multics System Programmers' Manual, Section BX.7.06, 25 September 1968, 4 pages. PDF at multicians.org
  • Martin Richards; revised by Arthur Evans, Jr. and Robert F. Mabee. The BCPL reference manual. MAC-TR-141, 26 November 1974. PDF

    "BCPL (Basic CPL) is a general purpose programming language which is particularly suitable for large nonnumerical problems in which machine independence is important. It was originally designed as a tool for compiler writing and has, so far, been used in at least three compilers. BCPL is currently implemented and running on the Honeywell 635 under GECOS III, on the Honeywell 645 and 6180 under Multics, on the IBM 360 under OS and CP/CMS, on the TX-2 at Lincoln Laboratory, on the CDC 6400, on the Univac 1108, and on the DEC PDP-9. There are also BCPL compilers on the KDF 9 at Oxford and on Atlas 2 at Cambridge. Other implementations are under construction."

  • See also https://multicians.org/unix.html.

Source code

  • See entries of the form bcpl_*.bcpl for the BCPL system, and entries of the form runoff_*.bcpl for the runoff application written in BCPL, in this directory: https://multicians.org/source-index.html

Applications

 

Lincoln Laboratory: TX-2

"BCPL is a simple recursive programming language, developed by M. Richards,* designed for compiler writing and system programming. To date, the uses of the language have included SNOBOL and MAD compilers, a QKD editor, and a PAL interpreter.

...

The BCPL compiler is written in BCPL which makes the transfer of the compiler from one machine to another relatively easy. It has been implemented on CTSS and Multics at Project MAC, the System 360, and Atlas, among other machines.

BCPL on TX-2 will bridge the gap between LEAP and Mark 5. It is a high-level language yet its structure is simple enough that assembly language-like programming is possible, i. e., the BCPL programmer can manipulate pointers, push bits, etc., very easily and with complete confidence regarding the compiler's functions. Thus, fairly well optimized code can be created.

A second advantage of BCPL for TX-2 is that any programming done in BCPL will be more readily exportable to other computers. For example, had VITAL been implemented in BCPL, its use might have been more general. Conversely, with a BCPL compiler, we will be able to take advantage of other groups' work.

Third, the implementation of BCPL is such that interfacing the compiler with a TX-2 assembler will not be difficult.

In order to transfer the compiler from Project MAC'S 7094 for implementation on TX-2, we had to solve three distinct problems:

  1. We rewrote the preprocessor (which accepts input text) and the code generator to produce a simple subset of Mark 5.
  2. We rewrote the BCPL library routines for TX-2.
  3. Since CTSS uses 7-track tape and TX-2 uses 9-track tape, we wrote a PL/l program for OS-360 to convert the CTSS tapes to TX-2 tapes.

All three steps in the transfer have been coded and partly checked out. The remaining areas of work are:

  1. To alter the code generator to produce binary, or, alternatively, to write a really simple assembler for the code produced by the compiler.
  2. To write a relocatable loader for the compiler programs, as well as to alter the compiler to produce relocatable code. This second problem has certain implications which have yet to be resolved. If a loader is produced exclusively for BCPL, all other potential compilers and assemblers will not be able to use it easily. This defeats one of the purposes of BCPL on TX-2, which is to improve communications between people and languages on TX-2. However, a full-blown loader is a large undertaking and it is unclear at this point what properties the loader should have.
  3. To add debugging aids to the BCPL system. This area has not yet been touched.

To date, two projects intend to use BCPL. The first project is to develop a new multiprocessing framework for TX-2; several parts of this system have already been coded in BCPL. The second project is to rewrite the code generator to produce code for the new testing machine and to write a real-time control and calculating system for the testing machine in BCPL.

* M. Richards, 'The BCPL Reference Manual,' Project MAC Memo-M-352-1, M.I.T. (February 1968)."
[Lincoln Laboratory 1968]

- - -

"An integrated relocatable code system has finally been created for the TX-2 comprising the BCPL compiler, a new relocatable assembler, and a linking loader. The output of the BCPL compiler is a text file of assembly code similar in form to any created by hand. The assembly code then passes to the new TAP (TX-2. Assembly Program) assembler which produces a relative binary file containing binary code, relocation bits, and symbolic linkage information. The link- ing loader combines relative binary files to produce executable TX-2 code. This new system has been used to create both the BCPL compiler (written itself in BCPL) and the EGS described below. In addition, the TAP assembler with modifications serves as an assembler on TX-2 for the 16-bit testing terminal computer."
[Lincoln Laboratory 1969]

See also Xerox PARC BCPL for DG Nova and Xerox Alto.

  • M. Richards and E. ("Henry") I. Ancona. The BCPL Reference Manual. Lincoln Laboratory, Massachusetts Institute of Technology, 1967, revised 6 May 1969. PDF at bitavers.org

    "BCPL is currently implemented and running on CTSS at Project MAC, the GE 635 under GE COS and on a KDF 9 at Oxford. Other implementations are under construction for MULTICS, the ICT 1900 series, Atlas, the System 360, and the TX-2."

  • Graphics: Semiannual Technical Summary Report to the Advanced Research Projects Agency, 1 June - 30 November 1968. Lincoln Laboratory, Massachusetts Institute of Technology, 19 December 1968. Online at archive.org / PDF at dtic.mil
  • Graphics: Semiannual Technical Summary Report to the Advanced Research Projects Agency, 1 December - 31 May 1969. Lincoln Laboratory, Massachusetts Institute of Technology, 24 June 1969. PDF at bitsavers.org

 

U. C. Berkeley: CDC 6400

James H. Morris joined the brand-new Berkeley Computer Science Department as an assistant professor after completing his dissertation at MIT. One of his first projects was porting BCPL to Berkeley's CDC 6400 computers.

Documentation

  • James H. Morris, Jr. BCPL Users Guide. Computer Center, University of California, Berkeley.
    1. Initial version, for CDC SCOPE operating system. December 1969. PDF at caltss.computerhistory.org

      Acknowledgement

      In the interest of making documentation of BCPL available quickly, large portions of this manual were taken from a very well-written memorandum by R.H. Canady and D. M. Ritchie of Bell Telephone Laboratories. Naturally any errors or omissions in this manual are my responsibility.

      The initial design and implementation of BCPL were done by Martin Richards of Cambridge University, England.

      The implementation for the 6400 was done with the assistance of Richard Aronoff."

    2. Revised version, for CAL Timesharing System [McJones and Redell 2023] as well as SCOPE. May 1971. PDF at caltss.computerhistory.org

Papers

  • James H. Morris. Thoughts of a Reformed Computer Scientist: On the Nature of Real and Artificial Intelligence. Self-published, 2021. Amazon

    One passage describes bringing BCPL to Berkeley and how it was received.

  • James H. Morris. BCPL. Nerd Zone. Online at jimmorris.org

    Explains how Morris bootstrapped the BCPL compiler on a CDC 6400 via OCODE (which Morris refers to as UNCOL).

  • Paul McJones and David Redell. History of the CAL Timesharing System. IEEE Annals of the History of Computing, Volume 45, Issue 3, July-September 2023, pages 80-91. IEEE (open access)

Source code

Applications

  • [Bill Bridge.] BASIC. Interpreter for the BASIC programming language. 21 January 1972. Online at caltss.computerhistory.org
  • [Howard E. Sturgis.] CLNPRF. Utility to manage accounting structures. Undated, circa 1971. Online at caltss.computerhistory.org
  • [Howard E. Sturgis.] Multiprocess test framework. Undated, circa summer 1971. Coordination framework for running a command in multiple processes and retrieving the reports. Written in BCPL, but probably not finished. Undated, circa 1971. PDF at caltss.computerhistory.org

 

University of Essex: ICL 1900 and TOPS-10 PDP-10

ICL 1900

"My initial bootstrap code-generator was in Fortran, and targeted the 1900 assembly language (PLAN). It would have been nicer to write it directly in BCPL, but that would have meant going back and forth between Colchester (Essex) and Cambridge: a tedious trip, even by car. The system would transparently invoke the assembler to generate “semi-compiled” — the relocateable link-loader format.

Between September 1969 and January 1970 I rewrote it in BCPL: targeting semi-compiled directly. The code generator algorithm they shared was simple. But as you can imagine, it was not simply a question of translating individual OCODE instructions into (sequences of) 1900 instructions: that would have more or less doubled the size of the code, and (about) halved its speed. From then on BCPL was considered a first-class citizen, and if this hadn’t been achieved there might have been stiffer competition[*] for selection as the practical workhorse for the “systems programming” part of the nascent Essex undergraduate curriculum. The Essex curriculum had, until then, included a course called “Data Structures and Cobol”, taught by a determined “primitive". It was clear to the (few) "space-cadets" that this had to be replaced, and we agitated for BCPL.

At our first meeting (in Cambridge, Spring 1969) Martin had given me a listing of an early version of his code-generator for the Cambridge IBM 360; by dint of a static simulation of the OCODE stack, and delaying the emission of instructions for as long as practical, it generated admirably concise and fast code. But I was a bit intimidated by the idea of reconstructing something like it in Fortran, and for a very different machine architecture. Eventually, on my way home one early morning[**], I thought of a simpler stratagy — it got me about 85% of what the vastly more complicated Richards algorithm might have achieved if I’d pursued it.

An important techno/logistic problem for both ports was that the 1909 memory was so small (32K*24-bit words), and the operating system and translated compiler were together so large, that there was little space for the abstract syntax tree of the programs it would translate, and it could never have translated the whole BCPL compiler. Thanks to Martin’s clean two-phase organisation of the compiler we were able to overlay the code of the first (parsing) phase against the code of the second (ocode generation) phase. The use of semi-compiled meant that we could use standard system routines to load each phase in turn: the tree and the stem of the compiler code stayed resident. The BCPL port of the code generator was considerably more compact: but we kept the overlay structure, and none of the people writing a BCPL program then ever had to worry about the size of the tree needed to compile any of its files.

[*] ICL Algol, and Atlas Autocode also ran on the University’s (sole) machine.

[**] R.A. (Tony) Brooker, who was head of the Department, was a strong supporter of my project: he arranged for me to take over the (sole!) University machine between the end of the evening shift and the start of the early morning shift. The origin of this arrangement was that the code-generator was on two massive card decks. The compiler’s OCODE — the exact monolith passed to me by Martin — was on a magnetic tape. To get decent turnaround when correcting mistakes I would have to orbit card-punch, card-reader, line-printer, operators’ console for much of the night. Not quite interactive, but I had time (and sometimes took time) to think while diagnosing my own mistakes — sometimes by poring over a very large core dump. The test for correctness was to use the translated OCODE compiler to translate the source of the compiler. Termination was (of course) necessary: but reaching an OCODE fixpoint was the goal. Of course every time I changed parts of the generator I had to repeat the test trajectory. The 1909 was pretty slow.

[***] The first handful of undergraduates had arrived in (I think) the autumn of 1969, as did the third cohort of [8] Master’s students.I had myself arrived in the second cohort [of 6] having finished a mathematics degree, during the second summer of which I’d written a PDP-8 simulator in APL while a summer teaching assistant at the University of Alberta. The first IBM 360/67 APL had appeared at UA at the start of that summer, complete with an interactive APL system.

[Bernard Sufrin, Personal communication, 17 April 2024]

PDP-10: First version, by Eyres supervised by Sufrin

"Richards' original compiler produced object code (OCODE) for an idealised stack machine and was itself available in OCODE. Hence to transport the compiler to another machine, it was only necessary to write a code generator to translate OCODE to the required machine code. By this method Richards took BCPL to Cambridge (England), from which version the original Essex ICL 1900 BCPL was developed via a code generator written by Bernard Sufrin in 1969. It was transported onto the PDP-10 in 1970 via a code generator written in BCPL by Brian O'Mahoney and David Eyres, with help from Bernard Sufrin." [Gardner 1978]

- - -

"Brian O’Mahoney ... had pretty close to nothing to do with the first direct PDP10 code generator: I supervised David Eyres — an MSc student as I recall." [Bernard Sufrin, Private communication, 14 April 2024]

- - -

"I designed the calling sequences to make it possible for us to implement a cactus-stack for coroutines/concurrent processes. There was a library that was used in the teaching of operating systems for a while. If you weren’t going to use the concurrency library the call stack was quite conventional: you didn’t have to pay the penalty for obtaining the frame for the callee from a free-space manager and linking it to the caller. Much later, when Dec20s had paged virtual memory rather than just two segments — code and data, it became easier to manage all this.

An important decision was to virtually abandon the 'global vector' of BCPL in favour of a proper system of symbolic links that made it possible to link-load as little or as much of a library as a program needed. This was a great relief for everyone: though I never found out whether Martin liked it or was annoyed." [Bernard Sufrin, Private communication, 14 April 2024]

"The great thing about BCPL was that the size of every stack frame was known up front (no dynamically-sized vectors in the language — but, being unwilling to commit to compile-time sizing for all structures, we had a simple library routine that would call a routine with a dynamically-sized vector taken from the stack as its parameter).

Here’s an account of the calling sequence: the 10’s indirect addressing calculation was enormously useful in keeping it short.

It was not necessary for a callee’s frame to be linked by pointer to its predecessor because the (maximum) size of each frame is manifest at translate time. In what follows stacks grow upwards. Call the frame pointer P; there is no explicit top-of stack, the caller has left a couple of words at the base of the intended callee’s frame, and loaded the values of the parameters above them. The running routine’s return link is in one of the words.

Before the call:

 
callee parameters
[two words of incipient callee frame base]
… caller locals … (N words)
[two words of caller frame base]  <—— P

Code at the call site:

JSR  L, <entry address>
SUBI P, N

Code at the entry address:

ADDI  P, @0(L)	[P:=P+N]
MOVEM L, 0(P)   [store the return link and flags]

After entry:

callee parameters
[two words of callee frame base]  <—— P
… caller locals … (N words)
[two words of caller frame base]

Code at the return site:

JRST  @0(P)     [the address at 0(P) is that of the SUBI]

The coroutine and 'safe' variants added a call to the 'frame allocator' after the entry code. At translate time the maximum extent of the entered frame (including space for any parameters it will pass on to routines that it calls) is known — call this M. The number of parameters it’s defined with is also known — call this D (it’s derivable from the SAVE OCODE directive that always appears after the ENTRY directive that names the routine).

JSP L, <frame allocator>
[D || M] 		[[Two half-words]]

The 'safe frame allocator' simply checks that P+M is within the bounds of the current memory segment; and invokes some sort of recovery if not: either to stop the program or to increase the size of the segment.

The 'coroutine frame allocator' can recover by fetching a block of size (at least) M from the memory allocator; copying the base of the current frame (D words) into it; and moving P to point to it.

Obviously coding conventions required care over the passing of the addresses of local variables across this kind of boundary.

I can’t quite remember the details, but I know we used to be able to give an intelligible stack backtrace (naming the routines owning the frames in the call stack) when a program went wrong. Perhaps we did it by placing the name of each routine inline just before its entry point, and using part of the second frame-base word to point to it. Straightforward and cheap (but not necessary if you’re confident and want to shave a couple of instructions)." [Bernard Sufrin, Personal communication, 17 April 2024]

PDP-10: Second version, by Gardner guided by Bornat

"By 1973 BCPL had developed into the major software language in use by the Department of Computer Science for both research (e.g. in AI) and teaching (e.g. Compiler writing), and so with the intention of improving the compiler, both in performance and by adding new language features, a new compiler was developed by Pete Gardner for release in 1974. The performance, as measured by the kilo-core second load on the system, has been improved by a factor 3 or 4; the new features included are documented in this manual. The main contributory factor was the removal of the intermediate OCODE stage which required in effect two compilations, one from BCPL to OCODE and one from OCODE to machine code." [Gardner 1978]

- - -

"But in fairness to Pete Gardner, what he did do under the close guidance of Richard Bornat while I was in the USA, was to build a complete compiler for (yet another dialect of) BCPL, using the same calling sequences: and still supporting the coroutines/concurrency library. Richard had earlier built an Algol compiler in Manchester, and knew what he was doing. In their compiler one could interpolate native code in routines: thus making it simpler to write libraries.

Richard just told me that their first motivation for doing this was that the string-packing conventions on 10s (5 7-bit characters per word) would have made packing and unpacking strings tedious in BCPL. " [Personal communication, Bernard Sufrin, 14 April 2024]

- - -

The Essex compiler introduced many extensions to BCPL, including the SELECTOR (spelled SLCT by some other compilers) and :: (spelled OF by some other compilers) operators.

The Essex compiler included the "op:=" assigning operators.

Essex BCPL also introduced an EXTERNAL declaration as an alternative to the standard BCPL GLOBAL vector.

Compiled versions of the Essex BCPL compiler are available on GitHub. The source may have been recovered, but I know of no available copy." [John Hughes, BCPL Bestiary, Essex BCPL for the PDP10]

See also the ICL 4130 port at the University of Kent by Bob Eager.

Documentation

  • P. Gardner. The BCPL Reference Manual. Computing Service, Department of Computer Science, University of Essex, 2nd edition, revised January 1978. PDF at rabbit.eng.miami.edu
  • R. D. Eager. Improving the Portability of the BCPL Compiler. Master's thesis, University of Essex, January 1975. PDF at bobeager.uk

Source code

Applications

POPS (Portable OPerating System)

"This is POPS, a Portable OPerating System. It was written by John Forecast, a Ph.D. student at the University of Essex, UK, in the early 1970s. It was designed to be hosted by another systems, and is more of an exemplar.

John is happy for this code to be released. The longer story was that I requested the thesis nearly 50 years ago, and decided to type in the source. I did check it well.

I did nothing with it, but John Forecast mentioned that he longer had it on some forum. I was able to return it to him!" [Bob Eager, Personal communication, 17 April 2024]

  • John Forecast. BCPL source code to POPS, 1975. ZIP archive
  • John Forecast. A Machine Independent Operating System. Thesis (Ph.D.), Computing Centre, University of Essex, 1975.
A hardcopy of the thesis is held at the Essex library.

Oxford, Programming Research Group: KDF-9 and CTL Modular One

"BCPL: started Jan 1967 by Martin Richards at MIT and in use MIT and Oxford Programming Research Group in May 1967. ..." [David Wheeler, Events in the early history of the Computer Laboratory]

- - -

"Throughout my time at MIT and later, on return to Cambridge, I maintained close ties with Strachey. He was enthusiastic about the design and portability of BCPL to the extent that he implemented it on the KDF-9 computer at Oxford, and later he installed it on the CTL Modular One at the Programming Research Group at 45 Banbury Road. He also used BCPL to implement an operating system called OS6 for that machine which, as the story goes, ran successfully, for the first time, on a Sunday evening very few days after the machine arrived. The BCPL source code is published in OS6Pub [Strachey and Stoy 1972a] with the “Commentary on the text of OS6Pub” [Strachey and Stoy 1972a]. BCPL running under OS6 was the only language available to students at the Programming Research Group for some years.

OS6 included many innovative ideas, one being his implementation of I/O streams. He represented a stream by a small vector, called a stream control block (SCB), that held all the values needed for its implementation, such as a pointer to its buffer and integers giving its size and current position. But importantly, the SCB also held three functions. One (Next) to read the next value from the stream, one (Out) to write a value to the stream and one (Close) to close the stream. Next was defined as follows:

LET Next(s) = (s!NEXT)(s)

where s points to an SCB and NEXT is a manifest constant identifying the position of the read function. This mechanism could be used to represent streams of characters, words or indeed any kind of value. You could even create a stream that generated prime numbers. It is clear that this structure is similar to an instance of a class in a language such as Java. Some streams required larger SCBs but could still use the same definition of Next. This is clearly a precursor to the concept of inheritance found in modern object oriented languages." [Richards 2016]

- - -

"I first met BCPL running on Strachey's Modular One at Oxford. Although the language was essentially the same as Richard's, the syntax was far superior, mainly because Strachey had insisted on having teletypes and a line printer that actually supported a reasonable character set.

Specifically, the hardware character set included upper and lower case letters, three of the four arrows (right for conditional, down for indexing), multiply, logical "and" and "or", a matching pair of quotes(!), and four sets of brackets {, [, ( and "Section brackets" that were used to delimit code blocks; the open section bracket was a double S section symbol (§) and the close section bracket was the same thing with a vertical bar running through it.

The full Modular One Internal character code also included a few characters that were not on the printers, but which could be produced (more or less) by overprinting: divide (÷), $, #, and lambda.

All this was done with 7 bits. The 8th bit was used to indicate underlining. Just as in many of the contemporary books, we used underlining to indicate keywords. The underscore key on the Olivetti teletypes was a "dead" key, like an accent, and you typed the keyword let, say, by striking _l_e_t.

The Oxford version of BCPL also included "Manifest Functions", which were used to simulate abstract data types, and ... objects. For example, Next[aStream] was a manifest function, i.e., one that could be compiled inline; its body was aStream <downarrow> STREAM_NEXT [aStream], i.e., apply the function that is stored in the STREAM_NEXT (a small integer) element of the aStream vector to aStream itself. What this did, of course, depended on the kind of stream that you had ... sound familiar?

I still have a few listings from those days ... " [Andrew Black, squeek-dev list, June 2000]

- - -

"[Strachey] was a great teacher and conveyed his enthusiasm for all aspects of Computer Science from the fine details of the cunning encoding tricks used in his compact byte-stream interpreter for the Modular-1 BCPL system to the more abstract thoughts relating to denotational semantics." [Richards 2000]

- - -

"The Strachey compiler was still in use in Oxford at the Programming Research Group when I arrived there in September 1978." [Bernard Sufrin, Personal communication, 15 April 2024]

Source code

At the request of Bernard Sufrin, Geraint Jones recovered a version of the Oxford BCPL compiler from a snapshot of the OS13(BLUE) live filestore.

"This appears to be the stream compiler in OS13 (not OS13(BLUE)). The OS13(BLUE) one has a different Pass 3, I haven't looked at it yet.

The zipfile contains a text showing the Index, and for each of the Text files in the Index an entry file/foo with the file in OSPub characters, and in pdf/foo.pdf a rough rendering of it.

Quite a few of the Text files in the filestore turn out not to contain Text, but most of those are owned by NOG. There are also some files that contain Text with unconventional stuff, for eaxmples underlining done by putting a CR in the line and overstriking un-underlined characters with underlined spaces. I woner whether this was what some pre-roff roff-like thing did.

Ah, and Milne never used pound signs. He writes pound by overstriking '(' and '-'. I suspect there was an output device that didn't have pounds on it." [Geraint Jones, Personal communication, 19 April 2024]

  • Christopher Strachey et al. Source code for OS13 stream compiler.
    • Geraint Jones, curator. ZIP archive, as described above. bcpl.zip
    • Combined listing, concatenating the individual PDFs in alphabetical order. PDF

Applications

  • Joseph Stoy and Christopher Strachey. An Operating System for a Small Computer. PRG-08, Programming Research Group, Oxford University Computer Laboratory. May, 1972. PDF at cs.ox.ac.uk

    Published as:

    • OS6—An Experimental Operating System for a Small Computer. Part 1: General Principles and Structure. The Computer Journal, Volume 15, Issue 2, May 1972, Pages 117–124. Oxford University Press
    • OS6—An Experimental Operating System for a Small Computer. Part 2: Input/Output and Filing System. The Computer Journal, Volume 15, Issue 3, August 1972, Pages 195–203. Oxford University Press
  • Christopher Strachey and Joseph Stoy. The text of OS6Pub. PRG-09, Programming Research Group, Oxford University Computer Laboratory, July 1972. PDF at cs.ox.ac.uk
  • Christopher Strachey and Joseph Stoy. The text of OS6Pub (Commentary). PRG-09 (c), Programming Research Group, Oxford University Computer Laboratory, July 1972. PDF at cs.ox.ac.uk

 

University of Kent: ICL 4130, DEC PDP-11, ICL 2900, Zilog Z80, DEC VAX (BSD 4.2, VMS)

These versions were by Bob Eager.

ICL (formerly NCR/Elliot) 4130

"I ported the early Essex compiler to the NCR/Elliott 4130 in 1975. ... I spent 1973-74 at Essex, and I did a code generator for an abstract machine for my dissertation. I was working on that while Pete Gardner was developing the PDP-10 compiler, and I remember finding a major bug in his register allocation! ...

I returned to Kent in October 1974, and ported the compiler to the 4130. It was a tight fit, and had to be overlaid. No documentation was ever written as I only used it personally." [Bob Eager, personal communication, 15 April 2024]

  • Bob Eager. Source code for port of early Essex BCPL to ICL 4130 under EMAS. 1975. ZIP archive

DEC PDP-11

"For PDP-11 under DOS-11, and cross compile to standalone too. Used for our earlier terminal concentrators. The terminal concentrators supported selection of host. So you could select one of the two 4130s (one gave bigger online workspace), or the ICL 2900 running VME.

This came from Cambridge but again I hacked it a lot. Our terminal concentrators were short on space, and loaded many initialisation overlays, kept in a DOS core image library (CIL)." [Bob Eager, Personal communication, 15 April 2024]

  • Bob Eager. Source code for port of Cambridge PDP-11 BCPL to PDP-11 DOS. 1976. ZIP archive

ICL 2900

An initial implementation ran on ICL's VME operating system, but only portions survive. The second implementation was for EMAS (Edinburgh Multi Access System), which was used at the University. Bob notes: "There is no real documentation; the code is easy to understand, even the user interface. At that time all our documentation was typed out by secretaries. " [Bob Eager, personal communication, 15 April 2024]

  • Bob Eager. Source code for EMAS 2900 BCPL. CircA 1979. ZIP archive

Zilog Z80

"Cross compiler for Zilog Z80. Originally done by Ian Wilson at Cambridge, but extensively modified by me. We used this for terminal concentrators, and space was at a premium." [Bob Eager, Personal communication, 15 April 2024]

  • Ian Wilson and Bob Eager. Source code for Z80 BCPL. Early 1980s.

DEC VAX UNIX BSD4.2

  • Bob Eager. Source code for DEC VAX BCPL under BSD4.2 UNIX. Original version was circa 1980 (BSD4.0). ZIP archive

DEC VAX VMS

  • Bob Eager. Source code for DEC VAX BCPL under VMS. Original version was 1983; further development 1985-1986. ZIP archive

Applications, etc.

"ECCE, SPELL, ML/I and CHEF are all very portable and were used on multiple systems." [Bob Eager, Personal communication, 16 April 2024]

A68K (assembler for Motorola 68000)

A68K is an assembler for the Motorola 68000. It ran under Tripos at Cambridge and Unix and VMS at Kent.

"This was written by Ian Wilson at Cambridge, probably early to mid 1980s.

I adapted it a bit for students, as we were teaching MC68000 assembler at the time. The dates show 1988, although we probably started using it a bit earlier." [Bob Eager, Personal communication, 17 April 2024]

  • Ian Wilson and Bob Eager. BCPL source code for A68K assembler. ZIP archive

CHEF (Christchurch Edit Facility)

"This is a portable editor written by John Peck of University of British Columbia, and Mike Maclean of University of Christchurch, New Zealand. I met John at an event in Cambridge and he came to Canterbury for a few days.

The source is the latest one, incorporating fixes sent to me by the authors, and conditional code added by me for other implementations.

It is 'ed' like, but with more facilities. The paper in doc/chef.pdf describes most of them." [Bob Eager, Personal communication, 17 April 2024]

  • J.E.L. Peck and M.A. Maclean. BCPL source code for CHEF editor, versions 4.7 and 4.8. ZIP archive
  • M.A. Maclean and J.E.L. Peck. CHEF: a Versatile Portable Text Editor. Software: Practice and Experience Volume 11, Number 5, May 1981, pages 467-477. (Copy in ZIP archive) Wiley Online
  • J.E.L. Peck, M.A. Maclean: The Construction of a Portable Editor. Software: Practice and Experience Volume 11, Number 5, May 1981, pages 479-489. (Copy in ZIP archive) Wiley Online
  • J.E.L.Peck and M.A.Maclean. CHEF - A programmer's word processor. (Copy in ZIP archive)

ECCE (Edinburg Compatible Context Editor)

"This is the Edinburgh Compatible Context Editor. Originally developed on Edinburgh IMP, then ported to BCPL and C." [Bob Eager, Personal Communication, 16 April 2024]

KRC (Kent Recursive Calculator)

"KRC is a simple lazy functional language designed and implemented by David Turner around 1979-81. It was a "miniaturised" version of SASL (St Andrews Static Language), used for teaching functional programming at the University of Kent and Oxford University in the early 1980's." [David Turner, krc-lang.org]

See https://www.cs.kent.ac.uk/people/staff/dat/krc/ for full details, including a version written in C for modern machines.

  • David Turner. BCPL source code for KRC, circa 1984. TGZ archive at kent.ac.uk

    "For historical interest here are sources of EMAS KRC. Not now usable, due to antique BCPL syntax and interface to an extinct operating system, it ran on the University of Kent's ICL 2900 computer under EMAS, during the period 1980-6. There was a second implementation of KRC made around 1985 by Simon Croft, in C for Unix using combinators, which remained in use for longer, but we have been unable to locate Simon, or the code." [David Turner, Software Archeology]

  • D. A. Turner. Recursion Equations as a Programming Language. In Functional Programming and its Applications, pp1-28, Cambridge University Press, 1982 (eds. Darlington, Henderson and Turner). PDF at cs.kent.ac.uk
  • D. A. Turner. The Semantic Elegance of Applicative Languages. Proceedings MIT/ACM conference on Functional Languages and Architectures, Portsmouth, New Hampshire, October 1981, pages 85-92. PDF at cs.kent.ac.uk

ML/I (macrogenerator)

"ML/I is a macrogenerator, written at Cambridge by Peter Brown in 1966-67 as part of his Ph.D. He later came to Kent (1968-69).

ML/I was written in an abstract language called L; the intention was that the L source could be mapped to any suitable language, usually using ML/I itself. The first map (to the PDP-7) was done by hand.

It transpired that an L-map was hard, so Peter mapped it to a low level (assembler level) language called LOWL. Many implementations were done using this, and I did a number.

In about 1980, I had the urge to map L to BCPL by hand! It produced a working implementation on EMAS (which I was using at the time). There were difficulties with the weird way in which ML/I did recursion, but I overcame that.

Peter became tired of ML/I after about 20 years, and I took over all enquiries and maintenance. In the end I put it all on a website. [Bob Eager, Personal communication, 16 April 2024]"

SPELL (spelling correction program)

  • Peter Robinson and Dave Singer. BCPL source code for spelling correction program. Original version and Bob Eager's heavily modified version. ZIP archive
  • Peter Robinson and Dave Singer. Another Spelling Correction Program. Communications of the ACM, Volume 24, Number 5, May 1981, pages 296-297. ACM Digital Library

 

Queen Mary's College?: ICL 1900

"Martin Richards's compiler was ported from the Titan to the ICL 1900 by Bernard Sufrin at the University of Essex in 1969. However the version of ICL 1900 BCPL we have appears not to be that version, notably the code generated seems not to be that described by Bernard Sufrin. The ICL 1900 compiler contains a few BCPL extensions, notably the true/false branches of a TEST statement can be written as IFSO and IFNOT and in in either order. It has been suggested that this is a dialect of BCPL introduced at Oxford. No byte access operator %, no subfield operators SLCT and OF." [John Hughes, BCPL Bestiary, ICL 1900 Systems]

- - -

"As described in Computer Resurrection issue 75 (Autumn 2016) a tape from Galdor Computing has been found that contains a copy of Martin Richards' BCPL compiler for the ICT/ICL 1900 series computers.

The compiler is available in both source and binary format. It was initally assumed that the the code generator was written by Bernard Sufrin, but it appears it was written elsewhere, possibly at QMC (Queen Mary College, now Queen Mary University of London). It is not currently known who wrote the code generator, or if they used Bernard Sufrin's code generator for the bootstrap).

On investigation of the files obtained from Galdor Computing it appeared that the full source of the compiler (BCPL to OCODE) was present and it proved possible to recompile the compiler, producing identical OCODE and a working second generation compiler.

Unfortunately the source of some functions found in the BCPL library is missing. This is not too serious as PLAN versions of the routines can be generated from the existing semicompiled library using my disassembler program.

More seriously, parts of the code generator, CGMX, (which converts OCODE to semicompiled) were missing, a simple recompilation of the code generator produced a binary that was significantly shorter than the original and which halted on a missing function when run. It has proved possible to recreate the missing parts of CGMX, as documented here.

The language compiled is the pre-PDP10 dialect of BCPL, without the later additions of the byte indexing operator "%" and the field access operators "SLCT" and "OF", which makes it rather a good fit for the word-oriented 1900 architecture. In contrast with some other non-ICL written compilers (Algol 68R, Fortran 77, Pascal) it compiles to standard semicompiled format, making it relatively easy to include non-BCPL code in BCPL programs. Like Salford's Fortran 77 it uses the ASCII character set internally, making programming with such advanced features as lower case rather easier than standard 1900 six bit 3 shift code." [John Hughes, ICL 1900 BCPL compiler]

Source code

Documentation

 

BBN (Bolt Beranek and Newman Inc.): TENEX PDP-10

"BCPL was originally designed and implemented by Martin Richards at MIT Project MAC. Many people have since contributed to the development of the language, compiler, utilities, and debugging system, as represented in the TENEX BCPL system. The language and compiler were extended to include structures, symbol tables, and various new language constructs by the group at MIT Lincoln Laboratory on the TX-2 computer, led by Art Evans. Carl Ellison (University of Utah Computer Science Department) built a TENEX BCPL bootstrap and brought an early version of the Lincoln compiler to Utah-TENEX through the ARPANET. He also built the first TENEX BCPL I/O library. Paul Rovner brought the Utah system to BBN-TENEX through the ARPANET, then used it to bootstrap an improved version of Lincoln's compiler. Victor Miller (BBN) helped to upgrade Ellison's code generators. The present TENEX BCPL system includes several packages of routines and functions, and several utility programs that were brought from Lincoln and modified for use on TENEX by Paul Rovner. Other utilities were contributed by Jerry Wolf, Ray Tomlinson, and Richard Schwartz at BBN. The TENEX BCPL debugger was designed and implemented by Jim Miller and Paul Rovner, with help by John Sybalsky. And Gail Hedtler of the TENEX group at BBN spent many hours puzzling through pencil scratched versions of this manual as she converted it to RUNOFF format and keyed it in." [Ancona et al. 1974]

- - -

"I [was] recruited to BBN by Paul Rovner, whose department — I think Bob Thomas was the head — hired me to work on finishing a (Tenex-BCPL) compiler for the PDP-11s that were going to take over as the IMP processors. I had just about finished the compiler when I had to return to the UK towards the end of 1974; I’m not sure the BBN people much cared, and I don’t remember handing it over properly." [Bernard Sufrin, Personal communication, 14 April 2024]

- - -

"Ray Tomlinson, as you can read in that PDP-11 appendix in the BCPL manual, thoroughly reworked the insides of the compiler to produce the PDP-11 compiler. In the summer of '75, Jim [Miller] and I worked to turn that PDP-11 cross-compiler back into a PDP-10 compiler. I remember having fun choosing the best machine instruction sequences for various things, including bitfields in structures. See for instance [https://github.com/PDP-10/]tenex-bcpl/bcpl/bcpl.changes.1, where we talk about the new "XBCPL" compiler:

``The code the new compiler generates is considerably better than old BCPL, especially for structure references and conditional expressions. Hopefully you will notice the difference in the core you use and in your run time.''

Also as mentioned there, the new compiler produced assembly language which had to be run through the assembler. Later, I think in 1976, I changed that to generate machine language directly." [Dan Halbert, Personal communication, 31 May 2024]

- - -

  • "I started working part time as an MIT freshman at BBN in 1972, with a project supervised by Paul Rovner in support of speech research being conducted on the PDP-10 (TENEX) and Imlac computers.
  • The work I was doing was an Undergraduate Research Opportunities Program (UROP) project supervised by J C R Licklider from the MIT side. My goal was to make a high-level language symbolic debugger based on the model of IDDT (Bill Plummer) which ran in a separate virtual machine from the process being debugged. The implementation was in and for BCPL.
  • There was similar work being conducted by Art Evans at Lincoln Labs on the TX-2. John Detreville (then a graduate student at MIT, later DEC SRC) was developing a debugger there, and Art owned the BCPL implementation and tool chain.
  • Eventually I took over the TENEX BCPL tool chain to support the work by the Hermes email team (where I eventually worked full time after I graduated in 1976).
  • I still have the BDDT source code on 9-track mag tape if anyone is interested. I used to have full listings of both BDDT and the whole tool chain, but that is long gone.
  • Ray Tomlinson and I did some work together on the PDP-11 version. Far more his project than mine. I do believe that we worked out design details for a BDDT cross-debugger, although I'm not sure it was ever built.
  • The BBN design philosophy around both the PDP-10 and -11 compilers was very similar. They were explicitly not optimizing compilers, but were intended to allow professional programmers to express optimized code directly (by doing manual common subexpression elevation, for example).
  • Ray's main work other than direct porting of the compiler code was to invest heavily in register allocation optimisations since these were difficult to express with just the REGISTER keyword.
  • My very vague recollection of representation issues was that Ray felt that pointers should be considered byte addresses, since this meant (consistent with the BBN philosophy) that programmers could directly access the hardware without having to worry about the compiler inserting or removing shifts and masking. I also recall some language extensions were under consideration to allow access to 8-bit, read-, and write-only registers. I think they were added as 'manifest lv' values (constant addresses)."

[Jim Miller, personal communication, 15 June 2024]

Documentation

  • [Martin Richards with] Henry Ancona, Paul Rovner, Jerry Burchfiel, and Jerry Wolf. BCPL Reference Manual. September 1974. PDF at bitsavers.org

    Appendix F is PDP-11 BCPL (Ray Tomlinson and Jerry Burchfiel).

  • Harry C. Forsdick, Arthur Evans, Jr and Robert H. Thomas. Improvements to the BCPL Programming System. Report No. 3983, Bolt Beranek and Newman, Inc., December 1978. Online at dtic.mil

    "This report describes BBN efforts to improve the BCPL Programming System by adding features to the language, changing the compiler and writing new routines for the run-time library. New features added to the BCPL Language include a facility for defining routines that are expanded directly in place of calls to them, and an assembler for including PDP-10 assembly language statements in a BCPL module. Changes made to the compiler include a peephole optimizer ... and shorter normal routine calling squences.

Source code

 

IBM Research: IBM System/370, CP/CMS

"... [Martin Richards] was on a sabbatical at IBM Research in the early '70s, and I succeeded him in being the 'keeper of the keys' for his port of BCPL to VM/CMS. He had left everything in perfect order for me to take over. I continued to use this BCPL until I left IBM in 1993 (20 years, pretty good record for durability).

I built a theorem prover (for Effigy [symbolic execution] headed by Jim King) in a personally modified BCPL. ..." [Jerry Archibald, squeak-dev list, June 2000]

Applications

 

Xerox Palo Alto Research Center: Data General Nova and Xerox Alto

"BCPL had a long history with ARPA and PARC. Jim Curry, at Lincoln Labs in the 60's, then at Utah, then at PARC, was one of the earliest bootstrappers of BCPL. The workhorse at PARC for the first 2 years was the Data General NOVA, which however lacked an efficient semihighlevel language to program with (the Algol on it was too slow and too hermetically sealed). So Jim bootstrapped one of the versions of BCPL to the NOVA.

The bootstrapping was interesting. BCPL had a bytecoded representation of itself (descended like all such from the legendary Burrough's B5000). One first wrote an interpreter for these byte codes, in this case in NOVA assembler. This got BCPL running, but slowly. One then started using BCPL to make a back end native code generator for the new machine. Once this started running the bootstrap was done and BCPL was pretty efficient. One of the architectures that was emulated by the Alto when it started running in 1973 was the NOVA (but with a 16 bit address space instead of the NOVA's 15-bit space). And BCPL was used for some of the Alto programming.

Quite a bit of the non-Smalltalk and non-Lisp software was done in BCPL, including one of the several operating systems, and BRAVO, which was the embryo of what is now called MS Word." [Alan Kay, squeak-dev list, June 2000]

- - -

"One of the more interesting east to west coast connections is [that] the TX-2 BCPL compiler was the basis for the BCPL on the Xerox Alto." [Al Kossow, TUHS Mailing list, 18 Oct 2011]"

Documentation

Nova

  • James E. Curry. BPCL Manual. Xerox Palo Alto Research Center, 15 February 1973. PDF at bitsavers.org
  • Ben Laws. BCPL I/O and Runtime Routines. Xerox Palo Alto Research Center, 31 May 1973. PDF at bitsavers.org
  • Gene McDaniel. BCPL Machine Language Interface. Xerox Palo Alto Research Center, 18 June 1973. PDF at bitsavers.org
  • James E. Curry. Compiling BCPL Programs. Xerox Palo Alto Research Center, 16 August 1973. PDF at bitsavers.org
  • James E. Curry. Loading BCPL programs. Xerox Palo Alto Research Center, 20 August 1973. PDF at bitsavers.org

Alto

  • Butler Lampson. Alto/Bcpl stcrage allocation and function calls. Xerox Palo Alto Research Center, 19 June 1973. PDF at bitsavers.org
  • Gene McDaniel. Bringing NOVA BCPL Programs to ALTO. Xerox Palo Alto Research Center, 3 July 1973. PDF at bitsavers.org
  • Bill Duvall. BCPL Symbol Table Format (Gleaned from Allen Brown's Debugger Notes). Xerox Palo Alto Research Center, 7 March 1974. PDF at bitsavers.org
  • Jim Curry and Peter Deutsch. BCPL .BR file format. Xerox Palo Alto Research Center, 29 April 1974. PDF at bitsavers.org
  • [Dan Swinehart]. Recent BCPL System Modifications. Xerox Palo Alto Research Center, 19 December 1974. PDF at bitsavers.org
  • [Dan Swinehart]. Recent BCPL System Modifications. Xerox Palo Alto Research Center, 14 January 1975. PDF at bitsavers.org
  • [James H. Morris, Jr.?]. Swat, a BCPL-oriented debugger. Xerox Palo Alto Research Center, 2 February 1977. PDF at bitsavers.org
  • [Bob Sproull?]. BCPL Runtime Package. Xerox Palo Alto Research Center, 17 October 1977. PDF at bitsavers.org
  • James E. Curry. BCPL Reference Manual. Xerox Palo Alto Research Center, 9 September 1975. PDF at bitsavers.org
  • [James E. Curry?]. [BCPL Compiler Internals]. Xerox Palo Alto Research Center, undated (circa 1975?). PDF at bitsavers.org
  • James E. Curry and PARC staff. BCPL Reference Manual. Xerox Palo Alto Research Center, 14 September 1979. PDF at bitsavers.org

Source code

  • James E. Curry and PARC staff. BCPL compiler source code. BCPL and Alto microcode. From [Indigo] BCPLSOURCES.DM!1, 5 December 1980. xeroxalto.computerhistory.org
  • James E. Curry and PARC staff. BCPL runtime source code. Alto assembly language and microcode. From [Indigo]BCPLRUNTIMESOURCE.DM!, 30 August 1979. xeroxalto.computerhistory.org

Applications

  • Xerox Alto operating system, library routines, utility programs, and applications (including Bravo and Draw).
  • Xerox Smalltalk.

    "You might be interested to know that the very first occurrence of a Smalltalk-to-C (-like language) was a translator from Smalltalk to BCPL that Ted Kaehler, Glenn Krasner and I did way back when we were at Xerox.

    We had designed this (pretty cool) virtual memory named LOOM (see the Green Book) that used 16-bit internal pointers, but 32-bit external pointers. This meant that if we could get it to work, we could just bolt it onto the existing (then fastest in the world) Dorado Smalltalk. Ted wrote the whole thing in Smalltalk, and arranged to run two images back-to-back, one with the LOOM VM code in it, the other with then normal Smalltalk image. When there was a fault in the normal image, it entered a primitive that emerged on the other side to handle the fault.

    When this all finally worked (it did!), we wanted to speed it up, and make it smaller by rewriting it in BCPL (BCPL was supported on all the Xerox hardware at the time). Ted had written a lot of it in the style of SLANG -- ie, Smalltalk as machine code -- so instead of starting over, we just changed the prettyPrinter to emit valid BCPL code for about 80% of what was there. We did that in a day, and then Ted and Glenn finished the translation by hand." [Dan Ingalls, squeak-dev list, June 2000]

 

Aarhus University (RIKKE)

The RIKKE series were implementations of the MATHILDA dynamically microprogrammable processor design. [Shriver 1973]

"One of my early projects in Aarhus was to design a virtual machine in hardware for BCPL. I needed to run BCPL or rather I wanted to run BCPL programs, so I looked at OCODE,3 which is basically assembly code for BCPL, and thought, “Why I don’t just implement that in hardware?” So I wrote a little piece of microcode that implemented it instruction for instruction. I made a binary representation of OCODE with compressed data structures so that you could have a compact program and then I could run BCPL." [Stroustrup, Oral history, 2015]

Documentation

  • E. Kressel and J. Staunstrup. The RIKKE-1 Reference Manual. DAIMI MD-7, Department of Computer Science, University of Aarhus, Denmark, April 1974.
  • Ejvind Lynning. The RIKKE BCPL System: A Programmer's Manual. DAIMI MD-22, Computer Science Department, Aarhus University, February 1976.
  • Jens Kristian Kjærgård, Ib Holm Sørensen (1980). BCPL on RIKKE (in Danish). DAIMI Report Series, MD-36. Matematisk Institut. Datalogisk Afdeling, Aarhus University, Denmark.
  • Jens Kristian Kjærgård and Flemming Wibroe. The RIKKE BCPL System. DAIMI MD-38, Computer Science Department, Aarhus University, September 1980. PDF at bitsavers.org
  • Henrik Andersen, Kurt Jensen, and Børge S. Kirk. INTCODE documentation. Undated. PDF at bitsavers.org
  • Bjarne Stroustrup. Oral hiatory interview by Paul McJones. Computer History Museum, February 5, 2015. Online at computerhistory.org

Papers

  • Bruce D. Shriver. A Description of the MATHILDA System. DAIMI PB-13, Department of Computer Science, University of Aarhus, Denmark, April 1973. PDF at bitsavers.org
  • Ole Sørensen. The Emulated OCODE Machine for the Support of BCPL. DAIMI PB-45, April 1975. Online at the Royal Danish Library

    "In the spring of 1973 it was decided to implement the language BCPL [ Richards 1969a, Richards 1971, Richards 1969b ] on the experimental microprogrammable computer RIKKE-1 [ Shriver 1973, Kressel and Staunstrup 1974] being constructed in this department. The language was chosen to be the systems programming language for RIKKE-1, one argument was the possibility of transferring the Oxford Operating system OS 8 [ Stoy and Strachey 1972a ] to RIKKE-1.

    As there existed no intermediate object language OCODE [ Richards 1971] for the translation of BCPL, one way of accomplishing this goal was to write an emulator for some internal representation of OCODE (or a slightly modified version of OCODE) and an OCODE assembler that would assemble symbolic OCODE into this internal representation.

    This paper describes the design process for an internal representation of OCODE, the resulting machine, the emulator, and the assembler, and finally there is a discussion of our experiences of running the OCODE machine during the past 8 months. Some future analysis and possible modifications are mentioned.

    The OCODE machine was designed and the OCODE emulator was written during the summer and autumn 1973 by Bjarne Stroustrup and the author. The OCODE machine has been running on RIKKE-1 with a mini-system written in BCPL since July 1974. Some modifications have been made during this period."

  • Eric Kressel and Ib Holm Sørensen. The first BCPL System on RIKKE-1. DAIMI MD-17, Department of Computer Science, University of Aarhus, Denmark, July 1975.
  • Ib Holm Sørensen and Eric Kressel. A proposal for a multi-programming BCPL system on RIKKE-1 (in Danish). Matematisk Institut. Datalogisk Afdeling, Aarhus University, Denmark, 1975.

Source code

  • BCPL compiler (PHASE 1) listing. Catalog entry at CHM

    "Description
    > BCPL compiler (PHASE 1) listing {BCPL source --> M.R. OCODE object} with:

    1. BCPL Source
    2. M.R. OCODE translation
    3. AARHUS OCODE translation
    4. LOADMAP of AARHUS OCODE load module"

 

University of York: RSX PDP-11

Source code

Documentation

  • Jeremy Holden. BCPL/RSX11D User Manual, Department of Computer Science, University of York, June 1976. Runoff source at pdp-11.classiccmp.org

    "BCPL is a programming language originally developed and implemented by Martin Richards at MIT project MAC for systems and non-numerical programming. It originated as a subset of CPL, the never-implemented language designed for TITAN by Barron et. al. [Barron et al. 1963], and is notable for its varied and efficient control constructs and for the fact that it is a typeless language. The BCPL compiler is written in BCPL and produces object code (OCODE) for an idealised stack machine. The compiler is therefore portable and can be transported by the provision of an OCODE translator for the target machine. It was by this method that BCPL was first implemented in England, at Cambridge, and it is from this implementation, via ICL 4130 implementations at Warwick and York, that the present system is derived. The BCPL language is defined in the BCPL Reference Manual [Richards 1970] and an extended version of the language in use at Essex is defined in [Gardner 1974]. This document describes an implementation of BCPL to run on a PDP-11/40 or 45 under the RSX-11D V004A operating system [Digital 1974]."

  • D. W Barron et. al. The Main Features of CPL. Computer Journal, Volume 6, Issue 2, August 1963, pages 134–143. Online at Oxford Academic
  • Introduction to RSX-11D. Digital Equipment Corporation, DEC-11-OXINA-A-D, 1974.

 

Finning: Data General Nova

Finning is the world's largest Caterpillar dealer.

Documentation

  • Doug Dyment. Finning BCPL System Reference Manual. Finning Computer Services Ltd. 27 July 1977. PDF

Applications

  • Doug Dyment. FINNET—a homogeneous multiprocessor network. In Proceedings of the 3rd ACM SIGSMALL symposium and the first SIGPC symposium on Small systems (SIGSMALL '80). Association for Computing Machinery, New York, NY, USA, pages 60–66. ACM Digital Library

 

Others (including applications)

Implementations

Applications

  • David Turner. SASL functional programming language. 1973.

    "The implementation of SASL in LISP wasn’t really robust enough to use for teaching. So over the Easter vacation in 1973 I wrote a compiler from SASL to SECD machine code and an interpreter for the latter, all in BCPL. The code of the first version was just over 300 lines — SASL was not a large language. It ran under the RAX timesharing system on the department’s IBM 360/44, so the students were able to run SASL programs interactively on monitors, which they liked." [Turner 2013]

  • David Turner. Some History of Functional Programming Languages. In Lecture Notes in Computer Science. Edited by H.-W. Loidl and R. Peña. Springer, 2013, pp. 1-20. PDF at kent.ac.uk / Springer

 

Acknowledgments

Thanks to Martin Richards, Andrew Black, Lars Brinkhoff, Dave Cannon, Bob Eager, Dan Halbert, John Hughes, Geraint Jones, Jim Miller, Jim Morris, Bruce Ray, Paul Ruizendaal, Jerry Saltzer, Bernard Sufrin, Tom van Vleck, and the proprietors of all the web sites linked to above.
« December 2024 »
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
 
Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: