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