Lints, Condate and bugs

[retard]

Wed, 03 Nov 2010 12:48:59 +0100, Daniel Gibson wrote:

> Kagamin schrieb:
>> Who knows, how large arrays can get even on 32bit target?
> 
> Probably not longer than 2^32 elements (minus a few for the rest of the
> program) because more couldn't be addressed.

Having the whole 32-bit address space available is a bit unrealistic on 
32-bit targets if they have a modern operating system. The user processes 
may only have 3 GB available if a 3/1 division is used even if on x86 the 
36-bit PAE is in use. Even then the whole 3 GB isn't available for a 
single array because all kinds of other data must reside in the same 
address space. This mean that the maximum realistic length of an array of 
bytes is closer to 2^31 and with an array of shorts it's closer to 2^30. 
Array of ints (most typical data size?) could only grow to a bit over 
2^29.

This is just from a application programmer's point of view. Sure, if 
you're building your own operating system, having unsigned length fields 
might have some merit. In practice, if I need to deal with arrays with 
billions of elements, I'd use a 64-bit operating system in any case. Then 
having a signed length isn't a bad tradeoff because the physical 
architecture doesn't even have buses that wide. From the wikipedia:

"The original implementation of the AMD64 architecture implemented 40-bit 
physical addresses and so could address up to 1 TB of RAM. Current 
implementations of the AMD64 architecture extend this to 48-bit physical 
addresses and therefore can address up to 256 TB of RAM. The architecture 
permits extending this to 52 bits in the future (limited by the page 
table entry format); this would allow addressing of up to 4 PB of RAM. 
For comparison, x86 processors are limited to 64 GB of RAM in Physical 
Address Extension (PAE) mode, or 4 GB of RAM without PAE mode."

http://en.wikipedia.org/wiki/X86-64