Reasonable C types sizes assumption

[Love4Boobies]

(u)int_fastN_t and (u)int_leastN_t are mandatory. uintN_t is mandatory only if the implementation provides an unsigned type of exactly N bits, and intN_t only if the implementation provides a 2s complement signed type of exactly N bits;

Right. Also, that type must not have padding bits. I didn't consider listing the details relevant to the discussion.

while the fastN and leastN types are always required

Yeah, my bad. It's more difficult to check references when using a phone. But I should have thought about it; such a restriction would be meaningless.

ANSI adopted C11 when ISO did. ANSI C *is* C89; the first ISO C standard was C90.

Exactly. People generally mean the organization of which the C committee was part of. However, it can be ambiguous---it's equally understandable to mean the organization which adopted the standard. The OP did just that.

[turdus]

I mean that the 64-bit size appears to be "less" native here because of immediate sizes in opcodes and the need of REX prefix when using 64-bit features. It seems the processor likes to behave like a 32-bit one unless a user deliberately wants it to be 64-bit.

That's not true. Yes, immediate are 32 bit without rex, but they are signed extended to 64 bit and used as such in arithmetic and addressing. It's just a way to shrink code size taking advantage of locality (a compression method if you like). Stack item size also 64 bit. All registers are 64 bit. All pointers in cpu specific data (in IDT for example) are 64 bit. Even if the arch implements only 48/56 bit memory bus size (not 64), it's whole memory cannot be addressed with 32 bit, you'll need qwords for that (in contrast to i386 PAE, which is truly 32 bit).
Because of these, we can say that the native word size on x86_64 _is_ 64 bit, and not 32. IMHO.

[Love4Boobies]

I avoided getting into that discussion because the terminology is vague to begin with. Saying that an OS or a CPU is 32-bit or 64-bit is mostly marketing and has little technical meaning; people have to be explicit when they actually need to talk about something in particular. (What makes a word size more native than another? Do you prefer to talk about the address space? Which one?)

[turdus]

I avoided getting into that discussion because the terminology is vague to begin with. Saying that an OS or a CPU is 32-bit or 64-bit is mostly marketing and has little technical meaning; people have to be explicit when they actually need to talk about something in particular. (What makes a word size more native than another? Do you prefer to talk about the address space? Which one?)

You are right, people must be explicit.
By "native word size" I mean the number of bits used in registers (maybe "native" is not the best word to use, I meant a hardwired property of the cpu by that). So it has technical meaning to me, not just marketing bullshit.
This word size equals to virtual memory pointer size, but does not necessairly equal to memory bus size. x86_64 allows different bus sizes from 48 to 56 bits, so it's not a good idea to use that varying value for an indicator at all...

On the other hand, it's misleading to call it 32 bit, because it would not reflect the arithemtic capabilities (which work on a considerably bigger interval of numbers than real 32 bit cpu would), and virtual memory space (also considerably bigger than 4G). There's a need to distinguish.

[Love4Boobies]

By "native word size" I mean the number of bits used in registers (maybe "native" is not the best word to use, I meant a hardwired property of the cpu by that). So it has technical meaning to me, not just marketing bullshit.

So that makes the x87 80-bit? What happens when you have different register sizes? In x86, the biggest registers aren't 64-bit.

This word size equals to virtual memory pointer size, but does not necessairly equal to memory bus size.

But above you gave a different definition for it. It's not true for all CPU's that registers and the address space are represented with the same number of bits. Furthermore, you may have different address spaces for code and data, of different sizes (quite common in the embedded world). Which one do you count?

[Antti]

[...]

[...]

I wrote a little bit ambiguously when I mentioned 64-bit is "less" native. That was after this line:

I do not think that x86-64 is so 64-bit than 80386 is 32-bit

As far as the x86-64 architecture is concerned, the 64-bit is far more native size than 32-bit. That goes without saying.

The point was that the 32-bit size has bigger role here than, for example, 16-bit size has with 32-bit processor. At least in practice. With 32-bit x86 processor, 32-bit size is really used almost everywhere.

[Love4Boobies]

The point was that the 32-bit size has bigger role here than, for example, 16-bit size has with 32-bit processor. At least in practice. With 32-bit x86 processor, 32-bit size is really used almost everywhere.

So you're saying whether a CPU is 32-bit or 64-bit is settled by how the CPU is used? Because in that case, x86-64 was originally 32-bit and later became 64-bit and will, when it's obsolete, become 0-bit (?).

[bluemoon]

As far as the x86-64 architecture is concerned, the 64-bit is far more native size than 32-bit. That goes without saying.

The manual disagree. The native bit depends on the operating mode. If an x86-64 CPU is operating in compatibility mode it's running natively 32-bit; and differ from IA64, that compatibility mode are, as claimed by manual, running just as fast as 64-bit instructions.

[Love4Boobies]

You haven't provided any definition for what 32-bit and 64-bit mean. The proposition is that these terms are not technical but marketing. Different people will understand different things when you use them.

[Antti]

The manual disagree. The native bit depends on the operating mode.

I forgot to mention I was talking about the x86-64 architecture running in Long Mode. I used the "x86-64 architecture" expression too liberally.

Oh, this topic went out of control. I think my point was crystal clear. I try to rephrase my thoughts just one more time and this is how it applies to the topic:

With x86-64 architecture in Long Mode, the 32-bit size is still used so much that it would be reasonable to keep the 32-bit int size. When it comes to the processor itself, I still think that it is not so 64-bit than 80386 is 32-bit.

You haven't provided any definition for what 32-bit and 64-bit mean.

Of cource, the concept of "native word size" can be quite vague. However, in this context your requirement goes a little bit too pedantic. I was just comparing the 32-bit x86 and x86-64 processors.

[bluemoon]

Oh, this topic went out of control.

Yeah, but as long as we learn something from each other in the progress it's good.

And by the way, there is 386SX that has 16-bit data bus. I think we all agree to some extend, talking about the number of bits alone is quite blur without account for the actual technical detail, and it became just an identifier / call sign / marketing term.

[Owen]

A bit more rationale for int being 32-bit on amd64: If you made int 64-bit, then either

• Short becomes 32-bit, which leaves you without a 16-bit type
• Short stays 16-bit, which leaves you without a 32-bit type.

In either of these cases, you would need to create some horrible contortion to incorporate the other type: either a short long for 32-bit, or a short short for 16-bit (and the latter would probably cause anyone working with said type to have this song permanently stuck in their head)