[M3devel] LONGINT

[Darko]

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