[M3devel] cm3 regression

[Tony Hosking]

I think Modula-3 has it exactly right in that the base types INTEGER  
and Word.T use the natural word size of the machine, and that there  
are no guarantees about BITSIZE on those.  If you want a specific bit  
size you use BITS FOR or simply a subrange type, both of which pack  
down in memory to just the number of bytes needed.  C is generally a  
mess since you have both LLP64 (Windows) and LP64 (everyone else, for  
good reason -- see http://www.unix.org/version2/whatsnew/ 
lp64_wp.html).  In any case, yes, I expect there will need to be a  
fork of BasicCTypes along the lines of ILP32, LP64, and LLP64.   
Currently, we have the strangeness that NT386 = ILP32/LL32 (because  
the integrated backend can't grok LL64), but this is an anomaly.   
Ideally, this would go to LLP64 (IL32) to match the Win64 world.   
Remember, this is only for *C types*.  On all 64-bit platforms, we  
should aim for 64-bit INTEGER and 64-bit Word.T as the native Modula-3  
types.  How C types fall out depends on the native C expectations of  
the platform, and really are just about interfacing to C APIs.

On Apr 14, 2008, at 1:18 PM, Mika Nystrom wrote:

> Jay writes:
>> --_50e47a65-f79d-472b-8eaf-fbcc30b6410e_
>> Content-Type: text/plain; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>>
>> new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3",  
>> line 18=
>> : illegal based LONGINT literal, zero used"..\src\C\32BITS 
>> \BasicCtypes.i3",=
>> line 18: illegal based LONGINT literal, zero used
>> long_long          =3D [-16_7fffffffffffffffL-1L ..  
>> 16_7fffffffffffffffL]=
>> ;
>> =20
>> Why isn't this LONGINT? So that NT386 can limp along? And it'd be  
>> correct f=
>> or the rest, eh?
>> I'll try it and see..
>> =20
>> The underlying system (the compiler) has (U)Int[8,16,32,64]
>> They should just be used here imho..
>> =20
>> Also, what should "long" be on 64bit?
>> On Windows it is 32 bits always.
>> On 32 bit systems it is 32 bits.
>> I think the 64bits directory is going to be forked for AMD64_NT_*.
>> The Windows decision imho has successfully been applied to more  
>> code and mo=
>> re users so therefore is better by practical success, even if the  
>> whole iss=
>> ue is problematic almost no matter what. Clearly the C and Modula-3  
>> notions=
>> of integers are pretty poor..
>
> I have to re-code my program to use Int64 if I want it to use the
> natural INTEGER size on 64 bit machines?  No thanks.