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

[Peter Wang]

On Thu, 7 Mar 2013 15:15:56 +1100, Julien Fischer <jfischer at opturion.com> 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.

This is tricky for static data...

> >
> > 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.
> 

AFAIK --cross-compiling currently just prevents some compile-time
evaluation, but doesn't cause data representation changes.
I don't think it should do.

> 
> > 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

Yes.

> it just going to be confusing though?

I think it will be obvious if one is labelled 32-bit, the other 64-bit.

Peter