What are the advantages of deviating from the norm; that is 64-bit pointers in both user and kernel space for a 64-bit architecture?
Reference: http://lwn.net/images/pdf/LDD3/ch11.pdf (Page 2)
1
-
I am typing this on a x86-64 Gnu+Linux, with 64bit kernel, and 32 bit (x86, not x32) user-land. I don't need 64 bit, and when I discovered that my cpu is 64 bit, I just upgraded the kernel.– ctrl-alt-delorAug 11, 2014 at 11:11
Add a comment
|
3 Answers
Compatibility.
First, note that Sun's 64-bit support goes back to 1998, with Solaris 7, well before AMD64 and even Itanium had OS support. By supporting both 32-bit and 64-bit in userland, you could let the vast majority of software run completely unchanged.
Check out the Solaris 64-bit Developer's guide (dated 2005). First, it notes that there are really 2 separate systems:
The Solaris operating environment supports two first-class ABIs simultaneously. In other words, two separate, fully functional system call paths connect into the 64–bit kernel. Two sets of libraries support applications.
and then repeatedly emphasizes that if you've got good old C-code that assumes it's 32-bit, it'll work just fine - even continue to build just fine, as if nothing's changed:
As discussed in Getting Past the 4 Gigabyte Barrier, most 32-bit applications run unchanged in the Solaris 64-bit operating environment.
...
Source level compatibility has been maintained for 32-bit applications. For 64-bit applications, the principal changes that have been made are with respect to the derived types used in the application programming interface.
Successful tech transitions are usually accompanied by quirky hybrids and chimeras that sometimes live past their usefulness.
-
There is no such chimera (64 bit code with 32 bit pointers) with Solaris. The question has been corrected. It refers to a Linux kernel document.– jlliagreMay 27, 2012 at 17:09
Answering the revised question: Why does Linux on sparc64 architecture use 32-bit pointers in user-space and 64-bit pointers in kernel-space?
This was probably done to reduce the size of code both binaries and run time as pointers use half the size in memory while keeping other advantages 64-bit mode has. Of course the drawback is a virtual memory size limitation to 4 GB, but that was less of a problem seven years ago than today.
On AMD64 (aka x86_64) architecture, 32-bit pointers in 64 bit-mode is an ongoing project: X32 System V Application Binary Interface. The interest is higher with this processor family as you also have more registers available when in 64-bit mode and using them instead of memory speed-up applications.
answered May 27, 2012 at 22:21
According to the document you posted a link to, the Solaris x86_64 architecture does not use 32-bit pointers in user-space and 64-bit pointers in kernel-space.
Anyway, this document is either incorrect, incomplete/missing to explain what Solaris release is used and what compiler version and options are used or just simply doesn't apply to Solaris but Linux (it states as demonstrated by running the program on different Linux computers).
Both the 32 bit (ILP32) and 64 bit (LP64) models are supported on Solaris 10 and newer, regardless of the 64 bit CPU architecture used (x86_64 or UltraSPARC/SPARC64) and there are no 32-bit pointers in the 64-bit model. For details, have a look at the Solaris 64-bit Developer's Guide.
On SPARC, Solaris supports 64 bit binaries/pointers since 2.7 (1998).
answered May 27, 2012 at 9:56
-
"It’s interesting to note that the SPARC 64 architecture runs with a 32-bit user space, so pointers are 32 bits wide there, even though they are 64 bits wide in kernel space." -- I mistakenly mentioned x86_64 instead of SPARC.– gjainMay 27, 2012 at 10:02
-
Granted. The point is this document does not apply to Solaris but to Linux running on 64-bit SPARC. What your question claim is inaccurate. You might want to rephrase your question: "Why does Linux sparc64 architecture use 32-bit pointes in user-space and 64-bit pointers in kernel space."– jlliagreMay 27, 2012 at 12:30
-