On Oct 12, 2007, at = 09:17, Christoph Sieghart wrote:

Is there any documentation for = adding a new architecture to ocamlopt? I would=A0like to do a = crosscompiler from one of the existing architectures to an=A0embedded = microcontroller.

I have searched the mailinglist = archives and the documenation, but have not=A0
Yes, asmcomp = contains both the middle-end and the back-end code generators. Note that = the architecture-specific features are injected by configure creating = various symlinks of the form asmcomp/<foo>.ml -> = asmcomp/<arch>/<foo>.ml. On one hand,=A0this means you = should be able to clone the contents of one of the asmcomp/<arch> = subdirectories and get your project off to a start pretty quickly. On = the other,=A0ocamlopt is not a cross-compiler, so you may have a bit of = a challenge just getting the paths to the cross tools into the right = places without breaking ocamlc.

I'm sure you'll get = more detailed pointers, but here's a quick = overview...

ocamlc and ocamlopt share = code through the "Lambda" representation (bytecomp/lambda.mli). After = this point, ocamlopt transfers control into asmcomp/asmgen.ml, which has = a fairly straightforward pass pipeline in = Asmgen.compile_implementation.

The Lambda representation = is first translated into Closed Lambda (asmcomp/clambda.mli), which is = similar except that closures are explicit.

Next, ocamlopt transforms = Clambda into its middle-end representation, C--. This form=A0is somewhat = well documented at http://cminusminus.org/ and in = various academic papers. The C-- representation is=A0architecture-neutral = in form, but not content. Target dependencies are injected through the = Arch module, which specifies address sizes, endianness, etc. This is the = point where displacement calculations are performed, etc.

The C-- representation is = the input to the=A0architecture-specific back-end code generators, which = are driven by the=A0architecture-neutral Asmgen.compile_phrase and = Asmgen.compile_fundecl. In particular, this pipeline is pleasantly = self-documenting:

let (++) x f =3D f = x

let = compile_fundecl (ppf : formatter) fd_cmm = =3D
=A0=A0Reg.reset();
=A0=A0fd_cmm (* <-- The = C-- representation for the function *)
=A0=A0++ = Selection.fundecl
=A0=A0++ pass_dump_if ppf dump_selection = "After instruction selection"
=A0=A0++ = Comballoc.fundecl
=A0=A0++ pass_dump_if ppf dump_combine = "After allocation combining"
=A0=A0++ liveness = ppf
=A0=A0++ pass_dump_if ppf dump_live "Liveness = analysis"
=A0=A0++ Spill.fundecl
=A0=A0++ liveness = ppf
=A0=A0++ pass_dump_if ppf dump_spill "After = spilling"
=A0=A0++ Split.fundecl
=A0=A0++ = pass_dump_if ppf dump_split "After live range splitting"
=A0=A0+= + liveness ppf
=A0=A0++ regalloc ppf 1
=A0=A0++ = Linearize.fundecl
=A0=A0++ pass_dump_linear_if ppf dump_linear = "Linearized code"
=A0=A0++ Scheduling.fundecl
=A0=A0++= pass_dump_linear_if ppf dump_scheduling "After instruction = scheduling"
=A0=A0++ Emit.fundecl

You can identify the = target-dependent phases by correlating the passes with the contents of a = target subdirectory. =A0Have fun!

=97 Gordon
=

= --Apple-Mail-12--862455957--