I think he means that int and pointer address must be interchangeable. As long as that holds, the size can be either 16 bits or 32 bits.
On a PDP-11 int would have been 16-bit. On x86 32 bits. But on x86_64 int is 32 bits but pointers are 64-bit. The easiest way to retain the original assumption with minimal changes to the historical source code while targeting a modern CPU is to compile in 32-bit mode.
My original comment was rather tongue in cheek - but I have actually ported this compiler (well a later version of it, from the v6 release) to a 32-bit target - it was a different time, and C was a different, definitely more forgiving and simpler language - with other systems languages like BCPL/Bliss/etc around at the time the whole 'int is the same as a pointer' was definitely a way of thinking about stuff at the time
Why can't it be 64-bit? I don't see any reason why we can't have an ILP64 data model. If int and int* were both 64-bit then it would restore so much of the original beauty of C.
It can be, and is, on platforms where supporting large arrays (if integers are 32 bits, arrays can ‘only’ have 2³¹ entries (#)) is deemed more important than memory usage.
Oh that's an Intel math kernel library. They probably just arbitrarily chose a 32-bit type in one of their FORTRAN interfaces. The x86_64 architecture itself, is pretty much word size agnostic. Arrays can be indexed using a 64-bit index, for example: mov (%rax,%rbx,8),%rcx where %rbx is the 64-bit word index. The only caveat with the instruction encoding is that fixed-size displacements can't be more than 32-bits. So for example, you can access the second 64-bit word in the array as mov 8(%rax),%rcx but you can't say mov 0x1000000000(%rax),%rcx. You'd instead have to load 0x1000000000/8 into %rbx and use the first op. This poses headaches for programs that compile to 3gb executables, since unlike arrays, code is usually referenced using displacement notation, but workarounds exist and it's still fine. All that stuff is abstracted by the compiler.
It can be, but people have arranged for it to not be, presumably because they don't feel the storage space to have all integers be 8-bytes is not justified.
Yes, and on 16-bit and 32-bit systems, sizeof(int) == sizeof(int*). On 64-bit systems, this is most probably not the case. This is a common roadblock when porting old C programs.
