<html><head><title>Compilers and Object Files</title></head>
<body background="images/tile">
<center><h3>Compilers and Object Files</h3></center>
<p>
<h4>Introduction:</h4>
<br>
 This is a short essay on AOF (Acorn Object Format) files, what they are and their relevance to compilers, such as GCC and the Acorn PD Pascal compiler.Much of this you may already know, but, if you don't, it will prove invaluble when using (or trying, in my case, to use) such compilers, which are not the most user-orientated I know...
<br>
<h4>Preprocess, Compile, Assemble and Link:</h4>
 When a normal compiler, including GCC, compiles source code, it does not immediately convert it into pure machine code. Far from it. There is a common sequence of stages for the compiler front end to perform before the final binary executable is reached. In GCC, each of these stages is handled by a different absolute file; if you run GCC to compile, say, <code>HelloW</code>, with v set, you'll see lines of various GCC copyright messages and lines beginning with the filename of one of the files in !GCC.bin, which are presumably the star commands the main <code>gcc</code> machine code file runs.
<br>
 First of all, the source code file is preprocessed. The result is still in the language in which the original code was written, but some elements may have been customised for the compiler; for example, this might include removing comments (so that the compiler does not have to worry about working around them) or expanding macros.
<br>
 After this comes the main task of the compiler: to convert the preprocessed source file into assembler. Note that, at this stage, it compiles into assembler, rather than actual machine code. Also, any links in the source file (calls to functions outside that source file, say in another source file or in one of the libraries) are still unresolved (i.e. recorded simply by function name, rather than by branch instruction), because all of the source files, including the libraries, are still seperate.
<br>
 These files of assembler are then assembled by the assembler into what are known as object files. These are basically machine code, except, as with the assembler files above, every time the machine code wants to call a procedure from another object file generated from another source file, it doesn't include the branch instruction, but simply the name. In the case of a single source file of C code, you are left with an object file of machine code, where every call to the ANSI C libraries is recorded as an unresolved link by name only.
<br>
 It is the task of the linker to take all the object files, including any standard libraries used, and join them into the final executable machine code file. Whenever the linker spots an unresolved link, it scans all of the other object files it is working on for the function definition that matches that name; when the corresponding machine code procedure definition is found, the linker formulates a branch instruction between the two. In this way, all unresolved links are thus resolved by the linker, to provide one final machine code file.
<p>
<h4>Why?</h4>
 This is a question I have pondered for a while. Why not just make the machine code all in one go? The answer is that having a final stage for the linker, which can be easily seperated from the rest of the compilation process, allows you to write one piece of software in many different languages, providing that each compiler for each language can produce object file output.
<br>
 If I wanted to, say, write a single-tasking game with a desktop interface, I could (for simplicity) write the Wimp interface on the icon bar in BASIC, (for speed) write the actual game code in C, (for hyper-speed) write the fast graphics plotting routines in ARM Assembler and (because I need another example) write the geometric look-up tables in Pascal. If my compilers and assemblers could generate object file output, I can call procedures from one language from another, safe in the knowledge that, when I link all of the output object files together, the different languages will join seemlessly. An object file isn't an ex-BASIC file; it isn't an ex-C file; it is simply some machine code with unresolved links, with has a common format of procedure calling (as documented in the PRMs).
<p>
<h4>RISC OS:</h4>
 The Acorn standard format of object file is AOF, Acorn Object Format. GCC compiles AOF files; Acorn's DDE compiles to AOF files; even the old now unsupported Acorn Pascal compiler performs AOF assembly.
<p>
  I hope that helped!
<p>
<body>
<html>