[m-dev.] Additional config tests

Fergus Henderson fjh at cs.mu.oz.au
Sat Mar 29 03:49:59 AEDT 1997


Bert Thompson, you wrote:
> 
> Quick summary:
> 	- We do need the -fixed- format constants in the bytecode file
> 	  for portability. (Call them Int64 and Float64.)
> 	- We -must- represent Float64 as `double' (or some primitive
> 	  64-bit float) since the alternative is to emulate some
> 	  IEEE-754 operations in software.

Agreed.  Well, the operations you need are just conversion
from `Float' (as defined in runtime/mercury_float.h) to
`Float64' (big-endian 64-bit IEEE float) and back.
But these are difficult to implement, so for the moment implementing
them as `#error' for the case where there is no C type that we can use for
Float64 is fine.

> 	- We could represent Int64 as either:
> 		- `long long' (or some other primitive 64-bit integral type)
> 		  Pros: Fast, simple
> 		  Cons: Maybe not portable. (Works on all platforms we
> 			currently support, however.) Is ANSI?
> 		or
> 		- array of eight bytes.
> 		  Pros: Portable.
> 		  Cons: Slower, messier.

Efficiency should not be an issue, since the conversion should happen
only at load time.  Messyness should also not be much of an issue,
since you should convert from Mercury `int' (i.e. C `Integer') to Int64
only as you write out the bytecode file (that's already done -- it is a
single spot in bytecode_gen.m), and you should convert from `Int64'
back to `Integer' as soon as you read in the bytecode file (and that
should be done in a single spot too).  There is thus no need to
actually have an explicit representation of `Int64' -- just convert
straight to `Integer'.

> |This will not be difficult, it is just the
> |inverse of what happens in bytecode_gen.m.  So I don't see any need
> |for an integer type with _exactly_ 64 bits.  
> 
> The reason for -exactly- 64-bits is this: we need a portable -fixed-
> format for Mercury `int' constants in the bytecode file. We also
> want a C representation of this 64-bit type to facilitate reading,
> writing and converting these Int64s to and from Mercury `int's. 

Why?  Why not convert straight to `Integer'?

Anyway, even if you did want to use Int64, you still only need a type
that is at least 64 bits, not exactly 64 bits.

> |>|>+ #undef	LONG_LONG_IS_64_BITS
> |>|>+ #undef	DOUBLE_IS_64_BITS
> |>|>+ #undef	SHORT_IS_16_BITS
> |>|>  
> |>|>  #endif /* CONF_H */
> |>
> |>|These macros should be documented.
> |>
> |>They do exactly what they say. LONG_LONG_IS_64_BITS is defined in
> |>exactly the case that `long long' is 64 bits.
> 
> |The case that `long long' is exactly 64 bits, or the
> |case that `long long' is at least 64 bits?
> 
> Exactly 64 bits.

OK, please document that in the header file.

> |Also, I think it would be helpful if you document which part of the
> |Mercury system uses them.
> 
> This is used only by the bytecode components of the compiler.
> Most of it will be in the C code I'm writing. A little will be
> in some pragma C in bytecode.m.
> 
> I'll document this better in a revised log message.

Please document it in the source file too.

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