GLIBC 2.16 Brings X32 Support, ISO C11 Compliance, Better Performance

← Back to Stories (view on slashdot.org)

GLIBC 2.16 Brings X32 Support, ISO C11 Compliance, Better Performance

Posted by Soulskill on Saturday June 30, 2012 @10:24PM from the new-and-shiny dept.

An anonymous reader writes "The GNU C Library version 2.16 was released with many new features over the weekend. The announcement cites support for the Linux x32 ABI, ISO C11 compliance, performance improvements for math functions and some architectures, and more than 230 bug fixes."

95 comments

Min score:

Reason:

Sort:

X32 by Anonymous Coward · 2012-06-30 22:30 · Score: 1

I've been following Glibc development for years, and I understand the code well and the concepts fine, but can anyone explain to me what the benefits are of the X32 ABI, perceived or real? I just don't get it...
1. Re:X32 by TheRaven64 · 2012-06-30 22:45 · Score: 5, Informative
  
  64 bit architectures give you 64-bit registers and a 64-bit address space (since pointers are, traditionally, integers that fit in registers[1]). On x86, there are a number of other advantages to using the 64-bit long mode: guaranteed SSE so you don't need slow x87 code, more registers, PC-relative addressing (useful for position-independent code) and so on. The cost of using these is that now every pointer is bigger. This has knock-on effects in terms of data cache usage.
  The X32 ABI allows you to have all of the benefits of the 64-bit mode except for the larger address space. If you're using under 4GB of memory, then it can, in theory give an improvement in memory and cache usage.
  There are two down sides. The first is that, in my testing of C, C++ and Objective-C code, I've found that it's very rare on a 64-bit platform for pointers to account for even 10% of the total memory usage, and usually it's a lot less. This is made worse by the fact that the X64 and X32 ABIs are incompatible, so you may need two copies of the same library in memory if you have code using both.
  I was quite enthusiastic about the idea of something like X32 five or so years ago when it was very rare for programs to want more than 4GB of address space, but now it's far less clear that there's a real advantage.
  [1] Not with the architecture I'm currently working with, and I'm spending a lot of time fixing compiler assumptions that this is always the case.
  
  --
  I am TheRaven on Soylent News
2. Re:X32 by SuneSpeg · 2012-06-30 22:56 · Score: 3, Interesting
  
  If someone could explain to me why x86 architecture is suddenly named x32 , i would be happy too. The name has been working fine for 40 years, despite its difficult teen years where it only represented 16bit.
3. Re:X32 by sapphire+wyvern · 2012-06-30 23:15 · Score: 4, Insightful
  
  Good question. I looked at the linked article and it took me a while to figure out.
  x64 CPUs aren't just x86 CPUs with larger memory addresses. They also have more registers, and are guaranteed to support certain additional instructions that aren't necessarily available in an x86 CPU (e.g. SSE). "x32" mode exploits the additional registers & instructions, without actually using 64-bit memory addressing. I think the idea is that it's supposed to allow for most of the benefits of the x64 instruction set without incurring the caching penalties of larger pointers. Honestly I'm not sure how useful that really is.
4. Re:X32 by kasperd · 2012-06-30 23:16 · Score: 5, Informative
  
  If someone could explain to me why x86 architecture is suddenly named x32
  It's not. X32 is the name of a programming model, not an architecture. And the X32 programming model cannot be used on the x86 architecture, X32 is a programming model for the AMD64 architecture.
  
  The most important aspect of a programming model for C is that it defines the sizes of basic types like char, short, int, long, and pointers. Many other aspects follow more or less directly from the sizes of those types. X32 is unusual in that it is 64 bit code, but pointers are only 32 bits. When a pointer is in a CPU register the lower 32 bits is the actual value, and the upper 32 bits are always zero.
  
  --
  
  Do you care about the security of your wireless mouse?
5. Re:X32 by billcopc · 2012-06-30 23:36 · Score: 4, Informative
  
  X32 is for running 32-bit apps in a 64-bit native execution environment.
  On Windows this practice is called "thunking" or "Windows-on-Windows", where it takes the form of a partially emulated legacy kernel which then backhands its requests to the real kernel.
  On Linux, since we usually compile things for the platform as-needed, it's more about efficiency than compatibility. If you don't need 64-bit processing, sometimes it's faster to stick with 32-bit code. If you can live with the 4gb address space, your pointers are half the size, resulting in a smaller memory footprint, which then reduces cache pressure, potentially yielding significant speed improvements for some workloads. Due to the use of 32-bit pointers in this scenario, a 32-bit compatibility layer is required to interface with system libraries. You can't just stick a 32-bit libc and expect it to work, because of its intimate relationship with the kernel.
  
  --
  -Billco, Fnarg.com
6. Re:X32 by Anonymous Coward · 2012-06-30 23:41 · Score: 2, Informative
  
  I think there are more advantages. Think embedded device, which is a market X86 is trying to move into.
7. Re:X32 by enriquevagu · 2012-06-30 23:42 · Score: 2
  
  Note that, on multiple processors, the legacy x86 and the x64 implementations are (almost completely) separated, using different processor resources. Between the larger/better resources, and the higher number of register, the x64 pipeline gets a better performance in the same processor. The lower memory usage also helps to improve performance, but its impact is minor.
