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

[Elmar Stellnberger]

Antony, you do not seem to understand what I have proposed.
Please have a look at my latest mail about

Re: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or 
configuration/target dependent?


Am 04.06.15 um 19:14 schrieb Antony Hosking:
>
>> On Jun 4, 2015, at 10:01 AM, Elmar Stellnberger <estellnb at elstel.org 
>> <mailto:estellnb at elstel.org>> 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.
>
> You are still misunderstanding the purpose of BITS FOR.  It is used to 
> express packing requirements for use of those types *inside* 
> structured values (such as RECORD or ARRAY) to enforce a particular 
> bit-packing and to avoid alignment contraints.  What it means is that 
> bit-wise operations must be used to load/store the value in memory in 
> the case that aligned operations do not suffice.
>
>>
>> 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]).
>
> A value of type [-32768..+32767] *never* occupies more than 16 bits in 
> memory!
>
>> 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).
>
> Operating on 16-bit values using natural word-size operations (32 bit 
> or 64 bit) is never more expensive.  And the memory is only ever 
> 16-bit. So your performance argument does not stand.
>
> I hope this clarifies your understanding of the Modula-3 type system.
>
>>
>> Regards,
>> Elmar
>>
>>> Can't do this.  Non-open arrays must have static constant bounds,
>>> which the above does not.  Open arrays have extra dope and are accessed
>>> through two extra pointers, which we really wouldn't want for text 
>>> literals.
>>>
>>> TextLiteral.Ts are unsafe only in UNSAFE code, which is no worse 
>>> that anything
>>> else in UNSAFE code.  The interface is UNSAFE, which means safe code 
>>> can't IMPORT
>>> it, and thus can't see the declaration.  Not very likely that 
>>> anybody other than
>>> the runtime, compiler-generated code, and debugger (written in C 
>>> anyway) would
>>> want to mess with it.
>>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150605/a2b57d3b/attachment-0002.html>