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.
Related
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
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.
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.
I don't understand what 32 bit and 64 bit means. It seems that people say 64 bit computers run faster - but why? Does it mean that there are 64 bit integers instead of 32? If it's something like that, is there a way to write a program to determine if we're on a 32 bit or 64 bit machine?
On 64-bit machines pointers are 8 bytes (64 bits). On 32-bit machines they are 4 bytes (32 bits). Thus we can determine by the size of a pointer what we are dealing with, in it's simplest form:
#define IS_64BIT (sizeof(void *) == 8)
The only drawback is that a 64 bit computer running in 32 bit mode will register as 32 bit. Of course, this isn't actually important as for all intents and purposes a 32 bit OS on a 64 bit computer will be a 32 bit computer.
There's actually several different things your asking here.
First of all there's the CPU. Most modern day CPUs (within the past 5-years approx) will support 64-bit.
Now just because the CPU supports it doesn't mean the OS supports it, that's where you have either 64-bit OS or 32-bit OS (32-bit is also known as x86, there's small technical differences in the x86 refers to the CPU instruction set, but for most common usage x86 and 32-bit are interchangeable)
Even if the OS supports it, it doesn't mean the specific program you're running supports 64-bit. What most (if not all?) 64-bit OS's do is they have a 32-bit emulation mode so you can still run 32-bit programs.
Now for your question of how to determine which architecture you're running on, the most reliable way is to ask the OS through some API call.
As for why 64-bit is sometimes considered faster, it because with 32-bits it is only possible to address 4GB of memory, whereas with 64-bit the limit imposed by address space is much higher (as in about 4 billion times higher) and the limiting factor is hardware not address space. As to when and why more memory is faster, that's a separate topic altogether.
64-bit machines do not run faster than 32-bit machines except in cases where 64-bit math is being done or in cases where more than 4 GB of RAM is needed.
64-bit AMD (and later Intel) machines run faster than 32-bit x86 machines because when AMD designed the new instruction set they added more CPU registers and made SSE math the default.
32-bit x86 systems can waste a lot of CPU time pushing data around in RAM, while a x86_64 system can store that data in CPU registers instead. Registers are much faster than level-1 CPU cache. Having more registers also saves CPU instructions that otherwise need to store the old value of a register in RAM, load in a different value from RAM, then load the original value back from RAM.
In some especially register-starved cases the extra registers can gain 30% speed for a program. The benefit is usually much less than that.
The speed benefits from assuming SSE2 are many. In 32-bit CPUs SSE instructions may or may not exist, so to use them the software needs to have clumsy test code and two (or more!) implementation of the math functions. Most software just doesn't care enough and so it never bothers, always falling back on x87 FPU math from the 486 days. The 64-bit CPUs made SSE2 a required part of the instruction set, so all x86_64 programs are free to assume it exists and use it in all cases.
64bit computers do not run faster, per se. It just can support higher precision (larger integers, more precise floats).
In some rare cases, libraries might jam two 32bit numbers into 64bits to perform a large number of parallel operations, possibly resulting in potentially up to 2x speedup. This might occur for some highly optimized scientific/numeric libraries, or in special applications that (for some reason or another) have been highly optimized at a very low level. For example, some multimedia software. It should be noted that such applications could always have made this tradeoff even in 32bit mode, but chose not to; they are merely trading away precision (which they may not need) for parallelism.
Operating system benchmarks which reveal faster performance (maybe <10% improvement) are not necessarily related to 64bit-related optimizations. 64bit architectures may be correlated with having for example more registers or advanced features that programs can take aware of [citation: http://www.tuxradar.com/content/ubuntu-904-32-bit-vs-64-bit-benchmarks ], which may be the cause of a performance difference (as well as other variables).
How to determine whether a CPU is 32bit or 64bit depends on what OS you are using. For example on Linux, you can call uname -a, though there's probably a better way to do so. If you're using C/C++, see the other answer for a way to determine it in a program.