How does the BCPL global vector work?

Is the global vector zero-initialized (or something) with a fixed size at the beginning of program execution?

If the global vector is unbounded in size and new global definitions can be dynamically added, how do we prevent the vector from "bumping into" other bits of global data?

I'm interested in understanding how this worked originally in BCPL and how it works now in the updated BCPL distribution if that is substantially different.

BCPL is an old language that predates C. It has a manual here.

The key differences from C are that it is typeless (aside from the FLT directive in modern versions) and that it has a global array of shared values as the sole means of sharing functions between translation units.

In the BCPL manual on page 37 by internal numbering (47 by pdf numbering), we have the following example code (with comments inserted).

// demohdr
GET "libhdr"

GLOBAL { f : 200 }
// demolib.b
GET "demohdr"

LET f(...) = VALOF {
// demomain.b
GET "demohdr"

LET start() BE {

The language is typeless, so in all cases f is just a {16,32,64}-bit word.

This all makes sense, at runtime it's just a pointer to a function (I think that would just be a pointer inside some text segment somewhere).

The manual includes the following description which suggests to me that portions of the global vector may be replaced at runtime in an ad hoc way, and potentially suggests that the global vector can grow without bound.

Although the global vector mechanism has disadvantages, particularly in the organisation of library packages, there are some compensating benefits arising from its extreme simplicity. One is that the output of the compiler is available directly for execution without the need for a link editing step. Sections may also be loaded and unloaded dynamically during the execution of a program using the library functions loadseg and unloadseg, and so arbitrary overlaying schemes can be organised easily.

  • 2
    Judging by explanations like "this was devised when machines were small, disc space was very limited and modern day linkage editors had not been invented" I would expect a really really simple implementation, such as an area of a fixed,, OS-dependent size (e.g. "256 bytes on a PDP-11"). But that's a guess, one would need to look at working BCPL + OS support relict to find out.
    – dirkt
    Commented Apr 4, 2022 at 16:45
  • 2
    The linked manual was updated only last month. Is there something going on in BCPL circles of interest to us here? Some software release?
    – dave
    Commented Apr 4, 2022 at 20:26
  • @another-dave I'm not sure. I'm not part of the BCPL community per se ... From what I can gather, Martin Richards is still working on the language and occasionally adds new features like floating point numbers (stack exchange link). Some of the Raspberry Pi support is relatively new I think. Commented Apr 4, 2022 at 20:42
  • 1
    @dirkt: I wonder why such approaches weren't used for personal-computer software development during the floppy-drive or even paper-tape era. If a language had separate "interface" and "implementation" files, it would be possible to build a program with a single pass through all of the interface files, followed by a single pass through all of the implementation files, writing in a single pass, for each implementation file, a blob of code which could, be processed by a simple relocating loader in such a way as to allow "incremental builds" and 'linking' merely by cutting/splicing tape.
    – supercat
    Commented Apr 5, 2022 at 19:17
  • @supercat Well, there were, for example in UCSD Pascal units (though not exactly as you described it). And Cobol and Fortran always had "common" areas, also in personal-computer (e.g. CP/M) implementations.
    – dirkt
    Commented Apr 6, 2022 at 5:36

1 Answer 1


From chapter 1, page 1 internal, of the linked document, when running under Cintsys:

-g n Set the default global vector upb to n

On page 46 (internal), the default size is specified as 2000, but this is not applicable to the native system. See rtn_gvecsize.


I infer(ok, guess) that the native system would have allocated a fixed-size vector, modifiable in source.

  • I think cintsys and cintpos are the single- and multi-threaded interpreters. Also, I think that's on page 46 (internal) / 56 (pdf) in the description of the constant rtn_gvecsize. That's a good find. The fact that this is a constant suggests that it is set once when the interpreter starts and cannot later be changed. Actually, wait. I think you might describing the command line flag on page 1/11. That's consistent with the "this thing is set once" hypothesis for the interpreters. Commented Apr 4, 2022 at 20:12
  • Fixed the typo for page 46. Added page ref for page 1. Thanks.
    – dave
    Commented Apr 4, 2022 at 20:24
  • 2
    @Greg, cintsys is the Cintcode system itself, while cintpos is the portable operating system built on top of it. The latter is not an interpreter itself but an "application" containing Cintcode instructions.
    – paxdiablo
    Commented Apr 5, 2022 at 5:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .