Wasn't there an Int type that should be the size of a platform dimension?

Question

I heard a lot of contradictory information on this issue, but in general I heard that the Int type should have been related to the platform word size, therefore, for example, in a 32-bit machine, Int has 4 bytes.

Except that I started coding in childhood in DOS, I think that my compiler already used 32-bit Int, even if the goal was a 16-bit processor (for example, 286), requiring constant use of shorts ...

And today I compiled my program as 64-bit only for kicks, and Int still finished 32-bit (and short 16-bit, I have not tested for a long time).

I know that the C standard defines this: short <= int <= long but I'm curious what happened? Why did everyone decide to use some arbitrary sizes for int?

Answer 1

C99 Justification uses many words to explain why long long was introduced, I quote part of the history of integer types, I think it can answer your question, at least in part.

Justification for an International Standard - Programming Languages ​​- C §6.2.5 Types

In the 1970s, 16-bit C (for PDP-11) initially presented file information with 16-bit integers that quickly became outdated along the disk. People switched to a 32-bit file system, first using int[2] constructors, which were not only inconvenient, but also inefficiently portable for 32-bit equipment.

To solve the problem, the long type was added to the language, although this required C on PDP-11 to generate several operations to simulate 32-bit arithmetic. Even when 32-bit minicomputers became available with 16-bit systems, people still used int to increase efficiency, reserving long for cases where large integers were needed, since long was noticeably less efficient for 16-bit systems. Both short and long values ​​were added to C, making short available for 16 bits, long for 32 bits, and int for convenience. There was no desire to block 16 or 32 in the language, since there were C compilers for at least 24- and 36-bit CPUs, but rather to provide names that could be used for 32 bits as needed.

PDP-11 C can be reimplemented with int as 32-bit, avoiding the need for long ; but it will force people to change most of their use of int to short or seriously degrade performance on PDP-11. In addition to the potential impact on the source code, the impact on existing object code and data files would be worse, even in 1976. By the 1990s, with a huge software base installed and widely used by dynamically linked libraries, the impact of resizing a common data object in an existing environment is so great that few people will tolerate it, although this may be acceptable when creating a new environment. Consequently, many vendors have added a 64-bit integer to their 32-bit C environments to avoid namespace conflicts using the new name most often used long long .

Answer 2

The standard defines the minimum sizes for integer types depending on the range of values ​​that they can represent. I will not cite all this, but to summarize:

• char must be at least 8 bits
• short and int must be at least 16 bits
• long must be at least 32 bits
• long long must be at least 64 bits

Meanwhile, to indicate K & R (my highlight):

The goal is that short and long should provide different integer lengths where possible; int will usually be the actual size for a particular machine.

So, if it’s possible to fit the size of a machine word, if it’s possible, this is by no means mandated, so this is ultimately an arbitrary compiler decision, which means int - as long as it is short , long or somewhere in the middle, and at least 16 bits.

Answer 3

int is for a reasonable integer type by default, nothing more. This includes issues such as the size that is best supported by the underlying platform, but more there.

For example, the word size can be quite small (8-bit microcontrollers), especially when larger types can be supported and more useful. On the other hand, if the phrase is larger than usually necessary (64 bits), existing programs will explode unreasonably or even break due to silly assumptions made in the past.

Answer 4

This was true in the old days when the size of the memory bus was the same as the size of the processor register. But not so long ago, Pentium was the first processor that you will find on standard hardware, where the size of the memory bus has become larger, 64-bit for a 32-bit processor. An easy way to increase bus throughput.

Memory is a very large bottleneck, it is much slower than the processor core. The problem is the distance, the farther the electrical signal has to go, the more difficult it will be to switch the signal at high frequency without distorting the signal.

Accordingly, the size of the processor caches, as well as the efficiency with which the program can use them, strongly determine the speed of the program. Skipping a cache can easily get by with cpu stop cycles.

Your 64-bit processor did not have a double cache size, L1 is still 32 KB and 32 KB of data, regardless of whether your program is running in 32-bit or 64-bit mode. The available space on the chip and, most importantly, the distance between the cache and the execution mechanism are physical limitations, determined by the size of the function of the technological technology.

Thus, creating a 64-bit int, which is very simple for the compiler, is very harmful for the speed of the program. Such a program uses caches much less efficiently and will suffer from many other kiosks, waiting for the memory bus.

The dominant data models for 64-bit are LLP64, a choice made by Microsoft, and LP64, a choice made on * nix operating systems. Both use 32-bit for int, LLP64 uses 32-bit length, LP64 makes it 64-bit. Long long 64-bit on both.

Answer 5

int should be an integer type with a natural size for the runtime, but for backward compatibility, many compilers adhere to 32-bit integers even in a 64-bit environment.