User guide

4.2. BOOTSTRAPPING CINTPOS 101
hold the dumped Cintcode registers. A result of zero, signifying successful completion,
causes execution of Cintsys to terminate; however, if a non zero result is returned, the
debugger in entered by means of the call debug(res). Note that the Cintcode registers
are availabl e to the debugger since regs is a global variable. When debug returns,
the REPEAT-loop ensures that the command language interpreter is re-entered. The
debugger is briefly described in the Chapter 7.
On entry to startroot, the coroutine envir onme nt is initialised by setting currco
and colist to point to the base of the current stack which is then setup as the root
coroutine. The remaining globals ar e the initiali se d and the standard input and output
streams opened before loading the CLI program by means of the following statement:
rootnode!rtn_cli := globin(loadseg("syscin/cli"))
The command language interpreter is now e ntered by the call start().
4.2 Bootstrapping Cintpos
Bootstrapping Cintpos is somewhat more complicated than bootstrappi ng Cintsys since
there are more resident modules of code, and the Cintpos sy st e m structures and resident
tasks must be set up. Bo ots tr app i ng starts when the cintpos progr am is entered. It
first decodes the command arguments, possibly changing the Cintcode memory or tally
vector sizes. It then allocates these vectors, initialising every word of the Cintcode
memory with the value #xDEADCODE. It also allocates a vector to hold counts of how
many blocks of each requested size have been allocated getvec bu t not yet freed. It
then allocates and initialises the stack and global vector to be used by BOOT. The
rootnode is then initialised, i nc l ud i ng the settin g of the fields: rtn boot (holding the
module boot), rtn
klib (holding the module klib), rtn blib (holding the modules
blib, syslib and dlib) and rtn
sys (holding the entry point to the function sys).
The initial values of the Cintcode registers are now placed in the register set
bootregs. The Cintcode interpreter is entered to start execution from this initial
state. I f the interpreter returns a non ze r o r e su l t, a message containing this value is
written to the standard output stream, and, if the rtn dumpflag field of the root node
is TRUE, the entire Cintcode memory is dumped to the file DUMP.mem in compacted form
suitable for inspection by commands such as dumpsys or dumpdebug.
4.2.1 The Cintpos BOOT module
The function start in boot is the very first BCPL compiled co d e to be entered when
Cintpos starts. On entry, the Cintcode registers A, B and C are zero, P and G p oi nt
to BOOT’s stack and global vector, and ST is set to 2, i ndi c ati n g that we are in boot
and that interrupts are disabled. The global vector has already been ini ti al i s e d to hold
all the entr y points in boot, klib, blib, syslib and dlib, but the stack currently is
filled entirely with the val ue stackword=#xABCD1234 except for its zeroth word which
was set by cintpos to hold the stacksize . To improve the behaviour of the standal one
debugger, this stack is turned into a root coroutine stack of the specified si ze , initialising
the globals currco and colist appropriately.