8. Re:X32 by Anonymous Coward · 2012-06-30 23:54 · Score: 1
  
  It's not the same architecture. X32 is basically x86-64 (with its extra registers, NX bit, etc.) but with 32 bit pointers.
  The positives:
  * It cuts memory usage (amounts differ on how pointer-heavy an application is).
  * There are low-memory systems out there today with 64-bit processors running 32-bit operating systems - e.g. most netbooks, some low-end commercial virtual server services. Also, as time goes on, x86-64 processors will replace x86 processors where they're used in embedded systems. X32 lets these systems better use the features of the processor without increasing their memory requirements.
  * More stuff can fit in processor cache, not insignificantly improving performance for some applications.
  * Over plain old x86, compilers can use the x86-64 exclusive processor features, improving performance.
  * A system can run x86-64 and X32 applications simultaneously - x32 for most appplications, and x86-64 for applications that need to address more than 4GB of memory.
  The negatives:
  * You only get 4 GB of virtual memory per X32 process.
  * On a mixed x86-64 and X32 system, you have to load two copies of shared libraries (this doesn't happen with exclusively X32 systems).
9. Re:X32 by ThePhilips · 2012-07-01 00:44 · Score: 3, Interesting
  
  The negatives:
  * On a mixed x86-64 and X32 system, you have to load two copies of shared libraries (this doesn't happen with exclusively X32 systems).
  It's not that the extra copies is the problem.
  The problem is that you effectively have to have two different /usr/lib directories. With potentially two different sets of the libraries. Same consequently goes for the /usr/include. Compiling and running software occasionally becomes nightmarish experience.
  After enjoying it thoroughly on the commercial *nix variants (Solaris and HP-UX), I have hopes that Linux will not do it and keep it clean: either fully 64bit system or fully 32bit system.
  
  --
  All hope abandon ye who enter here.
10. Re:X32 by TheRaven64 · 2012-07-01 00:50 · Score: 4, Informative
  
  On an embedded system, you'll be saving 5-10% memory usage by only supporting X32 and not X64. It may be worth it...
  
  --
  I am TheRaven on Soylent News
11. Re:X32 by BusterB · 2012-07-01 01:25 · Score: 3, Interesting
  
  In my opinion, it is designed pimarily so that Intel's embedded processors run Android well in the short term. Atom architecture in particular benefits in that some pointer offset calculations are faster when done in 32-bit vs 64-bit. Here are some great discussion links: http://blog.flameeyes.eu/2012/06/debunking-x32-myths http://lwn.net/Articles/503412/
12. Re:X32 by kantos · 2012-07-01 01:27 · Score: 4, Interesting
  Actually no it's not... Linux has that already and it works just fine, anyone who has gone through the pain of getting flash player to work before the x64 port can tell you. This is actually more similar (albeit with more restrictions) to setting the /LARGEADDRESSAWARE:NO option on the linker in Visual C++. An option you'll notice that comes with a significant warning about interoperability. Microsoft solved this problem by making pointer handling the developer's job, this meant that they could continue to use x86-64 libraries without an issue but all malloc operations would return addresses that are safe to sign extend.
  The benefit on windows is that you:
  
  Use less ram on an x64 bit OS than a corresponding x86 application would, this is because you won't have x64 threads for each x86 thread you have going, and won't have to load the thunking DLLs
  In theory could interop with x86 code since your pointers are safe, however this is not supported
  --
  Any and all content posted above may be ignored, considered irrelevant, or otherwise dismissed.
13. Re:X32 by jelle · 2012-07-01 01:56 · Score: 1
  
  If your platform has stdint, then you can use ptrdiff_t instead of int/long in your code... It's always the right size integer for pointers.
  
  --
  --- Hindsight is 20/20, but walking backwards is not the answer.
14. Re:X32 by Hal_Porter · 2012-07-01 01:59 · Score: 1
  
  From the first link
  
  CPUs perform better on 32-bit operands than 64-bit. Interestingly, the only CPU that Intel admits do perform better on 32-bit on the presentation I already linked a few times, is the Atom â" the quote is actually "64bit imul latency is twice of 32bit imul on Atom"
  .
  Now, what the heck is imul? That's a signed multiply operation. Do you multiply pointers? It doesn't make sense. Besides, pointers are not signed. Are you telling me that your most concern is for a platform (Atom) that has extra latency on an operation when people use 64-bit data types and they should instead use 32-bit? And your solution for that concerns is to create a new ABI where it's harder to use 64-bit data types instead of going to fix whatever program is causing the problem?
  I guess I should end it here, because this last note about the Atom and imul is probably going to make the day of most people who have half a clue.
  That paper is hardly making the case for x32.
  
  --
  echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
15. Re:X32 by TheRaven64 · 2012-07-01 02:01 · Score: 2
  
  Actually, you need three copies, one for i386, one for X64 and one for X32. You should only need copies of libraries though, not of headers (which use #ifdef for multiple platforms).
  
  --
  I am TheRaven on Soylent News
16. Re:X32 by Anonymous Coward · 2012-07-01 02:17 · Score: 0
  
  When a pointer is in a CPU register the lower 32 bits is the actual value, and the upper 32 bits are always zero.
  No. The upper 32 bits are sign extended.
17. Re:X32 by Anonymous Coward · 2012-07-01 02:32 · Score: 0
  
  Too bad the fat ELF project was shot down, on Macs having multiple architecture support is mostly transparent. That said I do think X32 is a bad idea, forced upon us for wrong reasons.
18. Re:X32 by ThePhilips · 2012-07-01 02:34 · Score: 3, Interesting
  
  Actually, you need three copies, one for i386, one for X64 and one for X32. You should only need copies of libraries though, not of headers (which use #ifdef for multiple platforms).
  I should have spelled it out better: many pieces of software already now make a presumption what /usr/lib is: some insist that those must be 32bit libraries, some insist on the 64bit ones. LD_LIBRARY_PATH works most of the time - until you hit an application which to do its work launches other applications.
  As for the headers... I have seen enough breakages to stop believing that #ifdefs are the solution: different software and different systems refer to the same thing with under names. Good luck finding a working combination. E.g. some functions are available in 32bit variant but not in 64bit variant, and vice versa. (That was recent fsck up of compiling VIM on the AIX 7: compile as 32bit, _XOPEN_SOURCE=600 - and it would fail linking because some 32bit libs are missing; try to compile as 64bit - only to find that _XOPEN_SOURCE wouldn't work and piles and piles of function declarations are missing. I had to hack the includes/defines into the config.h for the VIM to compile and link. (autoconf hasn't spotted it because it apparently couldn't imagine the functions missing.))
  Linux now is more or less clean of the madness.
  
  --
  All hope abandon ye who enter here.
19. Re:X32 by ThePhilips · 2012-07-01 02:42 · Score: 1
  
  IIRC, the ELF is fat. The fatness is simply not used and deprecated.
  But then again: fatness doesn't solve the problem - it just moves it around. In case of fat binaries the problem translates: some binaries are slim and not supporting all the expected architectures.
  The problem, in general, is that for a single OS to have parallel support for multiple run-time architectures is messy and error prone.
  
  --
  All hope abandon ye who enter here.
20. Re:X32 by TheRaven64 · 2012-07-01 02:42 · Score: 1
  
  You mean intptr_t. ptrdiff_t is the largest size of an object. On segmented architectures, it can be the maximum size of a segment. ptrdiff_t is large enough to hold the result of any defined pointer comparison, but pointer comparisons are only defined (in C) on pointers within the same object.
  
  --
  I am TheRaven on Soylent News
21. Re:X32 by Anonymous Coward · 2012-07-01 02:43 · Score: 0
  
  This is about memory consumption, not type selection.
22. Re:X32 by Bengie · 2012-07-01 02:43 · Score: 1
  
  Not to say it won't happen, but I don't think of x64 when I think "embedded". Would be great for a Linux firewall, but most embedded versions are ARM. I could see a high performance edge firewall/router with only 2-4GB of memory and a quad-core Xeon with 10Gb NICs. Smaller pointers are great for something like a firewall that relies heavily on data-structures.
23. Re:X32 by Anonymous Coward · 2012-07-01 02:46 · Score: 0
  
  X32 cannot be used in kernel mode. The upper 32 bits will always be zero.
24. Re:X32 by Joce640k · 2012-07-01 04:38 · Score: 1
  
  If someone could explain to me why x86 architecture is suddenly named x32
  It isn't. x86 is some sort of thunking layer between x86 and x86. Or something.
  I'm not sure of the exact details but it's not x86.
  
  --
  No sig today...
25. Re:X32 by phantomfive · 2012-07-01 04:45 · Score: 1
  
  What architecture are you currently working with that is giving you pointer problems?
  
  --
  "First they came for the slanderers and i said nothing."
26. Re:X32 by Anonymous Coward · 2012-07-01 04:53 · Score: 1
  
  The problem is that you effectively have to have two different /usr/lib directories. With potentially two different sets of the libraries. Same consequently goes for the /usr/include. Compiling and running software occasionally becomes nightmarish experience.
  solution: multiarch
  with multiarch in debian in ubuntu you can even install your arm or whatever libraries on a md64 system without trouble and without any nightmarish experiences.
27. Re:X32 by bill_mcgonigle · 2012-07-01 04:54 · Score: 2
  
  On an embedded system, you'll be saving 5-10% memory usage by only supporting X32 and not X64. It may be worth it...
  Yeah, this was my thought as well. x86 just doesn't seem to happen much in the embedded space, but I guess somewhere there is an embedded x86 vendor running millions of units (perhaps the contributor).
  I doubt it's the +10% memory size that's keeping vendors away from x86, though.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
28. Re:X32 by unixisc · 2012-07-01 04:59 · Score: 1
  
  But w/ memory densities going up, and fast getting to the point where 4GB or even 8GB will be the bare minimum standalone memory that will be available, even embedded will be forced to support x64. Unless they make CPUs w/ embedded RAM, in which case the question of having GBs doesn't even arise. There, since CPU designers can assign as little of the silicon to memory as they wish, that is one place where a x32 would be valid.
29. Re:X32 by unixisc · 2012-07-01 05:02 · Score: 3, Insightful
  
  I was quite enthusiastic about the idea of something like X32 five or so years ago when it was very rare for programs to want more than 4GB of address space, but now it's far less clear that there's a real advantage.
  That same thought struck me as well. At that time, when we were seemingly 'nowhere near 4GB', a x32 ABI would have made sense. But now, by the time it's ready, it's use by date seems to be near, if not already gone.
30. Re:X32 by kasperd · 2012-07-01 05:33 · Score: 2
  
  The upper 32 bits are sign extended.
  Look at the spec. You only have to read the first sentence. The chapter on X32 starts
  
  When a value of pointer type is returned or passed in a register, bits 32 to 63 shall be zero.
  
  --
  
  Do you care about the security of your wireless mouse?
31. Re:X32 by RobbieThe1st · 2012-07-01 07:32 · Score: 1
  
  But this is exactly the problem the parent post was talking about - for multiarch, you need two sets of libraries. which *could* be different. Fortunately, debian keeps things clean, so it works amazingly well, but the problem could still arise.
32. Re:X32 by osu-neko · 2012-07-01 07:35 · Score: 1
  
  In other words, the difference between two pointers should never require more bits than the pointers themselves. However, depending on the memory model, it may require less (pointer comparisons being only valid between objects in the same segment), making ptrdiff_t smaller than intptr_t.
  
  --
  "Convictions are more dangerous enemies of truth than lies."
33. Re:X32 by osu-neko · 2012-07-01 07:43 · Score: 1
  
  Correction: It doesn't even necessarily depend on the memory model. ptrdiff_t need only be large enough to hold any valid pointer offset, which on some architectures could be smaller than all of memory, even without a segmented memory model.
  
  --
  "Convictions are more dangerous enemies of truth than lies."
34. Re:X32 by Brane2 · 2012-07-01 08:30 · Score: 1
  
  So, it was meant for the case where you'd go with X86_64, but with anorexic memory ?
  Who is so moronic to do that ?
35. Re:X32 by TheRaven64 · 2012-07-01 10:34 · Score: 1
  
  CHERI. It's an experimental MIPS-derived chip that has 32 256-bit capability registers, which are basically fat pointers containing a base, length, and set of permissions.
  
  --
  I am TheRaven on Soylent News
36. Re:X32 by phantomfive · 2012-07-01 11:02 · Score: 1
  
  That is fascinating. I'm having trouble finding a link to information about it. I would guess the base is the address, length is the length of the memory you own (useful for writing arrays, possibly for doing managed code in hardware?), and the permission must be an owner or group ID?
  
  I'm going to have to think about this.
  
  --
  "First they came for the slanderers and i said nothing."
37. Re:X32 by Mr+Z · 2012-07-01 12:07 · Score: 1
  
  Outside of the webbrowser, what hand-held applications do you see needing a 4GB virtual address space in a single process?
  As far as "embedded RAM", just how embedded do you mean? The latest generation OMAP chips allow for "Package-on-Package" LPDDR, for example. There's plenty of phones out there today sporting 1GB RAM, and I'm sure it's a matter of time before that's in the same package or maybe on the same die as the processor if it isn't already on some devices.
  (I admit ignorance of the absolute bleeding edge...)
  
  --
  Program Intellivision!
38. Re:X32 by tibit · 2012-07-01 14:09 · Score: 1
  
  Would a firewall/router, even one with a couple 10Gb NICs, really need that much memory? On a firewall/router, if it's not in the L2 cache (or its performance-wise equivalent), it better not be needed very often. I have an 8 port 100 Mbit switch with some firewall and routing functionality that has a whooping 256 kbytes of memory shared between code and data, and it performs very smoothly.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
39. Re:X32 by tibit · 2012-07-01 14:13 · Score: 1
  
  Who the fuck would sign-extend a pointer?!
  
  --
  A successful API design takes a mixture of software design and pedagogy.
40. Re:X32 by tibit · 2012-07-01 14:15 · Score: 1
  
  Are you serious that anyone sign-extends pointers, where there is no concept of a sign?! Why would you do that?? It makes no sense at all. Zero-extending: sure. Sign extending: that's major brain damage symptom right there.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
41. Re:X32 by Anonymous Coward · 2012-07-01 19:34 · Score: 0
  
  The problem is that you effectively have to have two different /usr/lib directories. With potentially two different sets of the libraries. Same consequently goes for the /usr/include. Compiling and running software occasionally becomes nightmarish experience.
  Debian is solving that problem the right way: multiarch. They even go beyond the 32/64 bit problem and will fully support cross-compilation, multiple ABIs and foreign arch emulation. See wiki.debian.org/Multiarch/TheCaseForMultiarch.
42. Re:X32 by TheRaven64 · 2012-07-01 20:22 · Score: 1
  
  No, permissions are things like execute, read, write. There are also some flags. For example, you can seal a capability and then you can't use it unless it is unsealed by a special form of jump instruction that can be used to implement protection boundaries. The architecture is being developed at Cambridge as part of a DARPA grant to see what you'd do if you were allowed to change anything about computing to improve security: it's a softcore running on an FPGA, running FreeBSD and (almost - I need the latest round of ISA revisions to be finished before I can make everything work) with an LLVM compiler, so we can change any aspect of the stack, from CPU, kernel, compiler and upwards.
  
  --
  I am TheRaven on Soylent News
43. Re:X32 by unixisc · 2012-07-01 21:06 · Score: 1
  
  I wasn't talking about anything needing 4GB. I was talking about discrete 4GB memory being the minimum available, in which case, the system would need x64 if it wanted to access all the available memory. Granted, it may not be there right now, but as we undergo process shrinks, don't expect 1GB, 2GB or even 4GB to be there forever. At which point, even embedded systems may be foreced to 4GB, unless the CPUs are themselves going to incorporate internal memory on die.
  MCMs or PoPs will not be an option, since the discrete memory of that desired density would be needed for that purpose. And if the memory manufacturers decide to jack up the prices b'cos they don't want to remain in that market but want to move everything to more profitable shrinks of the current products, then the embedded systems in question would be forced to migrate, since price is a key factor in their design decisions, more so than in complete computer systems. But I do see x32 remaining, as a result of CPUs including whatever they need in the cache itself - 4GB, 2GB, 1GB or whatever density they need.
44. Re:X32 by unixisc · 2012-07-01 21:20 · Score: 1
  
  What is the size of integer ALU ops?
45. Re:X32 by Mr+Z · 2012-07-01 21:24 · Score: 1
  
  x32 user-space programs require an x64 kernel. So, the OS would be able to access the full address space. The restriction is only that individual processes are limited to 4GB per process. The x32 mode is really more like a "small model 64-bit mode" than a "fancy 32-bit mode."
  So, even if it was "impossible" to build a system around a given chip / chipset with less than 8GB of RAM, an x32-based system would still be able to use all 8 GB from kernel space (since the kernel is x64), despite the fact no single x32 process can directly address[*] more than 4GB at once.
  ------------------
  [*] The important part here is directly address. A single x32 task can indirectly address as much memory as it likes, for example, by mmapping time-varying portions of a large file stored in tmpfs. All of that memory would still be in RAM so long as it all fit.
  
  --
  Program Intellivision!
46. Re:X32 by LingNoi · 2012-07-01 21:41 · Score: 1
  
  > The problem is that you effectively have to have two different /usr/lib directories.
  That's not a problem. Almost every distro has being moving to a separate lib folder per arch anyway. It's not a nightmare as it makes cross compilation easier.
47. Re:X32 by KiloByte · 2012-07-01 21:44 · Score: 2
  
  Who the fuck would sign-extend a pointer?
  The amd64 ABI requires this. Currently, only 48 bits are used, which makes it tempting to use the rest for some flags, etc. Back in the days, this was a problem on Amiga (forgot which models): old programs suddenly stopped working when newer CPUs stopped ignoring higher bits of the address. Thus, to make sure no one will have bad ideas like this, amd64 CPUs actually check if the unused bits are sign-extended, and smite offenders with an exception.
  And why are addresses signed? So there's a clear distinction between the address space of the user-mode program and the operating system.
  
  --
  The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
48. Re:X32 by martin-boundary · 2012-07-01 22:18 · Score: 1
  
  Embedded is about *cheap* systems. A cheap system always lags current systems in capability by several years and even decades. Such systems will *never* have X amount of RAM if X/2 amount of RAM can be supplied cheaply instead. The only way you'll get X amount of RAM standard on an embedded system your boss will give you is if if X is literally the lowest possible manufacture size at the time.
49. Re:X32 by Anonymous Coward · 2012-07-01 22:34 · Score: 0
  
  x86 isn't happening in mobile or microcontrollers, but there's a ton of them out there. If it's something with a large screen, odds are it's x86. Eg. most new cash registers I see run Windows XP Embedded, as does many high-end measurement instruments. It is my understanding x86 is also used a lot in industrial systems.
  
  The main proponent of X32 seem to be Intel themselves, but they are kind of desperate to compete head-on with ARM wherever they can. I'm guessing they consider X32 important for competing in the mobile market.
50. Re:X32 by Anonymous Coward · 2012-07-01 22:48 · Score: 0
  
  Of course all system binaries have to support all architectures supported by the system. You can introduce problems by manually installing third-party libraries that don't support all architectures, but this has successfully been tested in practice. Eg. OS X 10.6 transparently supported x86, x86-64 and ppc (via emulation), and a normal user never had to worry about it.
51. Re:X32 by TheRaven64 · 2012-07-02 00:03 · Score: 1
  
  64 bits. Currently no FPU (but that's being worked on...).
  
  --
  I am TheRaven on Soylent News
52. Re:X32 by snadrus · 2012-07-02 03:42 · Score: 1
  
  If a single boot program needs >4gb then it's a problem. If a mobile app needs > 4GB and that's not obvious at design-time, then it's a problem. Process-in-a-tab browsers should be safe. Anything higher-end is intended to be X64. For future design, this is yet another reason to keep programs of limited size & using multi-processing (using message passing) where such a choice can be made.
  
  --
  Science & open-source build trust from peer review. Learn systems you can trust.
53. Re:X32 by Brane2 · 2012-07-03 21:56 · Score: 1
  
  So you will go with small, cheap and economic ARM instead of x86.
  Why go for x86 and then worry about a couple bytes of _code_ ?
  One can be lover of sport cars and byu a Ferrari. Or one could be a prudent driver and go for Diesel car.
  But having Diesel Ferrari doesn't make you prudent performance driver, it makes you a moron.
54. Re:X32 by Anonymous Coward · 2012-07-05 11:56 · Score: 0
  
  I can see a common case for multiplying a pointer: indexing into arrays, where the address of the nth element is the address of the array plus the n times the size of the elements. Would you mess around with a bunch of different registers to do this calculation, from which you only need one value: a pointer, or would you do it more or less in place and discard the terms you don't need anymore as you go? In the latter case, you're going to need to multiply something that's going to end up being used as a pointer.
  Signed? A ptrdiff_t is signed.
55. Re:X32 by martin-boundary · 2012-07-06 14:29 · Score: 1
  
  No, it makes you an industrial scale player. Some of the CPUs used in modern cars can be 20 years old. Why? Because it's cheaper. Once the hardware costs have come down as much as possible, then it's up to the software to get the performance out of what's there. Software engineering costs only once for development, whereas hardware costs for each product that is manufactured. That's industrial scale reasoning.
56. Re:X32 by Brane2 · 2012-07-06 14:35 · Score: 1
  
  Show me one 20 year old x86 CPU, capable of executing 64-bit code.
  And then please explain why would someone with such configuration even go with glibc when there are other, much slimmer choices.
57. Re:X32 by martin-boundary · 2012-07-06 18:54 · Score: 1
  
  Because not all C library implementations are equivalent. It's quite common for a codebase to either fail to compile or not quite work just right when the "wrong" C library is used. Yes, that shouldn't happen and should be fixed, and no it doesn't get fixed.
  There's nothing wrong with glibc trying to be relevant on older hardware.
32-bit pointers in x32? by tchernobog · 2012-06-30 22:32 · Score: 1

The thing I keep wondering about x32 is, I have > 4 GB of RAM. If applications use 32-bit pointers, they will be able to address a virtual address space of max 4 GB. Of course, different processes can be mapped in different physical memory regions so having > 4GB of RAM still helps, but if you have memory-hungry apps (such as when you try to open complex Excel spreadsheets in LibreOffice), you will hit the 4 gigs limit. Uhm. Doesn't look as a win-win situation to me. Can someone shed some light on the subject?

--
42.
1. Re:32-bit pointers in x32? by Anonymous Coward · 2012-06-30 22:35 · Score: 0, Insightful
  
  if a spreadsheet program uses 4 Gig, find a different spreadsheet program. SERIOUSLY.
2. Re:32-bit pointers in x32? by tchernobog · 2012-06-30 22:42 · Score: 3, Interesting
  
  If you can point me to a spreadsheet program that opens both ODS and XSLX files, is feature complete with respect to the OOXML formula specification, doesn't cost more than 100 € and runs on GNU/Linux, I will consider it :-p. Of course, it should work *better* than LibreOffice.
  I ain't saying LibreOffice shines on this. I should really take the time to profile it and file a bug against it. But it works most of the time for me and gets the job done better than many other alternatives. The fact that it uses *a lot* of memory for really complex models (we are talking about a million computed cells or so, anyways), should be fixable in the long run.
  
  --
  42.
3. Re:32-bit pointers in x32? by TheRaven64 · 2012-06-30 22:46 · Score: 1
  
  If you are likely to need more than 4GB of RAM, don't compile in X32 mode. Of course, if some of your applications use X32 and some use X64 mode, then you'll need two copies of shared libraries loaded, and one extra copy of glibc is likely to offset all of the benefits of X32 mode unless you are running some very unusually pointer-heavy workloads in the X32 programs.
  
  --
  I am TheRaven on Soylent News
4. Re:32-bit pointers in x32? by gigaherz · 2012-06-30 22:47 · Score: 0
  
  I assumed the idea of x32 was to run it on top of a 64bit kernel? so that you could mix x64 apps with x32 and use pointers as big as necessary and not always 64bit, maybe I should read more on it to confirm...
5. Re:32-bit pointers in x32? by Anonymous Coward · 2012-06-30 22:49 · Score: 0
  
  "should be fixable in the long run". I love you optimism. I've got grey hair waiting for that to happen. And maybe as I'm getting older, I look back more fondly at the 8 bit days :)
6. Re:32-bit pointers in x32? by loufoque · 2012-07-01 01:22 · Score: 1
  
  You don't need to use x32 for this. It works fine with the usual i386/i686 ABI.
7. Re:32-bit pointers in x32? by loufoque · 2012-07-01 01:23 · Score: 2
  
  You've always been able to run 32-bit applications with a 64-bit kernel. x32 is not required for this.
8. Re:32-bit pointers in x32? by Richard_J_N · 2012-07-01 03:43 · Score: 2
  
  I hope Firefox doesn't try this trick. Although it doesn't need to use > 4GB, it does need support for leaking more than that. I have an 8GB swap partition, mostly to stop firefox crashing more than once a week!
9. Re:32-bit pointers in x32? by fatphil · 2012-07-01 04:34 · Score: 1
  
  It becomes horrifically slow after a few days, so crashing weekly is a positive feature!
  
  --
  Also FatPhil on SoylentNews, id 863
10. Re:32-bit pointers in x32? by Anonymous Coward · 2012-07-01 05:42 · Score: 0
  
  Not necessarily. It doesn't hurt to have another copy of a library in RAM nearly as much as it hurts to have bloated code and data dragged through the processor cache. The single-process code density is more important for cache behavior than the other processes in the same system, though with increasing core/smp densities and shared caches, this is getting harder to calculate (a bit like NUMA already caused for 15+ years).
  It would be nice to see some real quantitative analysis of the benefits for real software and contemporary CPUs. I just bought 24GB of DDR3 ECC RAM for my workstation for $200, but I cannot so easily upgrade the Core i7 CPU cache. I still observe that a lot of my C code experiments perform better compiled with -Os rather than -O3 in gcc, suggesting that i-cache size is still a problem...
  It is funny though, that we had this division on SGI Irix with MIPS processors back in the 90s. The C compiler had three pointer modes available: o32 (like traditional i686), n32 (like this new X32 mode), and 64 (like x86_64). To account for this and other special ABI choices like which threading/locking system or which low-level message passing system was pre-processed into the code, we had to use an ABI "flavoring" model in our software builds, encoding a cross product of the pointer modes and other options that required linking with libraries compiled with the same combination.
11. Re:32-bit pointers in x32? by Anonymous Coward · 2012-07-01 10:04 · Score: 0
  
  So really what you're saying is: Linux is on its final journey to being as irrelevant as SGI and Irix? :D
12. Re:32-bit pointers in x32? by LingNoi · 2012-07-01 21:46 · Score: 1
  
  You're missing the important bit from the parent's post
  > use pointers as big as necessary
  By reducing the pointer sizes you can fit more into the cache which means less cache misses. This means faster processing.
13. Re:32-bit pointers in x32? by KiloByte · 2012-07-01 21:59 · Score: 1
  
  There is no such thing as an x32 kernel -- it's merely an extension to the amd64 one. Thus, the same kernel can run amd64, i386 and x32 code.
  If all of your userland uses x32, the kernel still uses full 64 bits. Thus, as long as no single process uses more than 2 (3?) GB of address space, you can have as much physical and virtual memory as you want with no loss.
  This said, except for some artificial edge cases, the gains don't outweigh extra complexity of having two incompatible architectures running together.
  
  --
  The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
14. Re:32-bit pointers in x32? by loufoque · 2012-07-01 22:00 · Score: 1
  
  I'm not missing anything. Your comment, albeit replying to mine, has nothing to do with it.
15. Re:32-bit pointers in x32? by KiloByte · 2012-07-01 22:17 · Score: 1
  
  You don't need to use x32 for this. It works fine with the usual i386/i686 ABI.
  Except that the i386/i686 ABI is ridiculously crippled. For example, it is register-starved (EAX, EBX, ECX, EDX, ESI, EDI, EBP... and that's it) -- while the processor has plenty more you can't use. Or, you can't use SSE math. Or, you can't have PIC code without a significant penalty. Or, ...
  
  --
  The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
16. Re:32-bit pointers in x32? by loufoque · 2012-07-01 23:01 · Score: 1
  
  You can use SSE math (though it's not enabled by compilers by default), you just can't pass scalar floating-point arguments in SSE registers.
  Also this is a bit irrelevant to what the message I replied to said. The poster asked whether multiple x32 processes could still use more than 4GB. I replied that it is already the case with i386 processes running with an amd64 kernel (actually, it's also even possible with a 32-bit kernel with PAE enabled).
17. Re:32-bit pointers in x32? by gigaherz · 2012-07-02 21:24 · Score: 0
  
  I know you can set up an x86 userland on a x64 kernel (although it can be somewhat annoying to do it right sometimes). The X32 ABI is meant to replace the x86 ABI in that situation, because it offers advantages without any drawbacks. Without X32, you either use the full x64, including the pointer bloat and long-integer-is-64bit issue (when compiling unaware code), or you stick to plain old x86, with only 6 integer general-purpose registers and only 8 FP/SIMD registers. The idea of X32 is to get all the advantages of x64 (extra registers, most notably) into a 32bit process, avoiding pointers and longs growing unnecessarily in size, which is not ideal for database daemons and similar software with high memory usage, but can be a really nice boost for applications that do intensive work on small data sets (specially apps that have a lot of references to data/virtual methods/callbacks).
18. Re:32-bit pointers in x32? by gigaherz · 2012-07-02 21:27 · Score: 0
  
  I always forget this site ignores line feeds in comments and expects me to add <br>s to the comment myself.
  This is how it was meant to look like (if I had noticed my failing before I pressed submit):
  I know you can set up an x86 userland on a x64 kernel (although it can be somewhat annoying to do it right sometimes). The X32 ABI is meant to replace the x86 ABI in that situation, because it offers advantages without any drawbacks.
  Without X32, you either use the full x64, including the pointer bloat and long-integer-is-64bit issue (when compiling unaware code), or you stick to plain old x86, with only 6 integer general-purpose registers and only 8 FP/SIMD registers.
  The idea of X32 is to get all the advantages of x64 (extra registers, most notably) into a 32bit process, avoiding pointers and longs growing unnecessarily in size, which is not ideal for database daemons and similar software with high memory usage, but can be a really nice boost for applications that do intensive work on small data sets (specially apps that have a lot of references to data/virtual methods/callbacks).
Remove support for anything but ELF binary format by Anonymous Coward · 2012-06-30 23:53 · Score: 2, Insightful

So, one of the things that has changed in this latest release is that only the ELF binary format is supported. What does this actually mean though? I guess it means they dropped a.out and COFF, but does anyone still use those?
Is this particularly a problem, perhaps for embedded *nix? (I.e. is ELF bigger or worse in resource terms compared to the other two formats?)
As far as I can tell from reading Wikipedia, ELF is much the better format generally, but is it worse in some situations?
Actually, did GLIBC support MS Windows PE format before now (a modified form of COFF)? Or what about the Mac Mach-O format?
GCC can build different file formats, is that also going to change?
Re:Remove support for anything but ELF binary form by kthreadd · 2012-07-01 00:05 · Score: 2

Microsoft has its own compiler and Apple has moved away from it, maintaining support when they are doing much better themselves is probably not a high priority.
Re:Remove support for anything but ELF binary form by Goaway · 2012-07-01 00:15 · Score: 2, Informative

Neither Windows nor Mac OS X uses glibc, so it is not a problem. gcc uses the appropriate libc for the platform.
PE in Wine by tepples · 2012-07-01 01:16 · Score: 2

Actually, did GLIBC support MS Windows PE format before now
On Linux systems, the PE format is handled by Wine if I remember correctly.
Re:Remove support for anything but ELF binary form by peppepz · 2012-07-01 01:58 · Score: 4, Informative

So, one of the things that has changed in this latest release is that only the ELF binary format is supported. What does this actually mean though?
That you can no longer run Linux executables based on the a.out format. The a.out format was phased out in 1996.

but does anyone still use those?
No, nobody does.

Is this particularly a problem, perhaps for embedded *nix? (I.e. is ELF bigger or worse in resource terms compared to the other two formats?)
No, because people stopped using the a.out format to store Linux executables long before Linux started appearing on embedded devices. On a side note, many MCUs use ELF as their preferred executable format, so I don't think there's a "size" problem with it.

As far as I can tell from reading Wikipedia, ELF is much the better format generally, but is it worse in some situations?
No, that's why nobody has used it since 1997. Even if it was competitive with ELF, and it isn't, maintaining two different binary formats to contain the executables of the same OS would be overkill - especially almost 20 years after the first format has been deprecated.

Actually, did GLIBC support MS Windows PE format before now (a modified form of COFF)? Or what about the Mac Mach-O format?
GCC can build different file formats, is that also going to change?
Glibc is only for running Linux or Hurd (I think) executables. These OSes only use ELF. Glibc never ran on Windows or Mac. GCC is a completely separate project, and of course it supports generating executables for Windows, hence it will target PE/COFF of course on those OSes. There is no relationship with Glibc.
Re:Remove support for anything but ELF binary form by Anonymous Coward · 2012-07-01 02:20 · Score: 0

On windows, cygwin gcc DOES use glibc, though it is a modified Cygwin version.
Re:Remove support for anything but ELF binary form by cpghost · 2012-07-01 02:27 · Score: 1

No, nobody does.
You can't be sure. But even if there are, something like the reverse of elftoaout could probably be written relatively easily.

--
cpghost at Cordula's Web.
Re:Remove support for anything but ELF binary form by peppepz · 2012-07-01 02:44 · Score: 2

Moreover, support for a.out is still there in the kernel. Assuming that you can find some a.out binaries today, and have a reason to run one of them on a contemporary system, you can still do it by having an old libc around. Different versions of libc can coexist on the same system.
Has this removed the need for EGlibc? by Anonymous Coward · 2012-07-01 03:00 · Score: 1

This has some nice new features, and --enable-obsolete-rpc will prevent distributions needing to patch the headers back in if they actually want to support NFS, but has this latest release fixed the problems that spawned EGlibc in the first place?
My understanding is that EGlibc happened because Glibc didn't accept patches for clearly wrong behaviour (expecting /bin/sh to be /bin/bash for example) and didn't look after the embedded architecture ports well enough, but with the change in leadership and the hard-float EABI changes, can we merge back into Glibc?
1. Re:Has this removed the need for EGlibc? by Trepidity · 2012-07-01 04:29 · Score: 4, Informative
  
  The goal is to merge eglibc back into glibc, yes. After the previous glibc steering committee disbanded, it switched to being run by an informal three-person committee, one of whom (Joseph Myers) is also one of the lead maintainers of eglibc, so the two projects' leadership are no longer at odds. And Myers has suggested that the goal is to start moving eglibc changes over into the main glibc branch.
  
  --
  10 PRINT CHR$(205.5+RND(1)); : GOTO 10
2. Re:Has this removed the need for EGlibc? by busyqth · 2012-07-01 04:37 · Score: 1
  
  My understanding is that EGlibc happened because Glibc didn't accept patches for clearly wrong behaviour (expecting /bin/sh to be /bin/bash for example) and didn't look after the embedded architecture ports well enough
  Yeah that was Drepper saying he didn't care about effeminate toy architectures like ARM, because glibc was being developed for manly real architectures like x86.
3. Re:Has this removed the need for EGlibc? by Hal_Porter · 2012-07-01 10:50 · Score: 1
  
  Here's a funny post where he compares people wanting support for minority architectures to 'violent minorities', i.e. terrorists.
  http://udrepper.livejournal.com/7326.html
  
  --
  echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Re:Remove support for anything but ELF binary form by Anonymous Coward · 2012-07-01 04:34 · Score: 0

An a.out binary will need libc-4 (a modified version of glibc-1). It won't work with libc-5 (also a modified version of glibc-1, but ELF instead of a.out) or libc-6 (which is glibc-2). So you have to have that old libc-4 around regardless.
Re:Remove support for anything but ELF binary form by Anonymous Coward · 2012-07-01 08:57 · Score: 1

Glibc is only for running Linux or Hurd (I think) executables.
Last I checked, Glibc had ports for Linux, Hurd, kFreeBSD, OpenSolaris and Syllable. They all use ELF, though.
ASLR by Anonymous Coward · 2012-07-02 09:45 · Score: 0

Anything dealing with untrusted data needs 64-bit for security. For example, a text message is untrusted data. It could contain a 0-day exploit.
you need address space, not actual memory by Anonymous Coward · 2012-07-02 09:48 · Score: 0

ASLR (Address Space Layout Randomization) is a critical security feature. Really you'd want more than 64 bits for that firewall. 32 is a joke.