- 1 Untitled
- 2 Two Things
- 3 Another Thing
- 4 BCPL compiler mechanism
- 5 O-Code
- 6 The BBC Micro implementation
- 7 Intro etc
- 8 Hungarian Notation
- 9 Amiga
- 10 Early computers had a 16-bit word??
- 11 Dennis Ritchie's preface
- 12 What's in a name?
- 13 What's in a name?
- 14 Canonical Syntax Page in Memorandum M-352 is missing
I would like to look over a 32K BCPL compiler. If you could record links to some of your findings here, It would be nice.
My 32KB compiler example is Acornsoft's BCPL for the Acorn Model B Microcomputer. It is proprietary, copyright, and only available in binary form. Alas. The 1980 Book (see head article) has the source for the compiler front end (lexer and syntax analyser).
I'd be a bit surprised if a full BCPL would run in 16K, though maybe someone did a stripped down version that would. The early C compilers ran in about 12K. Dennis Ritchie has said that some BCPL features were left out of B and C because there just wasn't room. (Of course C has since grown.) That said, the Jargon file is usually very accurate and well researched, despite its dubious and often strange style. I would trust it much more than other more sober sources, simply because it was written by people who were there, and cared, and in many cases have otherwise unavailable evidence stored in their attic.
BCPL is a very simple language (you should read the book!). 16KB sounds _about_ right for a well written hand-crafted compiler. It might be multipass in that little memory. Certainly it should be easier to write a BCPL compiler than even an early C compiler. I'd just like to know which one. --drj
1. I'd been taught BCPL stands for 'Boston Cambridge Programming Language'. 2. I seriously take offence you refer to code blocks as 'curly bracket programming'. BWK calls those brackets braces as I remember and it's just a REALLY DUMB MONIKER. A C preprocessor could effectively define away curly braces and the importance is not in the character but in the function - namely new automatic variables can be declared and they will only have scope within those curly braces. —Preceding unsigned comment added by 126.96.36.199 (talk) 23:59, 31 August 2008 (UTC)
I'd heard that BCPL stood for "Bootstrap Cambridge Programming Language", and was an attempt at a low-level language that didn't require a (complicated) linker, but had higher level constructs that would make it usable for developing higher level languages, to wit the CPL (programming language). Having used it I find that more plausible than other definitions (K. Cameron) — Preceding unsigned comment added by 188.8.131.52 (talk) 08:21, 26 December 2012 (UTC)
BCPL compiler mechanism
The BCPL compiler was always 2-pass - the first pass (Lex) turned the source into O-Code which was a virtual stack-based machine. The front end was of course portable. The back end read OCode and produced machine code (or sometimes assembler).
There was a clever porting mechanism using an interpretive code called INTCODE. Part of the compiler kit included a back end that converted O-code to INTCODE and you got a copy of several programs including the compiler already in INTCODE. You wrote an interpreter for INTCODE (it was very simple) in whatever language you liked say C or even BASIC. This was tested with the simpler programs and then with the INTCODE version of the compiler.
At this point you had a slow but functional compiler that enabled you to start writing the back end in BCPL, taking O-Code and converting it to machine code. You started at O-Code and not INTCODE because it allowed you to make better use of the target instruction set.
BCPL didn't use any sort of external linking: all variables and functions that were to be available in another module had to be declared as "Global" and allocated a number from 100 upwards. Numbers less than 100 were for library calls. When a BCPL program runs, the init sequence allocates a Global Vector (simple array) and if any functions are declared as global then code is generated in each module which will write the address of the function into the vector. This simple dynamic linking worked very well, and even allowed simple overlay mechanisms by using a library command called "LoadSeg" which loaded code and initialised the global vectors for the routines there. Once (say) the initialisation modules had run, you called UnLoadSeg to get rid of the code you don't need and call LoadSeg again on what you want next.
This also allowed Tripos/AmigaDOS to have CLI commands that were very small dynamically linked code LoadSeg'ed by the CLI.
- Dr Tim King
So what was O-Code? It did exist, I have a document describing it. Was it an earlier intermediate code preceding INTCODE/CINTCODE?
This is what I have from the CORAL66 compiler documentation, which compiled to the same intermediate code and used BCPL's back end on the PDP-11:
"This document describes Ocode, the intermediate code of various compilers and codegenerators used at RMCS and elsewhere.
Ocode is a simple intermediate code that forms the interface between front and back ends of a compiler. It is at a fairly low level, being largely linear, and with type mapping and address translation already performed.
The version described here is a development of the Ocode designed by Martin Richards for the BCPL compiler. Currently, compilers to Ocode exist for Algol60, BCPL, Coral66, Fortran, and RTL/2. There are codegenerators for many machines, including Intel 8080 and 8086, MC68000, DEC PDP-11 and VAX-11, CA LSI-2 and NM4, DG Nova, Interdata 7/16 and 8/32.
Ocode is intended as an intermediate code between a compiler and a codegenerator. It is not designed for interpretive execution, and to some extent is not suited to it. Further discussion of possible compiler and codegenerator strategies may be found in the companion documents 'Programming the Ocode Machine' and 'Codegenerating Ocode'."
Added later... Here's what I found about OCODE and CINTCODE: http://wuarchive.wustl.edu/pub/aminet/dev/lang/BCPL4Amiga.readme
By the way, 16K and 32K compilers were common for Acorn's BBC micro - both full ISO Pascal and a less than full C fitted into that much space (I QA tested the C compiler while I was learning C - the QA testing threw up a lot of problems that would only bite a beginner but never someone who actually knew the language!); the Pascal compiler (the only one for which I have personal knowlege of the innards) did it by tweaking the intermediate code to be as dense as possible, often at the expense of speed. One EPROM (16K) held the compiled compiler in intermediate code format; the other EPROM contained the interpreter (and a screen text editor throw in for good measure). I expect BCPL was implemented similarly. I wouldn't swear on it in court but I think it was an Arthur Norman production? (preceding the excellent NorCroft C compiler for the ARM, co-written with Alan Mycroft)
- Graham Toal (PS: Hi Tim, I remember you from Cambridge)
By way of information an INTCODE BCPL2 with 16bit word sizes occupies about 20K of INTCODE plus data. CINTCODE is supposed to be more compact so a 16K ROM holding the CINTCODE and the rest in RAM seems completely in order. The interpreter code is much more compact than native assembler in most cases. 184.108.40.206 (talk) 16:43, 18 March 2016 (UTC)
The BBC Micro implementation
The BCPL ROM and attendent tools were written by John Richards (brother to Martin, and who founded Richards Computer Products) and associates. The ROM was a classic BBC Micro ROM image containing a CINTCODE interpreter, command-line interface, and a few built-in commands. The compiler was not in the ROM but was run from disk, and was multi-pass. You could even run the compiler from cassette tape but I doubt anyone ever did without going mad; you would have to reload the entire program for each and every compilation. CINTCODE is loosely based in O-Code but was explictly designed to take up a little space as possible in disk or memory. I think John had written a CP/M port for the Z80 and this was used to bootstrap the 6502 version for the Beeb.
There were additional tools that permitted "standalone" versions of applications by binding a copy of the runtime with the compiled cintcode. Not very popular.
RCP also built 8086-based compilers for internal use but I don't think they were sold on. One was a 16-bit Cintcode compiler that was very effective for cross-compilation. The other was a 32-bit cintcode environment for DOS.
RCP can be found on the web at www.rcp.co.uk but I doubt there are many BCPL afficionados left...
Rob Burbidge (ne Seeman), former RCP employee
Just to reply to Rob, I too (Scott Earle) am a former RCP employee (Hi Rob!) who did some development work in BCPL, although all mine was in 1987. My memory tells me that the original implementation of BCPL was written by John Richards and another early RCP employee, who both also wrote the manual that accompanied the Acornsoft BCPL package.
The other early employee was Christopher Jobson, if you search Ebay you can still pick up copies of the user guide. (Zoë Jobson) — Preceding unsigned comment added by ZoeJobson (talk • contribs) 13:11, 15 April 2014 (UTC)
When developing software for production, we used to have tools to cross compile from an IBM PC (I used to use an IBM PC/XT 286 and an IBM PC/AT, as well as a BBC Master 128) to ROM images that were run from "sideways RAM" for testing on the target machine before being blown to EPROM for release. These images were copied to the target machine using ECONET. Interestingly, the ROM image contained the CINTCODE interpreter, that would run when the machine started - and also the compiled program. In this configuration, the CINTCODE interpreter was set up to automatically run the compiled program when it was started. —Preceding unsigned comment added by SWW (talk • contribs) 13:00, 13 February 2010 (UTC)
I've tweaked the intro a bit, and the bit on AmigaOS. Kickstart is probably the only remaining part of AmigaOS in BCPL, but the earliest versions of the command-line interface and the disk operating system (prior to the Kickstart 2.0 distribution) were written in BCPL. There is more about this in the relevant article. --Tony Sidaway 20:15, 3 October 2006 (UTC)
I'm surprised to see the assertion that Hungarian notation was developed for BCPL. While it would be useful in any typeless language, I've always understood Hungarian notation to be developed for C by Simonyi at Microsoft; the pre-ANSI C compilers used in early/mid 1980s had a fairly weak type system. Would be interesting to verify if BCPL was the originator of Hungarian. Certainly the Richards & W-S book doesn't use Hungarian. 220.127.116.11 09:59, 11 October 2006 (UTC)
The wording could perhaps be clearer. Hungarian notation was developed by Charles Simonyi at Xerox when he was working in BCPL. So it was first used in BCPL, but it was certainly not ubiquitous in BCPL development. DuncanBooth 11:41, 27 December 2006 (UTC)
The article lies "significant parts of AmigaOS including Kickstart". I'm sorry but that is bullcrap. Kickstart is the ROM chip of the Amiga, which contains a whole lot more than the DOS, which is what was written in BCPL. --18.104.22.168 16:21, 21 July 2007 (UTC)
I tend to agree with the above. The Amiga DOS came from TRIPOS which was written in BCPL. Kickstart, which was originally diskbased, and loaded at boot-up contained EXEC and other things necessary for the Amiga's multi-tasking OS. EXEC was most likely written in C, but could probably be confirmed by Carl Sassenrath the EXEC author. —Preceding unsigned comment added by 22.214.171.124 (talk) 00:50, 20 September 2007 (UTC)
LOL. I came here to point out the exact same thing. Only AmigaDOS was written in BCPL - not the other parts of the Kickstart ROM. Amazing that two years later no-one has bothered to correct the article, which again goes to show just how much Wikipedia sucks, with lousy arrogant stupid editors. Wikipedia ci w dupe! --126.96.36.199 (talk) 13:37, 8 July 2009 (UTC)
Early computers had a 16-bit word??
Does anyone have any evidence of this?
I used BCPL primarily on a DEC-10 - which had a 36 (yes, thirty-six) bit word - while working on Bartle's MUD. But then it had drum memory, and hard-wired transistor memory.
I think the PDP11 was 16 bit.
Word lengths were highly variable. Much of the development of BCPL was done on the Titan, which had a 48-bit word. It was the early minicomputers, like the PDP-8, that made the 16-bit word length popular.
PDP11 was a standard 8bit addressable machine with 16bit instructions. It was that which lead in part to the move from B to C, because B inherited the BCPL notion of machine word sized objects which then had to be faked up on the 11 just as on the Amiga.
16bit was actually quite unusual until the IBM/360 settled things down. 36bits is a magic number because 36bits was the same precision as existing mechanical calculating tools, 188.8.131.52 (talk) 17:25, 17 March 2016 (UTC)
Dennis Ritchie's preface
Dennis Ritchie's introduction to the BCPL Reference Manual expresses surprise that there should be two very similar versions of the manual produced on different typewriters. I would think it likely that it was not produced on a typewriter at all, but on a Friden Flexowriter. This was mechanically very similar to a typewriter, but was driven by paper tape. The master copy would have been edited on the Titan computer, output in paper tape form, and the tape then fed through the Flexowriter to produce hard copy. This was still the standard way of producing documents in Cambridge when I produced my PhD thesis in 1975, and I'm sure it had been around for a few years. The Flexowriter had a repertoire of punctuation characters that was different from the ASCII set we have become used to, and it certainly included the section symbol §. Mhkay (talk) 11:07, 9 April 2008 (UTC)
What's in a name?
This may or may not be a POV violation, but here goes anyway.....
I encountered BCPL at Sydney University in 1974 during lectures by a Dr Jan Hext and Dr Alan Bromley (not sure of either spelling as this was a long time ago). But I do remember clearly that Jan said that BCPL was an abbreviation of: "Before C Programming Language". For what that is worth.
What's in a name?
This may or may not be a POV violation, but here goes anyway.....
I encountered BCPL at Sydney University in 1974 during lectures by a Dr Jan Hext and Dr Alan Bromley (not sure of either spelling as this was a long time ago). But I do remember clearly that Jan said that BCPL was an abbreviation of: "Before C Programming Language". For what that is worth. — Preceding unsigned comment added by Old wombat (talk • contribs) 08:26, 5 March 2011 (UTC)
I'm pretty certain that the "BCPL: The Language And its compiler" states that B stands for Basic, as in "Basic CPL". Frankly, that should be an end to the debate, since Martin Richards ought to know. I've also heard it described as "Britain's Crummiest Programming Language" but that was very much an in-joke among the enthusiasts of the language Rob Burbidge (talk) 20:20, 11 November 2012 (UTC)
Canonical Syntax Page in Memorandum M-352 is missing
See Reference 2: "The BCPL Reference Manual (Memorandum M-352, Project MAC, Cambridge, July, 1967).
For some reason page 5 is missing from this pdf copy of the memorandum. Can anyone locate it? It is frustrating because it contains the (single page??) canonical syntax description (section 2.2 is clearly marked in the contents). Zteve (talk) 10:22, 11 April 2012 (UTC)
Dennis Ritchie's Web site  describes Karl Kleine's scan that you link to, and compares it with a different version of the same memo that DMR scanned. In other words, these are two scans of slightly different documents. DMR's version has section 2.2. On the other hand, Karl Kleine's version has the example programs.
Note that DMR has both TIFF and PDF formats. The PDF format is missing a few characters due to modern font problems.