Talk:BCPL
From Wikipedia, the free encyclopedia
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).
Martin Richards has released a distribution of his BCPL compiler (compiling to CINTCODE I believe): http://www.cl.cam.ac.uk/users/mr/BCPL.html --drj
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
Contents |
[edit] 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
[edit] O-Code
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)
[edit] 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
[edit] Intro etc
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)
[edit] Hungarian Notation
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. 62.172.213.137 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)
