\documentstyle[a4,12pt]{article}
\begin{document}
\author{Lee Smith}
\title{Version 1 MIT C Compiler}
\maketitle
\parskip .1 in
\setcounter{secnumdepth}{10}
\parindent 0in
\section{Preamble}
C Compiler for Motorola 68000 \hspace{ 2.1 in} Lee Smith

As of 12/04/83, a version of the MIT portable C compiler (sans floating
point support) which generates M68000 machine code has been moved
to the APM. It compiles C as described in Kernighan \& Ritchie's book
"The C Programming Language". Enough of a run-time handler exists
to support the compiler,linker,etc. The standard i/o header is in C:STDIO.H
which, for the present, should be denoted as "C:STDIO.H" rather than as
the more conventional $<$STDIO.H$>$.

\section{Compiling}
On the APM, C is accessed via the 'command' C:CC. The format is:

\hspace*{ 0.2 in} C:CC $<$filename$>$ [$<$pre-processor flags$>$]

The output relocatable machine code is left in $<$basename$>$.REL, where
$<$basename$>$ is formed by stripping any extension (rightmost ...)
from $<$filename$>$.

Pre-processor Flags

The pre-processor allows a sequence of symbols to be \#identified\{d\} from
the command line. These are given as -drhing1 -dthing2 etc. Similarly,
symbols may be initially \#undef\{ined\} using -uthing...


\section{Linking}
.REL files can be linked together using the C:CLINK command:

\hspace*{ 0.2 in} C:CLINK $<$f1$>$....$<$fn$>$ [-i$<$ct1$>$] -?$<$output$>$

$<$f1$>$ etc. are a space-separated list of .REL files; C:CLIB.REL
is the name of the standard run-time library (see below).
-i$<$ct1$>$ is an optional control file containing a list of files to be
linked and possibly, linker -i and the filename. ? is o, b or p
depending on whether the output is to be another .REL file (which
can be linked further), a binary image (.MOB file, conventionally)
which is runnable, or a patched (optimised) binary image (.MOB,again)
in which as many JSR xxxxxxxx as possible are converted to PC-relative
form to minimise image size and loading time. NOTE: THIS CONVERSION
MAY NOT ALWAYS BE SAFE. DO NOT COMPLAIN UNLESS A -b IMAGE FAILS TO
RUN. Once again, there must be NO space between -? and the filename
(which must be given in full, with the extension explicity supplied by the
user).

See further information on the Linker below.


\section{Run-time Library}
The run-time library implements functions such as printf,scanf, exit, etc.
At the present time the library is sufficiently extensive to support the C
compiler. Omissions should be notified to LDS. Deviations from the Unix
conventions for library support should, likewise, be notified to LDS. The
standard i/o header is in C:STDIO.H. The C source of the run-time library is
in C:CLIB.C.

The major omissions at the moment are:

1. No support for floating-point numbers (there is no machine support for
them yet anyway).

2. lseek has not been implemented; fseek supports fseek(fp,0,0) ONLY
(seek to start of file). Limitations in the filestore interface currently
preclude a full implementation of either of these functions.

3. On the APM, there is currently no way to include only part of the
run-time library (the bit you need): you either get it all or you
get none of it. Fixing this requires further discussion of library standards
and linker/loader standards for the APM.



\section{The C Linker}
The C linker assembles a number of .REL files into either (a) another .REL
file which can be linked further or (b) an executable, self-relocating
image, which can be run according to the APM conventions (1st byte of image
is X'FE', load the image anywhere and JSR to the last longword of it).
If the image so produced is left in a file THING.MOB then it can be run on the
APM by issuing the 'command' THING.

When the linker is building an executable
image it automatically loads the C machine support (C:CRTS) and the bootstrap
relocator (C:CLDR). The C run-time library C:CLIB.REL is NOT loaded
automatically.

The format of the CLINK command is described above.

If an input control file is specified with a -i$<$ct1$>$ parameter then a list of
names of files to be linked may be given (the list maybe empty) FOLLOWED
by a list of linker control commands. The names of files to be linked together
and the linker control commands must be separated by spaces and/or newlines.
2
The linker control commands are as follows:

\hspace*{ 0.3 in} *equate \hspace{ 0.3 in} $<$symbol1$>$ to $<$symbol2$>$
\\ \hspace*{ 0.3 in} *rename \hspace{ 0.3 in} $<$symbol1$>$ as $<$symbol2$>$
\\ \hspace*{ 0.3 in} *hide \hspace{ 0.5 in} $<$symbol$>$
\\ \hspace*{ 0.3 in} *hideall
\\ \hspace*{ 0.3 in} *unhide \hspace{ 0.3 in} $<$symbol$>$

ONLY *equate HAS BEEN TESTED; report bugs to LDS.

*equate $<$s1$>$ to $<$s2$>$ causes all references to $<$s1$>$ (which MUST be UNdefined)
to be re-directed to $<$s2$>$ (which need not be defined).

*rename $<$s1$>$ as $<$s2$>$ causes the symbol $<$s1$>$ to be renamed $<$s2$>$; $<$s2$>$ must
NOT EXIST at the point where the renaming takes place.

*hide $<$s$>$ deletes external symbol $<$s$>$ from the symbol-table of the output
.REL file. $<$s$>$ MUST be defined. This allows to modules with
different definitions of (say) external routine fred (or, rather, the C
equivalent therof) to be linked together quite happily by hiding one of
the freds from the other.

*hideall hides all DEFINED symbols; an UNdefined symbol cannot be hidden
(otherwise the reference would NEVER be resolved).

*unhide $<$s$>$ reverses the effect of a *hide $<$s$>$ or *hideall command.

Typically, I would expect these commands to be used to assemble an almost
complete module with a carefully controlled set of exported symbols. Such
a module can be called by users without fear that their choice of external
names might clash with that of the module builders (and if it does then the
clashes can be resolved using *rename).


\vspace{.75in} view:mit_c printed on 14/02/89 at 14.32

\newpage
\tableofcontents
\end{document}