[M3devel] LONGINT

[Tony Hosking]

I allow LONGINT indexed arrays, so long as the element offset can be  
computed as an integer.  The size restriction on arrays remains.   
NUMBER always returns a CARDINAL.  Thus, NUMBER(LONGINT) gives a  
range violation, just as NUMBER(INTEGER) currently does.  However,  
NUMBER([10L .. 20L]) = NUMBER([10..20]) = 11.

On Jul 19, 2007, at 6:02 PM, Darko wrote:

> I think in 64 bit land you get a variety of combinations and  
> possibly the most common is a 32 bit address space with 64 bit  
> integers, since applications seldom need to operate in the larger  
> address space. But I would think it you wouldn't allocate an object  
> bigger than 2^32 bytes anyway, and unsafe pointer arithmetic would  
> be more likely.
>
> The only situation where I can think of where this is an issue is  
> using a long integer index in an array of integer proportions, you  
> could handle this using arithmetic, also illustrates where you'd  
> need an implicit conversion:
>
> CONST
> 	start = 2^63-500;
> 	end = 2^63-200;
> VAR
> 	a: ARRAY[0..start-end+1] OF CHAR;
> BEGIN
> 	FOR i := start TO end DO a[INT(i-start)] := 'x' END;
>
>
> Or you could rule that all arrays are of INTEGER size, but may have  
> a LONGINT index. Open arrays would always be integers. This would  
> probably be messy to implement and NUMBER would have a different  
> base to FIRST and LAST. That doesn't sound very good.
>
>
>
> On 19/07/2007, at 11:33 PM, Rodney M. Bates wrote:
>
>>
>>
>> Randy Coleburn wrote:
>>> Tony:
>>>  I'd like to better understand the implications of your change as  
>>> I do use LONGINT as an index in some applications.
>>
>> Do you have arrays that need 64-bit subscripts on a 32-bit machine?
>>
>> Allow me the common assumption that both integers and addresses have
>> the native word size on most machines.  In this case, most arrays  
>> that
>> need 64-bit subscripts would exceed the virtual address space of the
>> machine.  Exceptions would require elements of size at most a byte,
>> and overall sizes in excess of half the virtual address space. Even
>> PACKED ARRAY [..] OF BITS 1 FOR BOOLEAN would need to use 1/8 the
>> virtual space before 32-bit subscripts ran out.  All this seems  
>> pretty
>> unlikely.
>>
>> I would favor keeping INTEGER as the type of open array subscripts
>> and not allowing LONGINT to be a fixed array subscript type.  It
>> saves a whole lot of language complexity, and doesn't disallow much.
>>
>> If it really mattered, you could still use unsafe techniques for
>> such memory-hogging arrays.  This might be a reason to extend unsafe
>> arithmetic on ADDRESS to accept LONGINT second operands.  This is
>> actually consistent with the rest of the operator generalizations.
>>>
>>
>> -- 
>> -------------------------------------------------------------
>> Rodney M. Bates, retired assistant professor
>> Dept. of Computer Science, Wichita State University
>> Wichita, KS 67260-0083
>> 316-978-3922
>> rodney.bates at wichita.edu