[m-dev.] [for review] Changes to config and bytecode (again!)
Fergus Henderson
fjh at cs.mu.oz.au
Sat Apr 12 19:45:07 AEST 1997
Bert Thompson, you wrote:
>
> + AC_MSG_CHECKING(whether architecture is big-endian)
> + AC_CACHE_VAL(mercury_is_bigender,
Autoconf variable names must start with `mercury_cv_'.
This is an autoconf restriction.
(`cv' stands for "configuration variable".)
> + /*
> + ** Spit out an `int' in a portable `highest common denominator' format.
> + ** This format is: big-endian, 64-bit, 2's-complement int.
> + **
> + ** NOTE: We -assume- the mahcine architecture uses 2's-complement.
Fix typo.
> output_int(Val) -->
> ! globals__io_lookup_int_option(bytes_per_word, IntBytes),
You should avoid using the `bytes_per_word' option here. When
cross-compiling, that option holds the bytes per word of the _target_
system. Here what you are really interested in is the bytes per int
for the host system. You should use `int__bits_per_int' instead.
Also, it should be very easy to generalize this code to handle
any size of integer, so you should do so. One day we will want
to compile on machines for which int is 16 or 128 bits.
> ! Float64 float64;
> ! unsigned char *raw_mem_p;
> !
> ! float64 = (Float64) FloatVal;
Do you need this cast? Why?
> ! raw_mem_p = (unsigned char*) &float64;
> !
> ! #if defined(BIG_ENDIAN)
> ! B0 = *(raw_mem_p+0);
`B0 = raw_mem_p[0]' would be clearer.
> + #undef DOUBLE_IS_64_BITS
> + #undef BIG_ENDIAN
> + #undef LITTLE_ENDIAN
You should document these macros.
> + /*
> + ** Float64 is required for the bytecode.
> + */
> +
> + #if DOUBLE_IS_64_BITS
> + typedef double Float64;
> + #else
> + #error For Mercury bytecode, we require double to be 64-bit IEEE-754.
> + #endif
You should try `float' and `long double' too, I think.
Or does IEE-754 require that the C `double' type is the 64-bit one?
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3 | -- the last words of T. S. Garp.
More information about the developers
mailing list