[M3devel] INTEGER and LONGINT on 64-bit systems

[Tony Hosking]

On Aug 8, 2007, at 9:30 AM, Darko wrote:

> This might make sense as a platform option (ie where more than one  
> platform config is available), where 32 bit integer performance is  
> better, or you want to save memory. But INTEGERs are fairly  
> fundamental. For instance, you might actually legitimately want to  
> allocate an array bigger than 4Gb on a 64 bit machine, but NUMBER  
> wouldn't work on it.

On second thoughts....

Given how integer is intimately tied up with Word.T and many assume  
BITSIZE(INTEGER)=BITSIZE(ADDRESS) I think we probably want INTEGER  
left as it currently stands.

> Will a integer subrange of a 64 bit INTEGER get handled by the back  
> end as efficiently as a 'natively' defined 32 bit integer which is  
> logically defined as a subrange?

Currently subranges with LONGINT base have values represented as  
LONGINT.  A subrange of LONGINT can be used as an array index for an  
array, so long as NUMBER(array) is restricted, just as it is currently.

>
>
>
> On 08/08/2007, at 5:59 AM, Tony Hosking wrote:
>
>> Now I've checked in the LONGINT extensions, I am wondering if we  
>> shouldn't observe the following protocol for mapping INTEGER and  
>> LONGINT to C types.   Currently, we have the following:
>>
>>
>> 		32-bit targets			64-bit targets
>>
>> INTEGER		32 bits				64 bits
>> LONGINT		64 bits				64 bits
>> C long int	32 bits				32 bits
>> C long long     64 bits				64 bits
>>
>> I wonder if we shouldn't simply identify INTEGER as 32-bit and  
>> LONGINT as 64-bit on all targets.  That way, INTEGER=long int and  
>> LONGINT=long long.
>>
>> Comments?
>>