James Wilkinson wrote:
Incidentally, I understand that it isn't the 64 bit wide registers that are the big performance enhancement in AMD64: it's the extra registers. Most programs (at the moment) don't need 64 bits. But 64 bit mode makes binaries larger, which means you can get less code into a fixed-size cache, slightly slowing things down.
On AMD64, the other benefits (especially the extra registers) outweigh this (so 64 bit mode is still faster). On RISC chips with a clean 32 bit mode, commercial Unix has often stuck to a 32 bit userland.
The above two paragraphs depend on sizeof(int). I don't have any AMD64 around to test, but my guess is sizeof(int) is 8 on it?
If the above is correct, than you are right. The code will get larger when everything goes double, where it really doesn't need to.
However, if the aproach was the same as in OSF/1 (alias Digital Unix, alias Tru64) for Alpha processors and OpenBSD for 64-bit processors (well, at least those I tried) things are different. On mentioned operating systems, sizeof(int) is 4, sizeof(long) is 8, and sizes of pointers and typedefs such as size_t, off_t and similar is bumped to 8 (OSF/1 time_t is also 8 bytes long). Basically, you are using double the memory only for storing data types that acutally benefit from being 64-bit long. Basically, that way you enable all programs access to large address space and correct handling of large files (even if the program itself was not written to support them by use of open64() and related system calls).
Of course, than you have small problems with that common programming error (assumption that sizeof(int) == sizeof(void *), which is plain wrong). Assigning 64-bit pointer to 32-bit int doesn't really work... However, Alpha processors have been around for long enough for that kind of bugs to be corrected in most of the open source. Speaking of that, I was compiling Linux kernel couple of minutes ago, and noticed bunch of "assigment makes pointer from int" (or the other way around?) warnings. Seems that Linux kernel is not free from those kinds of (basic) programming mistakes ;-)
-- Aleksandar Milivojevic <amilivojevic@xxxxxx> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
