User guide

102 CHAPTER 4. THE COMMAND LANGUAGE
All console input and output within BOOT and the standalone debugger is done
using the standalone version of rdch and wrch, so these globals are updated appro-
priately. BOOT next initialises the variables used by the standalone debugger. These
include the vectors bpt
addr, bpt instr and bpt dbgvars which respectively hold
break point address, breakpoint instructions that have been overwritten by the BRK
instruction, and the vector of the 10 standalone debugger variables V0 to V9. These
three vec tor s are placed in the rootnode to make them accessible both to the DEBUG
task and to dumpdebug when it is inspecting a system dump.
BOOT now creates and initialises a global vector and a stack to be used during the
further initialisation of the Cintpos system. The all elements of the global vector are
given values of the for m globword(=#x8F8F0000)+n, except for the globals globsize,
sys, rootnode, currco and colist, the last two being set to zero. Every element of
the stack is set to stackword (=#xABCD1234). The register set klibregs is initialised,
giving zero to A, B and C, the stack and global vector pointers to P and G, the value
one to ST to indicate execution is in KLIB and interrupts are disabled, and the entry
point startroot in PC. This register set is the n handed to a recur s i ve call of the
interpreter. This inner call is the one than performs the rest of the initialisation and
enters the normal execution of Cintpos. In due course the interpreter will return with
a completion code which controls what BOOT should do next.
A comple t i on code of zero signifies successfully completion and BOOT causes the
termination of cintpos. A return code of -1 is special, causing BOOT to re-enter
the interpreter immediately. Its purpose is to allow a running program to change
which interpreter is used. There ar e typically two interpreters: a slow one in which
all debugging aids are turne d on, and a fast one in which most aids are turned off.
The call sys(Sys
interpret, regs) selects the fast interpreter if the count register
in regs is -1, othe r wi se it selects the slow interpreter. The return code -2 allows
a r u nni ng program to invoke the dumpmem mechanism to write t he file DUMP.mem
representing the curre nt state of the entire Cintcode memory. Any other return code
caused BOOT to invoke the standalone debugger, which many in due course return
allowing the interpreter to be re-entered.
BOOT cunningly places a private version of the sys function in its global vector
so that, even if a breakpoi nt is set in the public version of sys, BOOT and in partic-
ular the standalone debugger can continue to work as normal. When BOOT invokes
the interpreter for the first time execution begins at the start of startroot which is
described in the next section.
4.2.2 startroot
This function creates the Cintpos running environment and loads all the resident system
tasks. Finally it enters the Cintpos scheduler which, in turn, gives control to the Idle
task which sends a packet to the root CLI task. After some i ni t i al i sat i on, this issues the
first CLI prompt inviting the user to type in a command. Knowledge of the underlying
structures used by Cintpos i f key to underst and how Cintpos works. They are described
in this section in the order in which startroot creates them.