The ML object format has to satisfy several distinct requirements.

1. It must be a repository for the run time executable, to be loaded
by the run time loader during the execution of the the program of
which it is a part.

2. It must be a repository for the environment resulting from the
compilation of this object, including unique identifiers of the
environments invoked during the compilation of this object. This is to
ensure that compilation of a file including some other file by more
than one route obtains a consistent copy thereof if required (note
that it may not be required, the semantics of ML allow either).

3. It must contain all information required by a debugger to allow
debugging of the separately loaded target, as opposed to debugging
within the interpreter environment.

The production of unique identifiers for ml object files is a problem.
An obvious starting point is the time stamp of the compilation. This
fails because the unix time stamping is of too coarse a grain to
distinguish files. We would also like to be able to determine if a
compiled object is the result of compilation of its corresponding
source object, rather than some other version of the same. Hence we at
least need to embed the time stamp of the source within the contents
of the object. Consider the following scenario. User A produces file
one on day one, and compiles it on day 3. Meanwhile user B produces
his own version of file one from the original on day two but doesn't
install it until day four. User A loads his system on day 3, and is
currently happy. He then attempts to reload on day 5, and is told not
only that he needs to reload file one, but also that the object he has
for file one is out of date with respect to the source, even though
the object appears newer than the source. This problem cannot be
solved as is by make, which will never determine that the object is
out of date with respect to the newer source. This may mean that
objects should be stamped with the same time as their corresponding
sources, this however makes it difficult to determine if an object is
out of date with respect to one of its dependents. Aaaaargghhhhhh!
Perhaps the answer is that for systems using unix make we must outlaw
behaviour which causes objects to appear to be up to date with respect
to their sources even though they are not. Forcing all objects to
migrate from the local user to the team only via RCS would solve this
problem, provided objects checked out of RCS are given the RCS file
last modified time. This is of course equally ghastly in the case
where one checks all one's source in having ensured everything is up
to date, only to find everything gets recompiled when it's all checked
out again. Aaaarrrgggggh! So what is a sensible model?

It must have the following properties.:-
1. Make must be able to determine which files need recompilation.
2. Updating a source file, even with an old version from RCS, must
cause recompilation of anything dependent on that.
3. The ML loader must be able to determine the consistency information
necessary to ensure that a module depending on other module by more
than one route always references the same item.
4. If the ML loader detects an inconsistency that make is unable to
resolve, it should be able to determine which objects files to delete
in order to cause make to be able to resolve this conflict. It should
also be the case that this situation should not happen provided people
follow the rules, whatever they may be.

The RCS effects seem to be as follows:-
1. When a file is checked in, or checked out locked, the time on the
RCS file is updated to reflect the current time.

2. Checking out a file unlocked does not alter the time stamp on the
RCS file, but all checkouts set the time stamp of the checked out
object to be the time of checkout.

3. Internally the RCS file contains the check in time of each version,
and this can be used by make (can it?).

4. The effect therefore of running a make -u (to leave all the checked
out objects) will be to leave a system which is up to date but may
appear out of date. This needs to be avoided.

5. If we use make externally for separate compilation, then we must
also understand it within the compiler itself, even if this is
achieved by forking make.

6. Making a system and then checking in all the source will leave a
system which is also apparently out of date.

   Actual contents of an object file.

It is assumed that the only form of endian-ness we will have to deal
with is word (4 byte) endian-ness. This may cause problems with
extended length floating point formats, but then this is target
specific anyway. Thus the word order within a multi word value will be
as for the target, but the byte order within each word will be as for
the producer. Machine instructions which are less than a word will be
produced as if part of strings, in the endian-ness of the target. This
will be the job of the code generator. In the case of cross
compilation involving a change of endian-ness, the code generator must
therefore handle this itself. For the case of a multi-endian target
such as MIPS, the code generator will need to be told which sort of
memory architecture it is generating for.

We may wish to wrap this in an a.out in order to allow unix systems to
recognise the file as not being text. We may also wish to make
archives of these files.

Word 1 A magic number uniquely identifying the file as an ML object
file and bytewise non-symmetric in order to enable endianness mismatch
to be detected (it is hoped that the loader will be capable of reading
either endian data, and the translators be capable of producing either
endian data (this one not so important)).

Word 2 A version number, to allow for future revisions.

Word 3 The number of bytes of loadable code (in its relevant byte code)
within this file.

Word 4 The number of bytes of ML environment code (as required when using
this file as a result of a require statement when compiling something
else, or when interactively loading this file within a running ML
system) within this file.

Word 5 The number of bytes of additional information available for a
debugger.

Word 6 The number of bytes of module consistency information.

Word 7-10 Offsets from the start of the file of the above sections.

Words 11-end the loadable code, the environment, the debug information,
consistency information.

Within the above, all word sized objects must be word aligned, and
will exist in the endianness of the translation system.

The loadable code consists of a sequence of byte and word values, as
specified in the document "loading".
