Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Programs can still use 64-bit integers via long long, int64_t or intmax_t (and I'd guess intfast_t too?).
Pettenò: Debunking x32 myths
Posted Jun 26, 2012 20:31 UTC (Tue) by butlerm (subscriber, #13312)
The struct timespec / timeval issues would go away, for example. The number of x32 specific syscalls required would go down. Problems with ioctl structure differences would be greatly reduced, as would problems porting LP64 code in general.
32 bit longs are the wave of the past. IA-32 is rapidly becoming obsolete. Why any special effort would be made to retain compatibility with ILP32 rather than with LP64 (as much as possible) is a mystery to me. The whole thing is going to run on an LP64 kernel with a parallel LP64 userspace in many cases, after all. 32 bit pointers can be a major improvement. 32 bit longs on a 64 bit architecture on the other hand just make life difficult without any substantive gains, so far as I can tell.
In any case ILP32 was a mistake. It should have been L64P32 to begin with.
Posted Jun 27, 2012 1:50 UTC (Wed) by slashdot (guest, #22014)
Again, almost all software supports 32-bit compilation, and since all existing relevant 32-bit ABIs (i.e. x86 and arm) are ILP32, it would be insane to use a different size for "long" than the rest of the 32-bit world.
New programs should never use the "long" keyword anyway and should instead use the typedefs in <stdint.h> which actually have a defined useful meaning.
Posted Jun 27, 2012 2:51 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
So would you like to have "int" to be 18 bits or 36 bits in length?
Posted Jun 27, 2012 4:30 UTC (Wed) by cmccabe (guest, #60281)
It would be nice for the stdint.h types to be built-in, and more widely used in some cases, but it's really not a big deal. There are always higher-level languages you can use if you don't want to deal with this stuff. Some of them even have unlimited length integers! The 70s are over, you know.
Posted Jun 27, 2012 13:49 UTC (Wed) by nix (subscriber, #2304)
char is "the smallest addressable unit" (in practice always 1 byte)
Posted Jun 27, 2012 14:22 UTC (Wed) by mansr (guest, #85328)
Posted Jun 27, 2012 21:27 UTC (Wed) by nix (subscriber, #2304)
Posted Jun 27, 2012 21:45 UTC (Wed) by mansr (guest, #85328)
Posted Jun 29, 2012 4:57 UTC (Fri) by sethml (subscriber, #8471)
Posted Jun 29, 2012 12:11 UTC (Fri) by nix (subscriber, #2304)
Posted Jun 27, 2012 8:38 UTC (Wed) by dgm (subscriber, #49227)
There was a reason for that. The intention was that they mapped cleanly to the word sizes of the underlaying architecture.
> despite the fact that there is no way to write a portable, correct and fast programs in such a language.
Absurd. C was invented for exactly that. The original UNIX code was written in PDP-7 assembly (a 18-bit machine), and later rewritten in C and ported to the PDP-11 (a 16-bit one). The first C version of UNIX was portable, correct _and_ fast. And all that in a newborn language that would be considered "crude" compared to today's C.
Posted Jun 28, 2012 17:45 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds