Previously I wrote about the issues bootstrapping BCPL on my Ruby board and I was moaning about needing a C front-end or “shim” to get BCPL going.

So I engaged the little grey cells and worked out a strategy…

What I’ve done is to write sufficient ‘816 assembler code to initialise the BCPL global vector and create a stack, then to point the cintcode program counter to some embedded cintcode (embedded into the ASM program as a binary blob), and call the cintcode interpreter.

At this point the bootstrap program can call local functions but not global ones. The “blob” is actually the bare minimum in terms of library calls to get BCPL fully going. I created it by simply concatenating the files (sections) and turning them into a form I can include in-line with the assembler source for the cintcode interpreter.

The BCPL bootstrap fixes-up the global vector by scanning the concatenated section images and working out the correct offsets to populate the global vector with. The first call I then make is the getvec setup call to initialise the memory for subsequent allocations, then I call the loadseg() function to load the rest of the library files into RAM as before with the C front-end. It’s already running BCPL at that point, so the last file it loads is the command line interpreter which is loaded and called and the system is ready. This is slightly quicker than the C front-end too as some of the library routines are loaded with the interpreter and remain there for the rest of time.

And so the paradox is no more!

Ruby BCPL Bootstrap