This question is about terminology for 32-bit vs. 64-bit x86.
If I have 2 directories with source code of the same program - one for 32-bit Windows and another for 64-bit Windows, what will be the more correct names for these folders:
x86-64 and x64?
or IA-32 and x64?
I already have read some web resources, but can't understand. Just for the record:
https://superuser.com/questions/179919/x86-vs-x64-why-is-32-bit-called-x86
Difference between x86, x32, and x64 architectures?
https://en.wikipedia.org/wiki/X86
https://en.wikipedia.org/wiki/IA-32
https://en.wikipedia.org/wiki/X86-64
x86 can be a broad term that covers all CPUs that are backwards-compatible with 8086, and all extensions to the architecture including x86-64.
Note that IA-64 is not x86 at all, it's Itanium (a 64-bit VLIW architecture with explicit speculation / parallelism). It was also designed by Intel, but is totally unrelated to x86 in terms of compatibility or design. (Early IA-64 CPUs also had an x86 core integrated, for compatibility. Intel was pushing IA-64 while AMD was pushing AMD64/x86-64)
Intel sometimes talks about their CPUs as having IA cores + the integrated GPU and the other logic outside of each IA core. (IA = Intel Architecture = x86).
32-bit x86 specifically (excluding 16-bit or 64-bit) can be called
IA-32 (used sometimes by Intel)
i386 or i686 (common on Linux)
(Windows only): x86. Yes really: in the Windows world, "x86" specifically means 32-bit. That's why you have a Program Files (x86) directory with that name. This choice causes potential terminology confusion for everyone, because "x86" is still by far the best way to refer to the architecture in general, as opposed to ARM or MIPS.
rarely: x86-32. This is not used officially by any hardware or software vendors I'm aware of, but it is a useful term that's unambiguous.
Never call it x32. x32 is an ILP32 variant of the x86-64 System V ABI: 32-bit pointers in 64-bit mode. https://en.wikipedia.org/wiki/X32_ABI
64-bit x86 is easier to refer to specifically (excluding 32 and 16-bit):
x86-64 or x86_64 (the dash vs. underscore is not at all significant. In text most people use a dash, but only _ can be part of function/variable names in most languages.)
AMD64 or amd64
(Windows only) x64
IA-32e or Intel64 (mostly only in Intel CPU-architecture documentation documenting Intel's implementation of x86-64, these aren't popular and I haven't seen them in software directory names or config options). The "e" stands for "extensions", apparently. https://en.wikipedia.org/wiki/X86-64#Intel_64 has a History section that mentions naming. There are very minor differences between Intel and AMD implementations of x86-64, mostly only affecting kernels, not user-space.
Not IA-64, that's a separate architecture.
Of course if you want to be pedantic, x86-64 CPUs are required to support legacy mode, so you can run a pure 32-bit OS on an x86-64 CPU, and it's still a 64-bit CPU.
With a 64-bit kernel running 32-bit user-space, the CPU is in "compatibility" mode, which is a lot like 32-bit protected mode except the page-table format has 52-bit physical addresses. (More than the 36-bit physical address width from PAE page tables, which the x86-64 page-table format is based on.) User-space would be hard pressed to tell the difference between running under a 32-bit kernel vs. a 64-bit kernel, except for OS-specific stuff like asking the kernel with a system call.
Software directory names
Many projects go with i386 vs. x86-64 or amd64. That would be my recommendation as the least ambiguous. (Or maybe i686 if you don't really care about compat with CPUs older than PPro.)
Some, like GMP (the GNU MultiPrecision library) which has hand-written asm for many architectures, uses "x86" and "x86_64". https://gmplib.org/repo/gmp/file/tip/mpn.
(GMP has multiple hand-tuned versions of the same function for different x86 CPUs. Within "x86", there are subdirectories with different versions of functions tuned for Pentum, Core 2, Haswell, and/or taking advantage of instruction-set extensions like BMI2. This is unusual; most projects don't get that specific. Some will maybe have some stuff to take advantage of AVX or AVX512, or SSE4.1 for example, but that's often just within source files.)
x86-32 versions are for Intel-compatible 32-bit processors.
x86-64 versions are for Intel-compatible 64-bit processors.
IA-64 versions are for specifically 64-bit Intel Itanium microprocessors.
Sometimes referred as:
x86-32 sometimes referred as IA-32, i386 or i686, x86 (see note 1), x32 (see note 2).
x86-64 sometimes referred as AMD64, Intel 64, x64.
Note 1: Strictly speaking, it's not correct, because
x86 covers all CPUs that are backwards-compatible with 8086 and all extensions to the architecture including x86-32 and x86-64.
Though, this shortening is often used in Windows world.
Note 2: Should not be used to avoid confusion with x32 ABI.
Sources:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/3da8f2fd-1089-4000-8c3f-f9225f0635e3
https://stackoverflow.com/questions/53364320#53364541
Related
In ELF-header, value of e_ident[EI_CLASS] can either be 1 or 2, which indicates 32-bit operating or 64-bit operating system. But from history we know that ELF first appeared in Solaris 2.0, which is released in 1993. However, widely used 32-bit processor Pentium Pro didn't appeared until 1995.
So why does ELF header has no information about 16-bit or even 8-bit information?
The first "widely used" 32-bit CPU was the Intel 80386 which was much older.
Then we have the story about SUN and their SPARC architecture from around the same time-frame as the 386.
Solaris was developed by SUN for their machines in the early 1990's, close to when the first 64-bit systems started appearing actually.
ELF (acronym for the Executable and Linkable Format) was developed in the late 1980's, when all major Unix variants ran on pure or hybrid (think Motorola 68000) 32-bit systems.
EI_CLASS doesn't identify an "operating system", but rather the memory model. This setting defines how various address information is encoded in the file, not necessarily how wide the target registers are.
For PC CPUs, the code loader is executed on the same CPU that will execute the program contained in the ELF file, so EI_CLASS matches the the code format. However, ELF files are also used as a portable code / debug format, even on 8-bit and 16-bit controllers. Besides, virtually all 16-bit CPUs can address more than 64 KB of memory, so EI_CLASS cannot be set to ELFCLASS16 for such targets (assuming such a class existed).
To sum up, it's irrelevant how much bits wide pointers are, it's only relevant how much virtual memory you can have. Of course, one could still make ELF files more compact by defining something like ELFCLASS20 (a common value for 16-bit CPUs, including Intel 8086), but, like it was already stated, 32-bit architectures were already widespread in 1993, so nobody bothered to define such a thing.
AMD64 Architecture Programmer's Manual Volume 2 says that most modern system software bypasses the hardware features for memory segmentation, because it is often more efficient to handle memory isolation and relocation with a combination of software and hardware paging support (revision 3.23, page 65, 3rd paragraph). Following, the Manual says that in 64-bit (long) mode some segment registers (system-segment registers) are still used.
This leads me to two questions. Does the latest version of 64-bit Linux kernel:
1) Runs in AMD64's 64-bit (long) mode?
2) Implements memory segmentation? Are these system-segment registers used for anything?
Segmentation is not supported in 64-bit mode. The segment registers still exist for compatibility but do not do anything in 64-bit mode.
It is sad that it took so long for segments do die go away.
This is semi-theoretic question.
Can I specify the virtualization mode for memory (pure segmentation/segmentation+paging/just paging) while compiling for Windows (e.g., MSVS12 C++) and for Linux (e.g. g++)?
I have read all MSVS linker+compiler options, and found no point of control in there.
For g++ the manual is quite too complex for such question.
The source of this question is this - link
I know from theory and practice that these should either be possible or restricted by OS policy at some level cause core i7 supports all three modes I mentioned above.
Practical background:
The piece of code that created lots of data is here, function Init - and it exhausted my memory if I wanted to have over 2-3G primes on heap.
Intel x86 CPUs always use some form segmentation that can't be turned off. In 64-bit mode code segmentation is limited, but it's still there. Paging is required for both Windows and Linux to work on Intel CPUs (though Linux doesn't use paging on certain other CPU architectures). Paging is also required to enable 64-bit mode on Intel CPUs.
So in other words on Windows and Linux the OS always uses segmentation and paging, and so do any applications run on them, though this is largely transparent. It's not possible to "compiled+linked for 'segmentation without paging'" as you said in the answer you linked. Maybe the book you referenced is referring to ancient 16-bit versions of Windows (3.1 or earlier) which could be run in a mode that supported 80286 CPUs which didn't have paging. Though even then that normally didn't make any difference in how you compiled and linked your applications.
What you are describing is not a function of a compiler, or even a linker.
When you run your program, you get the memory model that is already running on the system. Your compiled code does not care abut the underlying memory mode.
However, your program itself can change the memory model IF it starts running in an unprotected processor mode.
I was on Microsoft's website and noticed two different installers, one for x64 and one for IA-64. Reference:Installing the .NET Framework 4.5, 4.5.1
My understanding is that IA-64 is a subclass of x64, so I'm curious why it would have a separate installer.
x64 is used as a short term for the 64 bit extensions of the "classical" x86 architecture; almost any "normal" PC produced in the last years have a processor based on such architecture.
AMD invented the AMD64 extensions; Intel was more or less forced to implement them, and called them first IA-32e, then EM64T and finally Intel 64 (actually, the AMD and Intel extensions aren't exactly the same, but they are almost identical).
Many people also call this stuff x86-64, to have a vendor-independent name and to stress the fact that it's the 64 bit evolution of the x86 architecture. All the "regular" PCs that are sold with "64 bit processors" run on x86-64 architecture.
IA-64 (Intel Architecture 64) is an almost completely unrelated 64 bit architecture (also known as Itanium), developed by Intel initially for high-end servers. It was said that Itanium could have been a replacement for the x86 architecture, but this architecture didn't have much success (for various reasons), so it's unlikely that you'll ever need the IA-64 installers.
For more information, you may have a look at the wikipedia articles on x86-64 and Itanium.
IA-64 is the Intel Itanium Architecture. This is a Very Long Instruction Word (VLIW) processor instruction set.
x86_64 is the normal 64-bit architecture that is used by processors inside every laptop / desktop in today's computers. This processor is a dynamic processor.
The main difference between these two is that
In VLIW, the compiler resolves the dependencies between instructions and schedules them appropriately. The processor merely executes them.
With a dynamic processor, the compiler just schedules the instructions without worrying about dependencies. The processor takes care of dependencies, reorders them and executes them appropriately.
VLIW code is dependent on each chip's internal architecture. The compiler needs to know that information. The advantage of them is that it can extract much more parallelism than dynamic processors can give.
The code is independent on each chip's internal architecture for dynamic processors. It just needs to follow the instruction set. So code compiled on one machine can run on other machines very easily. The disadvantage though is that limited parallelism can be exploited from dynamic processors. And the internal logic and design is very complex and intricate than VLIW.
Nevertheless, dynamic processors are used today mostly by consumers (individuals), so they can run code compiled / generated on any machine. VLIW processors are used by servers and enterprises because of the parallelism they can produce.
they are different
IA-64 is itanium - an architecture for servers
x64 is what 64bit intel core and amd cpus implement
x64 is short for x86-64 which is an extension of the x86 instruction set.
IA-64 is for the Itanium 64 bit Architecture (by Intel)
IA-64 is for computers running Intel Itanium 64 bit processors. They do not support running 32 bit applications like x64 processors do. A special version of Windows is needed to run on these processors, thus the two different installers.
They have different instruction set, this is the key point.
What type of Paging is used when 32-bit linux runs on 64 bit Intel architecture?
(1) 32-bit Paging
(2) PAE Paging
(3) IA-32e Paging
In other words, What kind of paging is used in which situation?
Either 32-bit or PAE, depending on what variety of 32-bit kernel it is. In other words, it behaves no differently than if it were running on a 32-bit CPU.