Talk:BCPL

message: 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 90.5.7.87 (talk) 23:59, 31 August 2008 (UTC)
thread_title: Two Things

message: 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 67.169.85.47 (talk) 08:21, 26 December 2012 (UTC)
thread_title: Another Thing

message: 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. 86.11.47.92 (talk) 16:43, 18 March 2016 (UTC)
thread_title:  O-Code 

message: 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)
thread_title:  The BBC Micro implementation 

message: 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)
thread_title: Intro etc

message: 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)
thread_title: Hungarian Notation

message: 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. --194.251.240.113 16:21, 21 July 2007 (UTC)
replies: text: So fix it instead of just complaining here. Rlw (Talk) 15:47, 9 July 2009 (UTC)
thread_title:  Amiga 

message: 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.
Qixil (talk) 00:28, 2 March 2008 (UTC)
thread_title:  Early computers had a 16-bit word?? 

message: 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)
thread_title:  Dennis Ritchie's preface 

message: 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)
thread_title:  What's in a name? 

message: Whether a POV problem or not, this is an anachronism. BCPL pre-dates B which pre-dates C (I think it safe to assume that Hext was joking.) — Robert Greer (talk) 02:41, 6 March 2011 (UTC)
thread_title:  anachronism 

message: 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)
thread_title:  Naming, again 

message: 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)
thread_title:  Canonical Syntax Page in Memorandum M-352 is missing 

message: I couldn't find any historic reference that BCPL was a "curly bracket language".
The BCPL Reference Manual (July 21, 1967) define three type of "bracket delimiters": S (SBRA, SKET), R (RBRA, RKET) and SECT (SECTBRA, SECTKET). However a BCPL implementations could have a hardware representation were the bracket could be represented as characters or set of characters using preprocessor rules. At the time, common "bracket characters" were ( ), [ ], $( $) or § §. The Revised BCPL Manual (1979) use [ ] block delimiters.
Of course, BCPL could use curly bracket but as most of the era TTYs and terminal keyboards, especially the popular Teletype and "EBCDIC-apped" IBM ones, didn't always featured curlies, other characters were prefered.
So apparently BCPL never was an explicit "curly bracket language", use of curly brackets only seems to appear in later implementations. But by then curly brackets were already in use other languages, like B and C, which were explicitly using curly brackets and defined digraphs for non-ASCII compliant TTY/Keyboard (cf. http://www.thinkage.ca/gcos/expl/b/tuto/tuto.html#AppendixC, undated).
Is anyone have more information on the subject?  — Preceding unsigned comment added by 193.57.177.102 (talk) 10:47, 25 July 2018 (UTC)
thread_title:  Is BCPL really a "curly bracket language"? 

message: If "Hello World" was really first implemented in BCPl, it might make sense to make "Hello World" the very first piece of BCPL code introduced in the article. Comiscuous (talk) 19:58, 2 May 2021 (UTC)
thread_title:  "Hello World" 

message: The text jumps around a little in use of tense.  It may be that this is correct, but I wonder if it is actually due to multiple editors taking different (and sometimes incorrect) approaches to the tense in use.
It should be (have been) written from the point of tense of a present-day accounting of historical fact, with consideration of relative tenses mainly where some feature in the language has been superseded.  This is very difficult for me to explain clearly, not least because I am reading the content in order to learn about it: ie, I don't know how it should be written because I am not already in possession of the facts, and the text does not make these facts clear to me: someone with a proper understanding of correct use of past/present/future perfect/imperfect/etc tense AND also of the facts around the language (is that too much to ask?) could you please simply correct the use of tense (or else subtly clarify inline in the text, that the use of tense is appropriate) so that the article reads like an encyclopedic page should, and not like so much of the present-day awful television documentary world does, where the viewer is supposedly to be entranced and transported back in time to re-experience the horrors of the past (as if we have not enough of them today, as if the viewer has no interest in the content and must be hypnotised in order to benefit ... as if they have product to sell us and need stupid ignorant uninterested fools to keep watching for another 2 minutes until the ad. break.)
Thanks in advance, and thankyou for your patience anyone else who has wasted 6 minutes trying to parse this query in vain. — Preceding unsigned comment added by 2001:44b8:4146:600:2e1:50ff:fe00:256 (talk) 14:24, 15 May 2021 (UTC)
thread_title:  Confused mixture of tenses 

message: I was reading the article page because BCPL is mentioned on the Null-terminated string page as having had these, and presumably since Ritchie in implementing C first used BCPL, it seems plausible that he learned about the idea there.  Did BCPL in fact innovate this idea, or can an earlier (similar) implementation be found? — Preceding unsigned comment added by 2001:44B8:4146:600:2E1:50FF:FE00:256 (talk) 14:39, 15 May 2021 (UTC)
replies: text: No, BCPL did not use null-terminated strings. I worked with BCPL back in the 1980s, but if you need a printed source, this is from page 50 of my 1984 printing of "BCPL: the language and its compiler" - "By convention, byte 0 contains the number of characters in the string". -- John of Reading (talk) 18:08, 15 May 2021 (UTC)
thread_title:  NULL-terminated strings