Introducing the "lookup-constants runtime system" :)

[Anoq of the Sun]

Stephen Weeks wrote:
> 
> > Why?  I like your option two (include the explicit path for #include
> > <stdio.h>).  That way, the normal lookup-constants method can be used.  It
> > seems like a minor change the current approach to include the target headers
> > (which I figure you must have) and then run lookup-constants on the host
> > system.  Combining that with calling the cross-compiling gcc and linking with
> > the right files seems to me to be all you need.
> 
> Henry doesn't like this approach and thinks that combining the two different
> sets of include files is too risky.

Yes - I'm not even sure it will work (and at least not for
crosscompiling in general). Because if /usr/include/stdio.h (or
whatever)
includes other files in brackets <>, they will be loaded from the
target include paths.

> So, I'd say go with the approach you
> mentioned of just including the target .h files and linking with a special
> lookup-constants library for the host.  BTW, as far as I understand, this still
> just requires a tweak of the current call to gcc from within lookup-constants,

Yes - I believe so too. But I'm making part of this "tweak" quite
elaborate with many possibilities open for configuring the bin/mlton
script to do lots of crosscompiling / bootstrapping.
Hopefully even general enough to quite easily allow for
crosscompiling to other platforms.

> and does not require the command-line switches to stop at the lookup-constants
> pass or to load the result of a separate lookup-constants run.

I have already implemented the option: -stop constprog
from my earlier attempt. Right now I intend to just
leave it there, since it was not a big change in the code - maybe
it will be useful?

And there is still a catch to compiling lookupconstants on the host -
the compiler is not the actual crosscompiler. And there are
a few special cross-compiler things in some of the include files.
What I have seen so far is:

#ifdef __MINGW__

and:

__MINGW_IMPORT char *var;

(or something like that). But I guess in this case it's
just a matter of emulating those defines for the crosscompiler.

But if some day we're going to do crosscompilation to an
entirely different system (e.g. a different 64bit CPU or
something) - things like sizeof() will not work correctly.
I'm not sure if it matters for crosscompiling the compiler
itself, but for a programmer crosscompiling with some
foreign library (like SDL), it might give problems for the
constants in that library accessed from MLton with _prim.


Cheers
-- 
http://www.HardcoreProcessing.com