RISCI_ATOM
/
harvey
mirror of https://github.com/Harvey-OS/harvey.git


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910
							<html>
<title>
data
</title>
<body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044">
<H1>Adding Application Support for a New Architecture in Plan 9
</H1>
<DL><DD><I>Bob Flandrena<br>
bobf@plan9.bell-labs.com<br>
</I></DL>
<H4>Introduction
</H4>
<br>&#32;<br>
Plan 9 has five classes of architecture-dependent software:
headers, kernels, compilers and loaders, the
<TT>libc</TT>
system library, and a few application programs.  In general,
architecture-dependent programs
consist of a portable part shared by all architectures and a
processor-specific portion for each supported architecture.
The portable code is often compiled and stored in a library
associated with
each architecture.  A program is built by
compiling the architecture-specific code and loading it with the
library.  Support for a new architecture is provided
by building a compiler for the architecture, using it to
compile the portable code into libraries,
writing the architecture-specific code, and
then loading that code with
the libraries.
<br>&#32;<br>
This document describes the organization of the architecture-dependent
code and headers on Plan 9.
The first section briefly discusses the layout of
the headers and the source code for the kernels, compilers, loaders, and the
system library, 
<TT>libc</TT>.
The second section provides a detailed
discussion of the structure of
<TT>libmach</TT>,
a library containing almost
all architecture-dependent code
used by application programs.
The final section describes the steps required to add
application program support for a new architecture.
<H4>Directory Structure
</H4>
<P>
Architecture-dependent information for the new processor
is stored in the directory tree rooted at <TT>/</TT><I>m</I>
where
<I>m</I>
is the name of the new architecture (e.g.,
<TT>mips</TT>).
The new directory should be initialized with several important
subdirectories, notably
<TT>bin</TT>,
<TT>include</TT>,
and
<TT>lib</TT>.
The directory tree of an existing architecture
serves as a good model for the new tree.
The architecture-dependent
<TT>mkfile</TT>
must be stored in the newly created root directory
for the architecture.  It is easiest to copy the
mkfile for an existing architecture and modify
it for the new architecture.  When the mkfile
is correct, change the
<TT>OS</TT>
and
<TT>CPUS</TT>
variables in the
<TT>/sys/src/mkfile.proto</TT>
to reflect the addition of the new architecture.
</P>
<H4>Headers
</H4>
<br>&#32;<br>
Architecture-dependent headers are stored in directory
<TT>/</TT><I>m</I><TT>/include</TT><I>
where
</I><I>m</I><I>
is the name of the architecture (e.g.,
</I><TT>mips</TT><I>).
Two header files are required:
</I><TT>u.h</TT><I>
and
</I><TT>ureg.h</TT><I>.
The first defines fundamental data types,
bit settings for the floating point
status and control registers, and
</I><TT>va_list</TT><I>
processing which depends on the stack
model for the architecture.  This file
is best built by copying and modifying the
</I><TT>u.h</TT><I>
file from an architecture
with a similar stack model.
The
</I><TT>ureg.h</TT><I>
file
contains a structure describing the layout
of the saved register set for
the architecture; it is defined by the kernel.
</I><br>&#32;<br>
Header file
<TT>/sys/include/a.out.h</TT>
contains the definitions of the magic
numbers used to identify executables for
each architecture.  When support for a new
architecture is added, the magic number
for the architecture must be added to this file.
<br>&#32;<br>
The header format of a bootable executable is defined by
each manufacturer.  Header file
<TT>/sys/include/bootexec.h</TT>
contains structures describing the headers currently
supported.  If the new architecture uses a common header
such as COFF,
the header format is probably already defined,
but if the bootable header format is non-standard,
a structure defining the format must be added to this file.
<br>&#32;<br>
<H4>Kernel
</H4>
<br>&#32;<br>
Although the kernel depends critically on the properties of the underlying
hardware, most of the
higher-level kernel functions, including process
management, paging, pseudo-devices, and some
networking code, are independent of processor
architecture.  The portable kernel code
is divided into two parts: that implementing kernel
functions and that devoted to the boot process.
Code in the first class is stored in directory
<TT>/sys/src/9/port</TT>
and the portable boot code is stored in
<TT>/sys/src/9/boot</TT>.
Architecture-dependent kernel code is stored in the
subdirectories of
<TT>/sys/src/9</TT>
named for each architecture.
<br>&#32;<br>
The relationship between the kernel code and the boot code
is convoluted and subtle.  The portable boot code
is compiled into a library for each architecture.  An architecture-specific
main program is loaded with the appropriate library and the resulting
executable is compiled into the kernel where it is executed as
a user process during the final stages of kernel initialization.  The boot process
performs authentication, attaches the name space root to the appropriate
file system and starts the
<TT>init</TT>
process.
<br>&#32;<br>
The organization of the portable kernel source code differs from that
of most other architecture-specific code.
Instead of storing the portable code in a library
and loading it with the architecture-specific
code, the portable code is compiled directly into
the directory containing the architecture-specific code
and linked with the object files built from the source in that directory.
<br>&#32;<br>
<H4>Compilers and Loaders
</H4>
<br>&#32;<br>
The compiler source code conforms to the usual
organization: portable code is compiled into a library
for each architecture
and the architecture-dependent code is loaded with
that library.
The common compiler code is stored in
<TT>/sys/src/cmd/cc</TT>.
The
<TT>mkfile</TT>
in this directory compiles the portable source and
archives the objects in a library for each architecture.
The architecture-specific compiler source
is stored in a subdirectory of
<TT>/sys/src/cmd</TT>
with the same name as the compiler (e.g.,
<TT>/sys/src/cmd/vc</TT>).
<br>&#32;<br>
There is no portable code shared by the loaders.
Each directory of loader source
code is self-contained, except for
a header file and an instruction name table
included from the
directory of the associated
compiler.
<br>&#32;<br>
<H4>Libraries
</H4>
<br>&#32;<br>
Most C library modules are
portable; the source code is stored in
directories
<TT>/sys/src/libc/port</TT>
and
<TT>/sys/src/libc/9sys</TT>.
Architecture-dependent library code
is stored in the subdirectory of
<TT>/sys/src/libc</TT>
named the same as the target processor.
Non-portable functions not only
implement architecture-dependent operations
but also supply assembly language implementations
of functions where speed is critical.
Directory
<TT>/sys/src/libc/9syscall</TT>
is unusual because it
contains architecture-dependent information
for all architectures.
It holds only a header file defining
the names and numbers of system calls
and a
<TT>mkfile</TT>.
The
<TT>mkfile</TT>
executes an
<TT>rc</TT>
script that parses the header file, constructs
assembler language functions implementing the system
call for each architecture, assembles the code,
and archives the object files in
<TT>libc</TT>.
The assembler language syntax and the system interface
differ for each architecture.
The
<TT>rc</TT>
script in this
<TT>mkfile</TT>
must be modified to support a new architecture.
<br>&#32;<br>
<H4>Applications
</H4>
<br>&#32;<br>
Application programs process two forms of architecture-dependent
information: executable images and intermediate object files.
Almost all processing is on executable files.
System library
<TT>libmach</TT>
provides functions that convert
architecture-specific data
to a portable format so application programs
can process this data independent of its
underlying representation.
Further, when a new architecture is implemented
almost all code changes
are confined to the library;
most affected application programs need only be reloaded.
The source code for the library is stored in
<TT>/sys/src/libmach</TT>.
<br>&#32;<br>
An application program running on one type of
processor must be able to interpret
architecture-dependent information for all
supported processors.
For example, a debugger must be able to debug
the executables of
all architectures, not just the
architecture on which it is executing, since
<TT>/proc</TT>
may be imported from a different machine.
<br>&#32;<br>
A small part of the application library
provides functions to
extract symbol references from object files.
The remainder provides the following processing
of executable files or memory images:
<DL><DD>
<br>&#32;<br>
<UL>
<LI>
Header interpretation.
<LI>
Symbol table interpretation.
<LI>
Execution context interpretation, such as stack traces
and stack frame location.
<LI>
Instruction interpretation including disassembly and
instruction size and follow-set calculations.
<LI>
Exception and floating point number interpretation.
<LI>
Architecture-independent read and write access through a
relocation map.
</DL>
</ul>
<br>&#32;<br>
Header file
<TT>/sys/include/mach.h</TT>
defines the interfaces to the
application library.  Manual pages
<A href="/magic/man2html/2/mach"><I>mach</I>(2),
</A><A href="/magic/man2html/2/symbol"><I>symbol</I>(2),
</A>and
<A href="/magic/man2html/2/object"><I>object</I>(2)
</A>describe the details of the
library functions.
<br>&#32;<br>
Two data structures, called
<TT>Mach</TT>
and
<TT>Machdata</TT>,
contain architecture-dependent  parameters and
a jump table of functions.
Global variables
<TT>mach</TT>
and
<TT>machdata</TT>
point to the
<TT>Mach</TT>
and
<TT>Machdata</TT>
data structures associated with the target architecture.
An application determines the target architecture of
a file or executable image, sets the global pointers
to the data structures associated with that architecture,
and subsequently performs all references indirectly through the
pointers.
As a result, direct references to the tables for each
architecture are avoided and the application code intrinsically
supports all architectures (though only one at a time).
<br>&#32;<br>
Object file processing is handled similarly: architecture-dependent
functions identify and
decode the intermediate files for the processor.
The application indirectly
invokes a classification function to identify
the architecture of the object code and to select the
appropriate decoding function.  Subsequent calls
then use that function to decode each record.  Again,
the layer of indirection allows the application code
to support all architectures without modification.
<br>&#32;<br>
Splitting the architecture-dependent information
between the
<TT>Mach</TT>
and
<TT>Machdata</TT>
data structures
allows applications to choose
an appropriate level of service.  Even though an application
does not directly reference the architecture-specific data structures,
it must load the
architecture-dependent tables and code 
for all architectures it supports.  The size of this data
can be substantial and many applications do not require
the full range of architecture-dependent functionality.
For example, the
<TT>size</TT>
command does not require the disassemblers for every architecture;
it only needs to decode the header.
The
<TT>Mach</TT>
data structure contains a few architecture-specific parameters
and a description of the processor register set.
The size of the structure
varies with the size of the register
set but is generally small.
The
<TT>Machdata</TT>
data structure contains
a jump table of architecture-dependent functions;
the amount of code and data referenced by this table
is usually large.
<H4>Libmach Source Code Organization
</H4>
<br>&#32;<br>
The
<TT>libmach</TT>
library provides four classes of functionality:
<br>&#32;<br>
<DL COMPACT>
<DT>Header and Symbol Table Decoding - <DD>
Files
<TT>executable.c</TT>
and
<TT>sym.c</TT>
contain code to interpret the header and
symbol tables of
an executable file or executing image.
Function
<TT>crackhdr</TT>
decodes the header,
reformats the
information into an
<TT>Fhdr</TT>
data structure, and points
global variable
<TT>mach</TT>
to the
<TT>Mach</TT>
data structure of the target architecture.
The symbol table processing
uses the data in the
<TT>Fhdr</TT>
structure to decode the symbol table.
A variety of symbol table access functions then support
queries on the reformatted table.
<DT>Debugger Support - <DD>
Files named
<TT></TT><I>m</I><TT>.c</TT><I>,
where
</I><I>m</I><I>
is the code letter assigned to the architecture,
contain the initialized
</I><TT>Mach</TT><I>
data structure and the definition of the register
set for each architecture.
Architecture-specific debugger support functions and
an initialized
</I><TT>Machdata</TT><I>
structure are stored in
files named
</I><TT></TT><I>m</I><TT>db.c</TT><I>.
Files
</I><TT>machdata.c</TT><I>
and
</I><TT>setmach.c</TT><I>
contain debugger support functions shared
by multiple architectures.
<DT>Architecture-Independent Access - <DD>
Files
</I><TT>map.c</TT><I>,
</I><TT>access.c</TT><I>,
and
</I><TT>swap.c</TT><I>
provide accesses through a relocation map
to data in an executable file or executing image.
Byte-swapping is performed as needed.  Global variables
</I><TT>mach</TT><I>
and
</I><TT>machdata</TT><I>
must point to the
</I><TT>Mach</TT><I>
and
</I><TT>Machdata</TT><I>
data structures of the target architecture.
<DT>Object File Interpretation - <DD>
These files contain functions to identify the
target architecture of an
intermediate object file
and extract references to symbols.  File
</I><TT>obj.c</TT><I>
contains code common to all architectures;
file
</I><TT></TT><I>m</I><TT>obj.c</TT><I>
contains the architecture-specific source code
for the machine with code character
</I><I>m</I><I>.
</dl>
</I><br>&#32;<br>
The
<TT>Machdata</TT>
data structure is primarily a jump
table of architecture-dependent debugger support
functions. Functions select the
<TT>Machdata</TT>
structure for a target architecture based
on the value of the
<TT>type</TT>
code in the
<TT>Fhdr</TT>
structure or the name of the architecture.
The jump table provides functions to swap bytes, interpret
machine instructions,
perform stack
traces, find stack frames, format floating point
numbers, and decode machine exceptions.  Some functions, such as
machine exception decoding, are idiosyncratic and must be
supplied for each architecture.  Others depend
on the compiler run-time model and several
architectures may share code common to a model.  For
example, many architectures share the code to
process the fixed-frame stack model implemented by
several of the compilers.
Finally, some
functions, such as byte-swapping, provide a general capability and
the jump table need only select an implementation appropriate
to the architecture.
<br>&#32;<br>
<H4>Adding Application Support for a New Architecture
</H4>
<br>&#32;<br>
This section describes the
steps required to add application-level
support for a new architecture.
We assume
the kernel, compilers, loaders and system libraries
for the new architecture are already in place.  This
implies that a code-character has been assigned and
that the architecture-specific headers have been
updated.
With the exception of two programs,
application-level changes are confined to header
files and the source code in
<TT>/sys/src/libmach</TT>.
<br>&#32;<br>
<DL COMPACT>
<DT>1.<DD>
Begin by updating the application library
header file in
<TT>/sys/include/mach.h</TT>.
Add the following symbolic codes to the
<TT>enum</TT>
statement near the beginning of the file:
<DL><DD>
<DT>*<DD>
The processor type code, e.g., 
<TT>MSPARC</TT>.
<DT>*<DD>
The type of the executable.  There are usually
two codes needed: one for a bootable
executable (i.e., a kernel) and one for an
application executable.
<DT>*<DD>
The disassembler type code.  Add one entry for
each supported disassembler for the architecture.
<DT>*<DD>
A symbolic code for the object file.
</DL>
</dl>
<br>&#32;<br>
<DL COMPACT>
<DT>2.<DD>
In a file name
<TT>/sys/src/libmach/</TT><I>m</I><TT>.c</TT><I>
(where
</I><I>m</I><I>
is the identifier character assigned to the architecture),
initialize
</I><TT>Reglist</TT><I>
and
</I><TT>Mach</TT><I>
data structures with values defining
the register set and various system parameters.
The source file for a similar architecture
can serve as template.
Most of the fields of the
</I><TT>Mach</TT><I>
data structure are obvious
but a few require further explanation.
<DL><DD>
<DT></I><TT>kbase</TT><I> - <DD>
This field
contains the address of the kernel 
</I><TT>ublock</TT><I>.
The debuggers
assume the first entry of the kernel
</I><TT>ublock</TT><I>
points to the
</I><TT>Proc</TT><I>
structure for a kernel thread.
<DT></I><TT>ktmask</TT><I> - <DD>
This field
is a bit mask used to calculate the kernel text address from
the kernel 
</I><TT>ublock</TT><I>
address.
The first page of the
kernel text segment is calculated by
ANDing
the negation of this mask with
</I><TT>kbase</TT><I>.
<DT></I><TT>kspoff</TT><I> - <DD>
This field
contains the byte offset in the
</I><TT>Proc</TT><I>
data structure to the saved kernel
stack pointer for a suspended kernel thread.  This
is the offset to the 
</I><TT>sched.sp</TT><I>
field of a
</I><TT>Proc</TT><I>
table entry.
<DT></I><TT>kpcoff</TT><I> - <DD>
This field contains the byte offset into the
</I><TT>Proc</TT><I>
data structure
of
the program counter of a suspended kernel thread.
This is the offset to
field
</I><TT>sched.pc</TT><I>
in that structure.
<DT></I><TT>kspdelta</TT><I> and </I><TT>kpcdelta</TT><I> - <DD>
These fields
contain corrections to be added to
the stack pointer and program counter, respectively,
to properly locate the stack and next
instruction of a kernel thread.  These
values bias the saved registers retrieved
from the
</I><TT>Label</TT><I>
structure named
</I><TT>sched</TT><I>
in the
</I><TT>Proc</TT><I>
data structure.
Most architectures require no bias
and these fields contain zeros.
<DT></I><TT>scalloff</TT><I> - <DD>
This field
contains the byte offset of the
</I><TT>scallnr</TT><I>
field in the
</I><TT>ublock</TT><I>
data structure associated with a process.
The
</I><TT>scallnr</TT><I>
field contains the number of the
last system call executed by the process.
The location of the field varies depending on
the size of the floating point register set
which precedes it in the
</I><TT>ublock</TT><I>.
</DL>
</dl>
</I><br>&#32;<br>
<DL COMPACT>
<DT>3.<DD>
Add an entry to the initialization of the
<TT>ExecTable</TT>
data structure at the beginning of file
<TT>/sys/src/libmach/executable.c</TT>.
Most architectures
require two entries: one for
a normal executable and
one for a bootable
image.  Each table entry contains:
<DL><DD>
<DT>*<DD>
Magic Number - 
The big-endian magic number assigned to the architecture in
<TT>/sys/include/a.out.h</TT>.
<DT>*<DD>
Name - 
A string describing the executable.
<DT>*<DD>
Executable type code - 
The executable code assigned in
<TT>/sys/include/mach.h</TT>.
<DT>*<DD>
<TT>Mach</TT> pointer - 
The address of the initialized
<TT>Mach</TT>
data structure constructed in Step 2.
You must also add the name of this table to the
list of
<TT>Mach</TT>
table definitions immediately preceding the
<TT>ExecTable</TT>
initialization.
<DT>*<DD>
Header size - 
The number of bytes in the executable file header.
The size of a normal executable header is always
<TT>sizeof(Exec)</TT>.
The size of a bootable header is
determined by the size of the structure
for the architecture defined in
<TT>/sys/include/bootexec.h</TT>.
<DT>*<DD>
Byte-swapping function - 
The address of
<TT>beswal</TT>
or
<TT>leswal</TT>
for big-endian and little-endian
architectures, respectively.
<DT>*<DD>
Decoder function - 
The address of a function to decode the header.
Function
<TT>adotout</TT>
decodes the common header shared by all normal
(i.e., non-bootable) executable files.
The header format of bootable
executable files is defined by the manufacturer and
a custom function is almost always
required to decode it.
Header file
<TT>/sys/include/bootexec.h</TT>
contains data structures defining the bootable
headers for all architectures.  If the new architecture
uses an existing format, the appropriate
decoding function should already be in
<TT>executable.c</TT>.
If the header format is unique, then
a new function must be added to this file.
Usually the decoding function for an existing
architecture can be adopted with minor modifications.
</DL>
</dl>
<br>&#32;<br>
<DL COMPACT>
<DT>4.<DD>
Write an object file parser and
store it in file
<TT>/sys/src/libmach/</TT><I>m</I><TT>obj.c</TT><I>
where
</I><I>m</I><I>
is the identifier character assigned to the architecture.
Two functions are required: a predicate to identify an
object file for the architecture and a function to extract
symbol references from the object code.
The object code format is obscure but
it is often possible to adopt the
code of an existing architecture
with minor modifications.
When these
functions are in hand, insert their addresses
in the jump table at the beginning of file
</I><TT>/sys/src/libmach/obj.c</TT><I>.
</dl>
</I><br>&#32;<br>
<DL COMPACT>
<DT>5.<DD>
Implement the required debugger support functions and
initialize the parameters and jump table of the
<TT>Machdata</TT>
data structure for the architecture.
This code is conventionally stored in
a file named
<TT>/sys/src/libmach/</TT><I>m</I><TT>db.c</TT><I>
where
</I><I>m</I><I>
is the identifier character assigned to the architecture.
The fields of the
</I><TT>Machdata</TT><I>
structure are:
<DL><DD>
<DT></I><TT>bpinst</TT><I> and </I><TT>bpsize</TT><I> - <DD>
These fields
contain the breakpoint instruction and the size
of the instruction, respectively.
<DT></I><TT>swab</TT><I> - <DD>
This field
contains the address of a function to
byte-swap a 16-bit value.  Choose
</I><TT>leswab</TT><I>
or
</I><TT>beswab</TT><I>
for little-endian or big-endian architectures, respectively.
<DT></I><TT>swal</TT><I> - <DD>
This field
contains the address of a function to
byte-swap a 32-bit value.  Choose
</I><TT>leswal</TT><I>
or
</I><TT>beswal</TT><I>
for little-endian or big-endian architectures, respectively.
<DT></I><TT>ctrace</TT><I> - <DD>
This field
contains the address of a function to perform a
C-language stack trace.  Two general trace functions,
</I><TT>risctrace</TT><I>
and
</I><TT>cisctrace</TT><I>,
traverse fixed-frame and relative-frame stacks,
respectively.  If the compiler for the
new architecture conforms to one of
these models, select the appropriate function.  If the
stack model is unique,
supply a custom stack trace function.
<DT></I><TT>findframe</TT><I> - <DD>
This field
contains the address of a function to locate the stack
frame associated with a text address.
Generic functions
</I><TT>riscframe</TT><I>
and
</I><TT>ciscframe</TT><I>
process fixed-frame and relative-frame stack
models.
<DT></I><TT>ufixup</TT><I> - <DD>
This field
contains the address of a function to adjust
the base address of the register save area.
Currently, only the
68020 requires this bias
to offset over the active
exception frame.
<DT></I><TT>excep</TT><I> - <DD>
This field
contains the address of a function to produce a
text
string describing the
current exception.
Each architecture stores exception
information uniquely, so this code must always be supplied.
<DT></I><TT>bpfix</TT><I> - <DD>
This field
contains the address of a function to adjust an
address prior to laying down a breakpoint.
<DT></I><TT>sftos</TT><I> - <DD>
This field
contains the address of a function to convert a single
precision floating point value
to a string.  Choose
</I><TT>leieeesftos</TT><I>
for little-endian
or
</I><TT>beieeesftos</TT><I>
for big-endian architectures.
<DT></I><TT>dftos</TT><I> - <DD>
This field
contains the address of a function to convert a double
precision floating point value
to a string.  Choose
</I><TT>leieeedftos</TT><I>
for little-endian
or
</I><TT>beieeedftos</TT><I>
for big-endian architectures.
<DT></I><TT>foll</TT><I>, </I><TT>das</TT><I>, </I><TT>hexinst</TT><I>, and </I><TT>instsize</TT><I> - <DD>
These fields point to functions that interpret machine
instructions.
They rely on disassembly of the instruction
and are unique to each architecture.
</I><TT>Foll</TT><I>
calculates the follow set of an instruction.
</I><TT>Das</TT><I>
disassembles a machine instruction to assembly language.
</I><TT>Hexinst</TT><I>
formats a machine instruction as a text
string of
hexadecimal digits.
</I><TT>Instsize</TT><I>
calculates the size in bytes, of an instruction.
Once the disassembler is written, the other functions
can usually be implemented as trivial extensions of it.
</dl>
</I><br>&#32;<br>
It is possible to provide support for a new architecture
incrementally by filling the jump table entries
of the
<TT>Machdata</TT>
structure as code is written.  In general, if
a jump table entry contains a zero, application
programs requiring that function will issue an
error message instead of attempting to
call the function.  For example,
the
<TT>foll</TT>,
<TT>das</TT>,
<TT>hexinst</TT>,
and
<TT>instsize</TT>
jump table slots can be zeroed until a
disassembler is written.
Other capabilities, such as
stack trace or variable inspection,
can be supplied and will be available to
the debuggers but attempts to use the
disassembler will result in an error message.
</DL>
<DL COMPACT>
<DT>6.<DD>
Update the table named
<TT>machines</TT>
near the beginning of
<TT>/sys/src/libmach/setmach.c</TT>.
This table binds the
file type code and machine name to the
<TT>Mach</TT>
and
<TT>Machdata</TT>
structures of an architecture.
The names of the initialized
<TT>Mach</TT>
and
<TT>Machdata</TT>
structures built in steps 2 and 5
must be added to the list of
structure definitions immediately
preceding the table initialization.
If both Plan 9 and
native disassembly are supported, add
an entry for each disassembler to the table.  The
entry for the default disassembler (usually
Plan 9) must be first.
<DT>7.<DD>
Add an entry describing the architecture to
the table named
<TT>trans</TT>
near the end of
<TT>/sys/src/cmd/prof.c</TT>.
</DL>
<DT>8.<DD>
Add an entry describing the architecture to
the table named
<TT>objtype</TT>
near the start of
<TT>/sys/src/cmd/pcc.c</TT>.
</DL>
<DT>9.<DD>
Recompile and install
all application programs that include header file
<TT>mach.h</TT>
and load with
<TT>libmach.a</TT>.
</dl>
<br>&#32;<br>
<A href=http://www.lucent.com/copyright.html>
Copyright</A> &#169; 2004 Lucent Technologies Inc.  All rights reserved.
</body></html>