[M3devel] 32bit host 64bit target TextLiteral recurring problem

[Rodney M. Bates]

On 06/04/2015 09:01 AM, Elmar Stellnberger wrote:
> Am 03.06.15 um 03:58 schrieb Jay K:
>> We cannot cross from 32bit host to 64bit target.
>>
>>
>> Ok to commit this?
>>
>>
>
> Compatibility between the 32bit and the 64bit version of the same program would be the minimum I expected from a pickle.
> To me this is just another argument for a language specified value range of INTEGER.
> It makes certain things easier.
>
> My suggestion was:
> TYPE OFFSET = BITS BITSIZE(ADDRESS) FOR INTEGER; (and INTEGER = BITS 32 FOR INTEGER for 32 and 64bit targets)
> while also allowing BITS 16 FOR INTEGER (if that works for WIDECHAR I believe there is no reason to forbid it for INTEGER)
> BITS 64 FOR INTEGER would only work on x64 systems.
>

What you want is already pretty much here.  Just declare your desired type yourself:

TYPE Int32T = [-16_7FFFFFFF-1 .. 16_7FFFFFFF];

It will always have this range and occupy 32 bits, regardless of the native word size.  Pickles
will always save and reread it with exactly this range, even between machines of different
word size.

The only thing that will differ from 32- to 64-bit machine is the size of intermediate results in
expressions.  If you are already _not_ being careful about avoiding overflows, there are probably
cases where the results of silent overflows would differ with machine word size.  Not sure what
you would really want here.  The unsigned arithmetic operations in Word are explicitly defined
to silently do binary twos-complement wrap-around when overflows happen.  The language does not
define this for the builtin signed operators.  In code where I care about overflows, I never assume
this.  It is probably machine-dependent.

Or, you can import it: Int32.T. is already declared, in m3core, with this range.

However, Int32.T specifies BITS 32 FOR ...  I strongly suggest this is almost never what you really want.
The only place the BITS specification makes any difference is when you declare a record or object
field of this type.  In all other situations, BITS 32 FOR .. has _no effect_.  The only purpose of
BITS is so you can force the layout of a record.  In that case, since the range needs exactly 32
bits anyway, even if you omit the BITS, a field of this type will still always occupy 32 bits.

But, with the BITS specification, the compiler is not allowed to insert alignment padding, (if it
were, you could not fully specify the layout) and if the field comes at a place that is not 32-bit
aligned, you will either get a compile-time error or maybe a compiler will accept it and handle
unaligned field access (it is not required to--ours does not), neither of which is probably what
you want.  Without BITS, the compiler will pad as needed.  With BITS, you will have to insert explicit
padding for alignment yourself as needed, which can be different for every field of this type of every
record/object.  And later adding/removing/changing any prior field can upset it and require you to
rework the padding.  Moreover, I am sure there are simple cases where the required padding differs
between 32-bit and 64-bit machines.

Having been bitten by this more than once, I now only put BITS..FOR as the anonymous type of a specific
field, never in a named type to be used in multiple places.

(Actually, BITS does the same thing when used as the type of an array element, but cases where this
matters are rare.  If the bit count evenly divides the word size, there won't be any alignment padding
needed, and BITS won't matter.  Otherwise, the compiler is likely to refuse, unless the entire array
fits in a single machine word.  I do have a couple of such cases.)

> The value range - bitsize correlation problem could be solved easily by automatically extending and reducing the value
> range of an integer type to what its binary representation allows as long as no explicit range has ever been specified for
> any of its supertypes (i.e. BITS 16 FOR INTEGER = BITS 16 FOR [-32768..+32767]).
>
> Finally it needs to be said that the argument that target size arithmetics is always the fastest which was often used in
> here can be very wrong. It does not hold for the 64bit systems of today because the CPU is no more the bottleneck. In
> a fact now the memory hierarchy has become the new bottleneck (which means that using more memory for the same
> tends to be much slower).
>
> Regards,
> Elmar
>

-- 
Rodney Bates
rodney.m.bates at acm.org