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)
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:
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:
Successful tech transitions are usually accompanied by quirky hybrids and chimeras that sometimes live past their usefulness.
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.
According to the document you posted a link to, the
Anyway, this document
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).