<html><title>data</title><body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044"><H1>How to Use the Plan 9 C Compiler</H1><DL><DD><I>Rob Pike<br>rob@plan9.bell-labs.com<br></I></DL><H4>Introduction</H4><P>The C compiler on Plan 9 is a wholly new program; in factit was the first piece of software written for what wouldeventually become Plan 9 from Bell Labs.Programmers familiar with existing C compilers will finda number of differences in both the language the Plan 9 compileraccepts and in how the compiler is used.</P><P>The compiler is really a set of compilers, one for eacharchitecture ­ MIPS, SPARC, Motorola 68020, Intel 386, etc. ­that accept a dialect of ANSI C and efficiently producefairly good code for the target machine.There is a packaging of the compiler that accepts strict ANSI C fora POSIX environment, but this document focuses on thenative Plan 9 environment, that in which all the system source andalmost all the utilities are written.</P><H4>Source</H4><P>The language accepted by the compilers is the core ANSI C languagewith some modest extensions,a greatly simplified preprocessor,a smaller library that includes system calls and related facilities,and a completely different structure for include files.</P><P>Official ANSI C accepts the old (K&R) style of declarations forfunctions; the Plan 9 compilersare more demanding.Without an explicit run-time flag(<TT>-B</TT>)whose use is discouraged, the compilers insiston new-style function declarations, that is, prototypes forfunction arguments.The function declarations in the libraries' include files areall in the new style so the interfaces are checked at compile time.For C programmers who have not yet switched to function prototypesthe clumsy syntax may seem repellent but the payoff in stronger typingis substantial.Those who wish to import existing software to Plan 9 are urgedto use the opportunity to update their code.</P><P>The compilers include an integrated preprocessor that accepts the familiar<TT>#include</TT>,<TT>#define</TT>for macros both with and without arguments,<TT>#undef</TT>,<TT>#line</TT>,<TT>#ifdef</TT>,<TT>#ifndef</TT>,and<TT>#endif</TT>.Itsupports neither<TT>#if</TT>nor<TT>##</TT>,although it doeshonor a few<TT>#pragmas</TT>.The<TT>#if</TT>directive was omitted because it greatly complicates thepreprocessor, is never necessary, and is usually abused.Conditional compilation in general makes code hard to understand;the Plan 9 source uses it sparingly.Also, because the compilers remove dead code, regular<TT>if</TT>statements with constant conditions are more readable equivalents to many<TT>#ifs</TT>.To compile imported code ineluctably fouled by<TT>#if</TT>there is a separate command,<TT>/bin/cpp</TT>,that implements the complete ANSI C preprocessor specification.</P><P>Include files fall into two groups: machine-dependent and machine-independent.The machine-independent files occupy the directory<TT>/sys/include</TT>;the others are placed in a directory appropriate to the machine, such as<TT>/mips/include</TT>.The compiler searches for include filesfirst in the machine-dependent directory and thenin the machine-independent directory.At the time of writing there are thirty-one machine-independent includefiles and two (per machine) machine-dependent ones:<TT><ureg.h></TT>and<TT><u.h></TT>.The first describes the layout of registers on the system stack,for use by the debugger.The second defines somearchitecture-dependent types such as<TT>jmp_buf</TT>for<TT>setjmp</TT>and the<TT>va_arg</TT>and<TT>va_list</TT>macros for handling arguments to variadic functions,as well as a set of<TT>typedef</TT>abbreviations for<TT>unsigned</TT><TT>short</TT>and so on.</P><P>Here is an excerpt from<TT>/68020/include/u.h</TT>:<DL><DT><DD><TT><PRE>#define nil ((void*)0)typedef unsigned short ushort;typedef unsigned char uchar;typedef unsigned long ulong;typedef unsigned int uint;typedef signed char schar;typedef long long vlong; typedef long jmp_buf[2];#define JMPBUFSP 0#define JMPBUFPC 1#define JMPBUFDPC 0</PRE></TT></DL>Plan 9 programs use<TT>nil</TT>for the name of the zero-valued pointer.The type<TT>vlong</TT>is the largest integer type available; on most architectures itis a 64-bit value.A couple of other types in<TT><u.h></TT>are<TT>u32int</TT>,which is guaranteed to have exactly 32 bits (a possibility on all the supported architectures) and<TT>mpdigit</TT>,which is used by the multiprecision math package<TT><mp.h></TT>.The<TT>#define</TT>constants permit an architecture-independent (but compiler-dependent)implementation of stack-switching using<TT>setjmp</TT>and<TT>longjmp</TT>.</P><P>Every Plan 9 C program begins<DL><DT><DD><TT><PRE>#include <u.h></PRE></TT></DL>because all the other installed header files use the<TT>typedefs</TT>declared in<TT><u.h></TT>.</P><P>In strict ANSI C, include files are grouped to collect related functionsin a single file: one for string functions, one for memory functions,one for I/O, and none for system calls.Each include file is protected by an<TT>#ifdef</TT>to guarantee its contents are seen by the compiler only once.Plan 9 takes a different approach. Other than a few includefiles that define external formats such as archives, the files in<TT>/sys/include</TT>correspond to<I>libraries.</I>If a program is using a library, it includes the corresponding header.The default C library comprises string functions, memory functions, andso on, largely as in ANSI C, some formatted I/O routines,plus all the system calls and related functions.To use these functions, one must<TT>#include</TT>the file<TT><libc.h></TT>,which in turn must follow<TT><u.h></TT>,to define their prototypes for the compiler.Here is the complete source to the traditional first C program:<DL><DT><DD><TT><PRE>#include <u.h>#include <libc.h> voidmain(void){ print("hello world\n"); exits(0);}</PRE></TT></DL>The<TT>print</TT>routine and its relatives<TT>fprint</TT>and<TT>sprint</TT>resemble the similarly-named functions in Standard I/O but are notattached to a specific I/O library.In Plan 9<TT>main</TT>is not integer-valued; it should call<TT>exits</TT>,which takes a string argument (or null; here ANSI C promotes the 0 to a<TT>char*</TT>).All these functions are, of course, documented in the Programmer's Manual.</P><P>To use<TT>printf</TT>,<TT><stdio.h></TT>must be included to define the function prototype for<TT>printf</TT>:<DL><DT><DD><TT><PRE>#include <u.h>#include <libc.h>#include <stdio.h> voidmain(int argc, char *argv[]){ printf("%s: hello world; argc = %d\n", argv[0], argc); exits(0);}</PRE></TT></DL>In practice, Standard I/O is not used much in Plan 9. I/O libraries arediscussed in a later section of this document.</P><P>There are libraries for handling regular expressions, raster graphics,windows, and so on, and each has an associated include file.The manual for each library states which include files are needed.The files are not protected against multiple inclusion and themselvescontain no nested<TT>#includes</TT>.Instead theprogrammer is expected to sort out the requirementsand to<TT>#include</TT>the necessary files once at the top of each source file. In practice this istrivial: this way of handling include files is so straightforwardthat it is rare for a source file to contain more than half a dozen<TT>#includes</TT>.</P><P>The compilers do their own register allocation so the<TT>register</TT>keyword is ignored.For different reasons,<TT>volatile</TT>and<TT>const</TT>are also ignored.</P><P>To make it easier to share code with other systems, Plan 9 has a versionof the compiler,<TT>pcc</TT>,that provides the standard ANSI C preprocessor, headers, and librarieswith POSIX extensions.<TT>Pcc</TT>is recommended onlywhen broad external portability is mandated. It compiles slower,produces slower code (it takes extra work to simulate POSIX on Plan 9),eliminates those parts of the Plan 9 interfacenot related to POSIX, and illustrates the clumsiness of an environmentdesigned by committee.<TT>Pcc</TT>is described in more detail inAPE­The ANSI/POSIX Environment,by Howard Trickey.</P><H4>Process</H4><P>Each CPU architecture supported by Plan 9 is identified by a single,arbitrary, alphanumeric character:<TT>k</TT>for SPARC,<TT>q</TT>for Motorola Power PC 630 and 640,<TT>v</TT>for MIPS,<TT>1</TT>for Motorola 68000,<TT>2</TT>for Motorola 68020 and 68040,<TT>5</TT>for Acorn ARM 7500,<TT>6</TT>for Intel 960,<TT>7</TT>for DEC Alpha,<TT>8</TT>for Intel 386, and<TT>9</TT>for AMD 29000.The character labels the support tools and files for that architecture.For instance, for the 68020 the compiler is<TT>2c</TT>,the assembler is<TT>2a</TT>,the link editor/loader is<TT>2l</TT>,the object files are suffixed<TT>.2</TT>,and the default name for an executable file is<TT>2.out</TT>.Before we can use the compiler we therefore need to know whichmachine we are compiling for.The next section explains how this decision is made; for the momentassume we are building 68020 binaries and make the mental substitution for<TT>2</TT>appropriate to the machine you are actually using.</P><P>To convert source to an executable binary is a two-step process.First run the compiler,<TT>2c</TT>,on the source, say<TT>file.c</TT>,to generate an object file<TT>file.2</TT>.Then run the loader,<TT>2l</TT>,to generate an executable<TT>2.out</TT>that may be run (on a 680X0 machine):<DL><DT><DD><TT><PRE>2c file.c2l file.22.out</PRE></TT></DL>The loader automatically links with whatever libraries the programneeds, usually including the standard C library as defined by<TT><libc.h></TT>.Of course the compiler and loader have lots of options, both familiar and new;see the manual for details.The compiler does not generate an executable automatically;the output of the compiler must be given to the loader.Since most compilation is done under the control of<TT>mk</TT>(see below), this is rarely an inconvenience.</P><P>The distribution of work between the compiler and loader is unusual.The compiler integrates preprocessing, parsing, register allocation,code generation and some assembly.Combining these tasks in a single program is part of the reason forthe compiler's efficiency.The loader does instruction selection, branch folding,instruction scheduling,and writes the final executable.There is no separate C preprocessor and no assembler in the usual pipeline.Instead the intermediate object file(here a<TT>.2</TT>file) is a type of binary assembly language.The instructions in the intermediate format are not exactly those inthe machine. For example, on the 68020 the object file may specifya MOVE instruction but the loader will decide just which variant ofthe MOVE instruction ­ MOVE immediate, MOVE quick, MOVE address,etc. ­ is most efficient.</P><P>The assembler,<TT>2a</TT>,is just a translator between the textual and binaryrepresentations of the object file format.It is not an assembler in the traditional sense. It has limitedmacro capabilities (the same as the integral C preprocessor in the compiler),clumsy syntax, and minimal error checking. For instance, the assemblerwill accept an instruction (such as memory-to-memory MOVE on the MIPS) that themachine does not actually support; only when the output of the assembleris passed to the loader will the error be discovered.The assembler is intended only for writing things that need access to instructionsinvisible from C,such as the machine-dependentpart of an operating system;very little code in Plan 9 is in assembly language.</P><P>The compilers take an option<TT>-S</TT>that causes them to print on their standard output the generated codein a format acceptable as input to the assemblers.This is of course merely a formatting of thedata in the object file; therefore the assembler is justanASCII-to-binary converter for this format.Other than the specific instructions, the input to the assemblersis largely architecture-independent; see``A Manual for the Plan 9 Assembler'',by Rob Pike,for more information.</P><P>The loader is an integral part of the compilation process.Each library header file contains a<TT>#pragma</TT>that tells the loader the name of the associated archive; it isnot necessary to tell the loader which libraries a program uses.The C run-time startup is found, by default, in the C library.The loader starts with an undefinedsymbol,<TT>_main</TT>,that is resolved by pulling in the run-time startup code from the library.(The loader undefines<TT>_mainp</TT>when profiling is enabled, to force loading of the profiling start-upinstead.)</P><P>Unlike its counterpart on other systems, the Plan 9 loader rearrangesdata to optimize access. This means the order of variables in theloaded program is unrelated to its order in the source.Most programs don't care, but some assume that, for example, thevariables declared by<DL><DT><DD><TT><PRE>int a;int b;</PRE></TT></DL>will appear at adjacent addresses in memory. On Plan 9, they won't.</P><H4>Heterogeneity</H4><P>When the system starts or a user logs in the environment is configuredso the appropriate binaries are available in<TT>/bin</TT>.The configuration process is controlled by an environment variable,<TT>$cputype</TT>,with value such as<TT>mips</TT>,<TT>68020</TT>,<TT>386</TT>,or<TT>sparc</TT>.For each architecture there is a directory in the root,with the appropriate name,that holds the binary and library files for that architecture.Thus<TT>/mips/lib</TT>contains the object code libraries for MIPS programs,<TT>/mips/include</TT>holds MIPS-specific include files, and<TT>/mips/bin</TT>has the MIPS binaries.These binaries are attached to<TT>/bin</TT>at boot time by binding<TT>/$cputype/bin</TT>to<TT>/bin</TT>,so<TT>/bin</TT>always contains the correct files.</P><P>The MIPS compiler,<TT>vc</TT>,by definitionproduces object files for the MIPS architecture,regardless of the architecture of the machine on which the compiler is running.There is a version of<TT>vc</TT>compiled for each architecture:<TT>/mips/bin/vc</TT>,<TT>/68020/bin/vc</TT>,<TT>/sparc/bin/vc</TT>,and so on,each capable of producing MIPS object files regardless of the nativeinstruction set.If one is running on a SPARC,<TT>/sparc/bin/vc</TT>will compile programs for the MIPS;if one is running on machine<TT>$cputype</TT>,<TT>/$cputype/bin/vc</TT>will compile programs for the MIPS.</P><P>Lines 1–500 of 1513. Load more
<html> <title> data </title> <body BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#330088" ALINK="#FF0044"> <H1>How to Use the Plan 9 C Compiler </H1> <DL><DD><I>Rob Pike<br> rob@plan9.bell-labs.com<br> </I></DL> <H4>Introduction </H4> <P> The C compiler on Plan 9 is a wholly new program; in fact it was the first piece of software written for what would eventually become Plan 9 from Bell Labs. Programmers familiar with existing C compilers will find a number of differences in both the language the Plan 9 compiler accepts and in how the compiler is used. </P> <P> The compiler is really a set of compilers, one for each architecture ­ MIPS, SPARC, Motorola 68020, Intel 386, etc. ­ that accept a dialect of ANSI C and efficiently produce fairly good code for the target machine. There is a packaging of the compiler that accepts strict ANSI C for a POSIX environment, but this document focuses on the native Plan 9 environment, that in which all the system source and almost all the utilities are written. </P> <H4>Source </H4> <P> The language accepted by the compilers is the core ANSI C language with some modest extensions, a greatly simplified preprocessor, a smaller library that includes system calls and related facilities, and a completely different structure for include files. </P> <P> Official ANSI C accepts the old (K&R) style of declarations for functions; the Plan 9 compilers are more demanding. Without an explicit run-time flag (<TT>-B</TT>) whose use is discouraged, the compilers insist on new-style function declarations, that is, prototypes for function arguments. The function declarations in the libraries' include files are all in the new style so the interfaces are checked at compile time. For C programmers who have not yet switched to function prototypes the clumsy syntax may seem repellent but the payoff in stronger typing is substantial. Those who wish to import existing software to Plan 9 are urged to use the opportunity to update their code. </P> <P> The compilers include an integrated preprocessor that accepts the familiar <TT>#include</TT>, <TT>#define</TT> for macros both with and without arguments, <TT>#undef</TT>, <TT>#line</TT>, <TT>#ifdef</TT>, <TT>#ifndef</TT>, and <TT>#endif</TT>. It supports neither <TT>#if</TT> nor <TT>##</TT>, although it does honor a few <TT>#pragmas</TT>. The <TT>#if</TT> directive was omitted because it greatly complicates the preprocessor, is never necessary, and is usually abused. Conditional compilation in general makes code hard to understand; the Plan 9 source uses it sparingly. Also, because the compilers remove dead code, regular <TT>if</TT> statements with constant conditions are more readable equivalents to many <TT>#ifs</TT>. To compile imported code ineluctably fouled by <TT>#if</TT> there is a separate command, <TT>/bin/cpp</TT>, that implements the complete ANSI C preprocessor specification. </P> <P> Include files fall into two groups: machine-dependent and machine-independent. The machine-independent files occupy the directory <TT>/sys/include</TT>; the others are placed in a directory appropriate to the machine, such as <TT>/mips/include</TT>. The compiler searches for include files first in the machine-dependent directory and then in the machine-independent directory. At the time of writing there are thirty-one machine-independent include files and two (per machine) machine-dependent ones: <TT><ureg.h></TT> and <TT><u.h></TT>. The first describes the layout of registers on the system stack, for use by the debugger. The second defines some architecture-dependent types such as <TT>jmp_buf</TT> for <TT>setjmp</TT> and the <TT>va_arg</TT> and <TT>va_list</TT> macros for handling arguments to variadic functions, as well as a set of <TT>typedef</TT> abbreviations for <TT>unsigned</TT> <TT>short</TT> and so on. </P> <P> Here is an excerpt from <TT>/68020/include/u.h</TT>: <DL><DT><DD><TT><PRE> #define nil ((void*)0) typedef unsigned short ushort; typedef unsigned char uchar; typedef unsigned long ulong; typedef unsigned int uint; typedef signed char schar; typedef long long vlong; typedef long jmp_buf[2]; #define JMPBUFSP 0 #define JMPBUFPC 1 #define JMPBUFDPC 0 </PRE></TT></DL> Plan 9 programs use <TT>nil</TT> for the name of the zero-valued pointer. The type <TT>vlong</TT> is the largest integer type available; on most architectures it is a 64-bit value. A couple of other types in <TT><u.h></TT> are <TT>u32int</TT>, which is guaranteed to have exactly 32 bits (a possibility on all the supported architectures) and <TT>mpdigit</TT>, which is used by the multiprecision math package <TT><mp.h></TT>. The <TT>#define</TT> constants permit an architecture-independent (but compiler-dependent) implementation of stack-switching using <TT>setjmp</TT> and <TT>longjmp</TT>. </P> <P> Every Plan 9 C program begins <DL><DT><DD><TT><PRE> #include <u.h> </PRE></TT></DL> because all the other installed header files use the <TT>typedefs</TT> declared in <TT><u.h></TT>. </P> <P> In strict ANSI C, include files are grouped to collect related functions in a single file: one for string functions, one for memory functions, one for I/O, and none for system calls. Each include file is protected by an <TT>#ifdef</TT> to guarantee its contents are seen by the compiler only once. Plan 9 takes a different approach. Other than a few include files that define external formats such as archives, the files in <TT>/sys/include</TT> correspond to <I>libraries.</I> If a program is using a library, it includes the corresponding header. The default C library comprises string functions, memory functions, and so on, largely as in ANSI C, some formatted I/O routines, plus all the system calls and related functions. To use these functions, one must <TT>#include</TT> the file <TT><libc.h></TT>, which in turn must follow <TT><u.h></TT>, to define their prototypes for the compiler. Here is the complete source to the traditional first C program: <DL><DT><DD><TT><PRE> #include <u.h> #include <libc.h> void main(void) { print("hello world\n"); exits(0); } </PRE></TT></DL> The <TT>print</TT> routine and its relatives <TT>fprint</TT> and <TT>sprint</TT> resemble the similarly-named functions in Standard I/O but are not attached to a specific I/O library. In Plan 9 <TT>main</TT> is not integer-valued; it should call <TT>exits</TT>, which takes a string argument (or null; here ANSI C promotes the 0 to a <TT>char*</TT>). All these functions are, of course, documented in the Programmer's Manual. </P> <P> To use <TT>printf</TT>, <TT><stdio.h></TT> must be included to define the function prototype for <TT>printf</TT>: <DL><DT><DD><TT><PRE> #include <u.h> #include <libc.h> #include <stdio.h> void main(int argc, char *argv[]) { printf("%s: hello world; argc = %d\n", argv[0], argc); exits(0); } </PRE></TT></DL> In practice, Standard I/O is not used much in Plan 9. I/O libraries are discussed in a later section of this document. </P> <P> There are libraries for handling regular expressions, raster graphics, windows, and so on, and each has an associated include file. The manual for each library states which include files are needed. The files are not protected against multiple inclusion and themselves contain no nested <TT>#includes</TT>. Instead the programmer is expected to sort out the requirements and to <TT>#include</TT> the necessary files once at the top of each source file. In practice this is trivial: this way of handling include files is so straightforward that it is rare for a source file to contain more than half a dozen <TT>#includes</TT>. </P> <P> The compilers do their own register allocation so the <TT>register</TT> keyword is ignored. For different reasons, <TT>volatile</TT> and <TT>const</TT> are also ignored. </P> <P> To make it easier to share code with other systems, Plan 9 has a version of the compiler, <TT>pcc</TT>, that provides the standard ANSI C preprocessor, headers, and libraries with POSIX extensions. <TT>Pcc</TT> is recommended only when broad external portability is mandated. It compiles slower, produces slower code (it takes extra work to simulate POSIX on Plan 9), eliminates those parts of the Plan 9 interface not related to POSIX, and illustrates the clumsiness of an environment designed by committee. <TT>Pcc</TT> is described in more detail in APE­The ANSI/POSIX Environment, by Howard Trickey. </P> <H4>Process </H4> <P> Each CPU architecture supported by Plan 9 is identified by a single, arbitrary, alphanumeric character: <TT>k</TT> for SPARC, <TT>q</TT> for Motorola Power PC 630 and 640, <TT>v</TT> for MIPS, <TT>1</TT> for Motorola 68000, <TT>2</TT> for Motorola 68020 and 68040, <TT>5</TT> for Acorn ARM 7500, <TT>6</TT> for Intel 960, <TT>7</TT> for DEC Alpha, <TT>8</TT> for Intel 386, and <TT>9</TT> for AMD 29000. The character labels the support tools and files for that architecture. For instance, for the 68020 the compiler is <TT>2c</TT>, the assembler is <TT>2a</TT>, the link editor/loader is <TT>2l</TT>, the object files are suffixed <TT>.2</TT>, and the default name for an executable file is <TT>2.out</TT>. Before we can use the compiler we therefore need to know which machine we are compiling for. The next section explains how this decision is made; for the moment assume we are building 68020 binaries and make the mental substitution for <TT>2</TT> appropriate to the machine you are actually using. </P> <P> To convert source to an executable binary is a two-step process. First run the compiler, <TT>2c</TT>, on the source, say <TT>file.c</TT>, to generate an object file <TT>file.2</TT>. Then run the loader, <TT>2l</TT>, to generate an executable <TT>2.out</TT> that may be run (on a 680X0 machine): <DL><DT><DD><TT><PRE> 2c file.c 2l file.2 2.out </PRE></TT></DL> The loader automatically links with whatever libraries the program needs, usually including the standard C library as defined by <TT><libc.h></TT>. Of course the compiler and loader have lots of options, both familiar and new; see the manual for details. The compiler does not generate an executable automatically; the output of the compiler must be given to the loader. Since most compilation is done under the control of <TT>mk</TT> (see below), this is rarely an inconvenience. </P> <P> The distribution of work between the compiler and loader is unusual. The compiler integrates preprocessing, parsing, register allocation, code generation and some assembly. Combining these tasks in a single program is part of the reason for the compiler's efficiency. The loader does instruction selection, branch folding, instruction scheduling, and writes the final executable. There is no separate C preprocessor and no assembler in the usual pipeline. Instead the intermediate object file (here a <TT>.2</TT> file) is a type of binary assembly language. The instructions in the intermediate format are not exactly those in the machine. For example, on the 68020 the object file may specify a MOVE instruction but the loader will decide just which variant of the MOVE instruction ­ MOVE immediate, MOVE quick, MOVE address, etc. ­ is most efficient. </P> <P> The assembler, <TT>2a</TT>, is just a translator between the textual and binary representations of the object file format. It is not an assembler in the traditional sense. It has limited macro capabilities (the same as the integral C preprocessor in the compiler), clumsy syntax, and minimal error checking. For instance, the assembler will accept an instruction (such as memory-to-memory MOVE on the MIPS) that the machine does not actually support; only when the output of the assembler is passed to the loader will the error be discovered. The assembler is intended only for writing things that need access to instructions invisible from C, such as the machine-dependent part of an operating system; very little code in Plan 9 is in assembly language. </P> <P> The compilers take an option <TT>-S</TT> that causes them to print on their standard output the generated code in a format acceptable as input to the assemblers. This is of course merely a formatting of the data in the object file; therefore the assembler is just an ASCII-to-binary converter for this format. Other than the specific instructions, the input to the assemblers is largely architecture-independent; see ``A Manual for the Plan 9 Assembler'', by Rob Pike, for more information. </P> <P> The loader is an integral part of the compilation process. Each library header file contains a <TT>#pragma</TT> that tells the loader the name of the associated archive; it is not necessary to tell the loader which libraries a program uses. The C run-time startup is found, by default, in the C library. The loader starts with an undefined symbol, <TT>_main</TT>, that is resolved by pulling in the run-time startup code from the library. (The loader undefines <TT>_mainp</TT> when profiling is enabled, to force loading of the profiling start-up instead.) </P> <P> Unlike its counterpart on other systems, the Plan 9 loader rearranges data to optimize access. This means the order of variables in the loaded program is unrelated to its order in the source. Most programs don't care, but some assume that, for example, the variables declared by <DL><DT><DD><TT><PRE> int a; int b; </PRE></TT></DL> will appear at adjacent addresses in memory. On Plan 9, they won't. </P> <H4>Heterogeneity </H4> <P> When the system starts or a user logs in the environment is configured so the appropriate binaries are available in <TT>/bin</TT>. The configuration process is controlled by an environment variable, <TT>$cputype</TT>, with value such as <TT>mips</TT>, <TT>68020</TT>, <TT>386</TT>, or <TT>sparc</TT>. For each architecture there is a directory in the root, with the appropriate name, that holds the binary and library files for that architecture. Thus <TT>/mips/lib</TT> contains the object code libraries for MIPS programs, <TT>/mips/include</TT> holds MIPS-specific include files, and <TT>/mips/bin</TT> has the MIPS binaries. These binaries are attached to <TT>/bin</TT> at boot time by binding <TT>/$cputype/bin</TT> to <TT>/bin</TT>, so <TT>/bin</TT> always contains the correct files. </P> <P> The MIPS compiler, <TT>vc</TT>, by definition produces object files for the MIPS architecture, regardless of the architecture of the machine on which the compiler is running. There is a version of <TT>vc</TT> compiled for each architecture: <TT>/mips/bin/vc</TT>, <TT>/68020/bin/vc</TT>, <TT>/sparc/bin/vc</TT>, and so on, each capable of producing MIPS object files regardless of the native instruction set. If one is running on a SPARC, <TT>/sparc/bin/vc</TT> will compile programs for the MIPS; if one is running on machine <TT>$cputype</TT>, <TT>/$cputype/bin/vc</TT> will compile programs for the MIPS. </P> <P>