[m-dev.] 32-bit sources on 64-bit target

[Paul Bone]

On Thu, Mar 07, 2013 at 03:15:56PM +1100, Julien Fischer wrote:
> Hi Peter,
> 
> On Thu, Mar 7, 2013 at 12:17 PM, Peter Wang <novalazy at gmail.com> wrote:
> 
> > I think I can fix the first by allocating two words to a `float'
> > constructor argument whenever --no-unboxed-float is used, even when it
> > is unnecessary on 64-bit.
> >
> > The second, I'm guessing, does not actually occur in the standard
> > library.  A solution would be to restrict enum packing to using at
> > most 32 bits of a word, with an option like --max-arg-packing-bits=32.
> 
> I think we already have an option that is appropriate here, --cross-compiling.
> You just need to make it do the above.  The only catch I can think of is
> that when I reconfigure the source distribution on my build machine, then you
> need to make sure that settings like --max-arg-packing-bits end up being
> consistent with the pre-generated C files.
> 
> ...
> 
> > PS. I'd still like to see generated C sources for 64-bit...
> 
> That should just be a matter of:
> 
>         mercury_cv_low_tag_bits=3 \
>         mercury_cv_bits_per_word=64 \
>         mercury_cv_unboxed_floats=yes \
> 
> And indeed if you change the grade to hlc.gc you will get a source
> distribution whose C files are
> high-level C code.
> 
> Is it worth having multiple versions of the source distribution or is
> it just going to be confusing though?

No, we already have a problem with the amount of effort one must go through
to get Mercury installed.  Even a trivial decision such as "do I have a
32bit or 64bit system?" adds complication that can be avoided if we just do
a little more work with the build system.  Secondly, this makes creating
packages for distros more difficult.  Basically this implementation detail
should be abstracted over at the correct level (build system).

I prefer Peter's proposal of making the compiler bootstrap itself (by
default?) as this is what we recommend people do anyway.  There are several
other improvements that are also necessary such as removing any compilation
steps from the 'make install' target.


-- 
Paul Bone
http://www.bone.id.au