
October 13 1995, Draft 1
352
Addendum to –– Evaluating and Programming the 29K RISC Family
The memory system is then analyzed in the process of building the data struc-
ture passed to
dbg_control()
. In some cases this involves the operation of dynamic
memory sizing code. The floating–point trap handlers are then prepared for opera-
tion. Initialization of floating–point support is a one–time operation, so it occurs be-
fore
dbg_control()
is called.
Before the cold–start operation is complete, additional vector table entries are
made to support DebugCore operation, entries such as V_TRACE. The DebugCore/
OS shared data structure is then initialized and vector table entry 71 is set to point to
the base of the data structure. The message system is then initialized with a call to
msg_init()
and
dbg_control()
is called, indicating the completion of operating sys-
tem cold–start code.
The return from
dbg_control()
causes execution of the operating system
warm–start code to commence at address
warm_start
. The run time environment is
now prepared. Much of this is concerned with memory management. The memory
and register stack support registers are assigned values before any loaded application
code starts. The warm–start code examines the return parameters from
dbg_con-
trol()
in preparing the run–time environment.
With 29K family members which have TLB hardware, OS–boot is normally
configured to start application code execution in User mode with address translation
turned on. Warm–start code gets the application code start address from return regis-
ters
gr100
. This address is loaded into the frozen PC–buffer registers and an IRET
used to depart the operating system supervisor mode code and enter the application
code in User mode. Register
gr104
is used to select operating system warm–start op-
tions. If bit 31 is set then application code is started with no address translation en-
abled. (To use this feature set
gr104
to –1 after using the MonDFE
y
command to
yank–in application code into target system memory.) Note, warm–start code does
not issue an IRET instruction directly, it jumps to the DebugCore service
dbg_iret
.
This enables the DebugCore to set the TE bit in the OPS register and so enable single
stepping of the first application code instruction. Additionally the BTE and BPID
fields of any breakpoint registers in use are also set by
dbg_iret
.
7.4.3 HIF Services
Once application code has started, operating system code will only be again
called into play when: a floating–point trap occurs; a peripheral generates an inter-
rupt; or when a HIF service is requested. HIF is a system call interface specification.
OS–boot supplies the necessary support code which is accessed by a system call trap
instruction. Many of the library calls, such as
printf()
, result in HIF trapware being
called. HIF trapware support starts at address label
HIFTrap
.
HIF services are divided into two groups, those that can be satisfied by the 29K
itself (such as the
sysalloc
service), and those that need MonTIP support (such as
open
). The HIF specification states that the service request number be placed in reg-