sizeof int?

[Sebastiani]

I think what he means is that the old instructions simply act on a portion of the an existing 64-bit register (although it would seem that it should be the lower word - not higher). Just as you can access the lower 16 bits of eax on a 32-bit machine by referencing the 'ax register', for instance.

Or maybe I misunderstood you?

[cyberfish]

I thought what he meant was, 64-bit data needs to be stored in 2 independent registers, like how the x86 div instruction divides edx:eax by... something . That's not true for x86-64, though.

[Dino]

That's not the case with x86-64. x86-64 gets new 64-bit registers (extended EAX-EDX to RAX-RDX, as well as a few brand new 64-bit ones). They are not 'halves".

In your view, then, what should determine the size of int? Should it always be 4 bytes everywhere on all machines?

Yes, I think standardization is good. We're talking about a language that is used on many, many platforms.

[Mario F.]

Yes, I think standardization is good. We're talking about a language that is used on many, many platforms.

But what can possibly be more portable than:

A ‘‘plain’’ int object has the natural size suggested by the
architecture of the execution environment (large enough to contain any value in the range
INT_MIN to INT_MAX as defined in the header <limits.h>)

If on one hand it can be argued the developer is limited in that they cannot rely on the size of the int, it however allows for the continuous development of newer architectures without having to introduce new built-in types; a feature that would break portability at a fundamental level.

EDIT: Incidentally, did you check my question on the previous post? You arose my curiosity.

[Dino]

Hmm... this looks very much like the Z80 to me in how it handled 8 and 16 bit instructions. Are you sure there are indeed only 64 bit registers instead of 32 bit registers paired up?

I'm thinking you'd have there a 32 bit processor with a 32 bit internal databus and a 64 bit address bus. Most of the registers would be 32 bits that could be paired for 64 bit data storage, and only a handful true 64 bit registers (like the stack pointer). And you can still have two sets of instructions for 32 and 64 bit processing.

Otherwise I find it odd this -- IMHO -- inefficient choice to use 64 bit registers to store 32 bit data blocks.

I'm not familiar with the Z80. I'm referring to IBM z/Architecture series (aka z/Series) processors.

The register setup is certainly not inefficient, by any measure.

Similar to Intel, on the IBM, there are several sets of registers available to the programmer:

16 64-bit general purpose registers
16 32-bit access registers
16 64-bit control registers

I wasn't on the design team (as if) but I'm pretty sure the choice to keep the same set of registers and extend them on the left was an easy one in order to provide backward compatibility (so all those programs written back in the 60's, 70's and 80's whose source code is or is not long gone will still run on new hardware).

[Dino]

I think what he means is that the old instructions simply act on a portion of the an existing 64-bit register (although it would seem that it should be the lower word - not higher). Just as you can access the lower 16 bits of eax on a 32-bit machine by referencing the 'ax register', for instance.

Or maybe I misunderstood you?

Yes, this is correct. At first, I too considered that it might be appropriate to have the original 32-bit half on the left, but the more I use them, the more it makes sense to me to put them on the right, and there are several new instructions for managing this too, like "clear high half" (the left half), "clear high (left) half all registers", "load 64 bit value from 32 bit value already in right half", etc. In the case of a negative value, the sign bit is propagated left. (These are not the real instruction names, but I express them this way for simplicity.

[Dino]

I thought what he meant was, 64-bit data needs to be stored in 2 independent registers, like how the x86 div instruction divides edx:eax by... something . That's not true for x86-64, though.

Nope - it's one 64-bit register that can be managed like a 64-bit or 32 bit (or, in regards to the right half, managed a byte at a time - like AL, AH, etc.).

[brewbuck]

64-bit ints would be stupid. Nobody needs numbers that large normally, they take up twice as much memory and twice as much cache. In fact, most places where people use a 32-bit integer they could easily get away with a 16-bit short or even a char.

I'd challenge anyone here to examine a piece of their own code and tell me that in all those places you are using "int" that it would not be a pointless waste of space for that quantity to be 64 bits.

[Elysia]

There is still a lot of "oh, it's better this way" (car analogy) or "I like it this way", but still no practical reason why int should be 64 bits.
To the processor, 32 bits or 64 bits doesn't matter, so why the bother?
Besides, with int being 4 bytes, we could have char (1), short (2), int (4), long (8), long long (16). That makes more sense to me, as we're able to use all kinds of sizes. Especially good where performance and memory print really and truly matters.

[MK27]

64-bit ints would be stupid. Nobody needs numbers that large normally, they take up twice as much memory and twice as much cache. In fact, most places where people use a 32-bit integer they could easily get away with a 16-bit short or even a char.

Just in case anyone gets the wrong idea here (I did at a certain point; I still keep finding old code with lots of short int in it) using a short int saves memory but is slower for the processor.

So unless you are dealing with a very restricted memory, using a short int for low numbers is a bad practice. Use chars or ints.

[Elysia]

Is it really slower to use a smaller data type?
The lower bits of the register would be filled with the data of the variable and the upper bits would simply be 0. That doesn't speak of much penalty to me.
Still, even if there was a penalty, how much would it be? 1 clock cycle or so?

[abachler]

Besides, with int being 4 bytes, we could have char (1), short (2), int (4), long (8), long long (16).

or use the existing types int8 int16 int32 int64 and the as yet to be widely implemented int128.

That is actually a feature I think SHOULD be added to the standard, defining that all compliant compilers must support integer types of any size when they are written as intN and recognize those as keywords. of course the details fo how the compilers did so woudl be left as implementation specific. A compiler for x86/x64 could use native register sizes, while a compiler for the 68HC11 would have to use some behind the scenes inline support functions. And of course they woudl all have to use some fancy math for int41

[Elysia]

Hmm? I do not know of such types implemented into the standard. If they were, then that would be excellent news.
If they were to exist, the above would a void argument indeed.

[laserlight]

Hmm? I do not know of such types implemented into the standard. If they were, then that would be excellent news.

C99 only, I think. Plus the types have a "_t" suffix, and are not guaranteed to be available.

EDIT:

That is actually a feature I think SHOULD be added to the standard, defining that all compliant compilers must support integer types of any size when they are written as intN and recognize those as keywords.

Yeah, C99 only requires them to be available if integer types with those sizes are supported by the implementation.

[brewbuck]

Just in case anyone gets the wrong idea here (I did at a certain point; I still keep finding old code with lots of short int in it) using a short int saves memory but is slower for the processor.

So unless you are dealing with a very restricted memory, using a short int for low numbers is a bad practice. Use chars or ints.

Yes, and I didn't really finish my entire thought in that post. I'm not arguing that a programmer should use the smallest integer type possible. In fact, I'm trying to argue the opposite: we need a generic, reasonably-sized type that we can use everywhere without having to think too hard about it. That type, in my mind, is a 32-bit integer. It gives a good trade between range and memory use in normal situations.

(Of course, a programmer should always think about the consequences of limit range, overflow, and underflow. My point is that these issues should normally be solvable with an every-day data type, and that the solution should also not be a gross overkill in 99% of cases)