The sound library uses the sys(Sys sound,...) functions to provide facilities for reading, writing and analysisng sound data. There is a sound header file (g/sound.h) declaring various constants and globals available in the sound library. The sound library itself can be inserted into a program by the following statements.
MANIFEST { soundgbase=450 } GET "sound.h"
GET "sound.b"
The manifest constant soundgbase specifies the position of the first global variable to be used by the sound library.
3.8.1 The Sound Constants
The sound library is not yet available.
3.8.2 The Sound Global Variables
The sound library is not yet available.
3.8.3 The Sound Functions
The sound library is not yet available.
Chapter 4
The Command Language
The Command Language Interpreter (CLI) is a simple interactive interface between the user and the system. It loads and executes previously compiled programs that are held either in the current directory or one of the directories specified by the shell environ-ment variable (typically BCPLPATH or POSPATH) whose name is in rootnode!rtn path.
These commands are described in Section 4.3 and their source code can be found in the com directory. The command language is a combination of the features provided by the CLI and the collection of commands that can be invoked. Under Cintpos, a similar CLI program provides command language interpreters in several contexts such as those created by the commands: run, newcli, tcpcli and mbxcli. Details of the implementation of both CLIs are given at the end of this chapter from page 124.
Commands can set a return code in the global returncode with zero meaning successful termination and other values indicating the severity of the fault. Commands that set a non zero return code are expected to leave a reason code in result2. The CLI copies the return code and reason code of the previous command into the CLI variables cli returncode and cli result2, respectively. These can be inspected by commands such as if and why and also used by the CLI to terminate a command-command if the failure was severe enough. For details, see the command-command failat on page 111 below.
4.1 Bootstrapping Cintsys
When Cintsys is started, control is passed to the interpreter which, after a few initial checks, allocates vectors for the memory of the Cintcode abstract machine and the tally vector available for statistics gathering. The Cintcode memory is initialised suitably for sub-allocation by getvec, which is then used to allocate space for the root node, the initial stack and the initial global vector. The initial state shown in figure 4.1 is completed by loading the object modules SYSLIB, BLIB and BOOT, and initialising the root node, the stack and global vector. Interpretation of Cintcode instructions now begins with the Cintcode register PC, P and G set as shown in the figure, and Count set to -1. The other registers are cleared. The first Cintcode instruction to be executed is the first instruction of the body of the function start defined in sysb/boot.b. Since
95
no return link has been stored into the stack, this call of start must not attempt to return in the normal way; however, its execution can still be terminated using sys(Sys quit,0).
The global vector and stack shown in figure 4.1 are used by start and form the running environment both during initialization and while running the debugger. The CLI, on the other hand, is provided with a new stack and a separate global vector, thus allowing the debugger to use its own globals freely without interfering with the command language interpreter or running commands. The global vector of 1000 words is allocated for the CLI and this is shared by the CLI program and its running com-mands. The stack, on the other hand, is used exclusively by the command language interpreter since it creates a coroutine for each command it runs.
stack globals
P G
rootnode
0 PC
Entry to start Tally vector
blklist
SYSLIB BLIB BOOT
Figure 4.1: The initial state
Control is passed to the CLI by means of the call sys(Sys interpret,regs) which recursively enters the intepreter from an initial Cintcode state specified by the vector regsin which that P and G are set to point to the bases of a new stack and a new global vector for CLI, respectively, PC is the location of the first instruction of startcli, and count is set to -1. This call of sys(Sys interpret,regs) is embedded in the loop shown below that occurs at the end of the body of start.
{ LET res = sys(Sys_interpret, regs) // Call the interpreter IF res=0 DO sys(Sys_quit, 0)
debug res // Enter the debugger
} REPEAT
At the moment sys(Sys interpret,regs) is first called, only globsize, sys and rootnode have been set in CLI’s global vector and so the body of startroot must be coded with care to avoid calling global functions before their entry points have be placed in the global vector. Thus, for instance, instead of calling globin to initialise the globals defined in BLIB, SYSLIB and DLIB, the following code is used:
sys(Sys_globin, rootnode!rtn_blib)
If a fault occurs during the execution of CLI or a command that it is running, the call of sys(Sys interpret,regs) will return with the fault code and regs will