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

[Rodney M. Bates]

On 05/28/2015 02:53 PM, Elmar Stellnberger wrote:
>
> How for the hell do you interface with operating system services requiring a 32bit int when you only have the 64bit INTEGER??
>

Use subranges.  Just declare its type [-16_7fffffff-1 .. 16_7fffffff].  Our compiler
will allocate nice round bit sizes for everything that isn't BITS n FOR ... .  And
if it is BITS ..., just use the same subrange type, as above, then use
BITS 32 FOR ... . But remember BITS has no effect except when it's an array
element or record/object field.  It's the subrange, not the BITS spec that determines the range.

The language reference doesn't constrain the allocated size, but I'm skeptical about
adding things like that to the language.  Interfacing with another language is
low-level programming, and specifying all the things in that category would be
huge and overconstrain the language.

Well, maybe not stack variables, if the stack has a bigger alignment to be honored,
quite possibly a hardware requirement.  No doubt taking and using the address of
such would be endian-dependent.  Would a C compiler do  differently in this case?
Can you rely on them all doing it the same?  Does C specify it?


> Am 28.05.15 um 19:46 schrieb Elmar Stellnberger:
>> Am 28.05.15 um 04:03 schrieb Antony Hosking:
>>> BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing.
>>>
>> on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit
>>
>> I have just noticed that and when taking a practical standpoint - i.e. what really matters to new and old programs -
>> this is a really bad decision which I wish to change for the next release.
>>
>> If you have not examined it yet please reclaim the design decisions for leaving int 32bit in C:
>> /However things turned out to be very different when the extension from
>> 32bit to 64bit was at stake. There was no more gain by automatically
>> extending the value ranges from 2^32  to 2^64  for 95% of all application
>> purposes while the memory hierarchy has increasingly become a bottle
>> neck in recent time. Additionally doubling the size of all integers would
>> initially have doubled our memory needs which would have been a
>> potential drawback for introducing the AMD64 arch. Just think of a machine
>> with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while
>> making all INTS 64bit would have shrunken our memory to an effective size
>> of 2GB. Luckily the decision was taken differently this time:
>>
>> * keep all ints of at most 32bit and just extend pointers to 64bit
>> /
>>  Same reasoning applies to Modula-3. - and I believe you have failed to notice when
>> making your decisions for cm3 5.8.6. Or do you want to tell me that Modula-3
>> developers are more prudent than the C/C++ community?
>>
>>   Even worse I have discovered the following:
>> BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3 5.8.6:
>>
>> :: BITS FOR size too small, must be at least (64)
>>
>> That will break existing legacy code when trying to compile it with cm3 5.8.6.
>

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