| |||||||||||||
Pettenò: Debunking x32 mythsPettenò: Debunking x32 mythsPosted Jun 27, 2012 1:50 UTC (Wed) by slashdot (guest, #22014)In reply to: Pettenò: Debunking x32 myths by butlerm Parent article: Pettenò: Debunking x32 myths
The mistake was introducing the "char", "short", "int" and "long" keywords in C without specifying their meaning, despite the fact that there is no way to write a portable, correct and fast programs in such a language.
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.
(Log in to post comments)
Pettenò: Debunking x32 myths Posted Jun 27, 2012 2:51 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>The mistake was introducing the "char", "short", "int" and "long" keywords in C without specifying their meaning, despite the fact that there is no way to write a portable, correct and fast programs in such a language.
So would you like to have "int" to be 18 bits or 36 bits in length?
Pettenò: Debunking x32 myths Posted Jun 27, 2012 4:30 UTC (Wed) by cmccabe (guest, #60281) [Link]
The C standard DOES specify the meaning of "char," "short," "int," and so forth. char is "the smallest addressable unit" (in practice always 1 byte), short and int are at least 2 bytes, and long is at least 4 bytes. It may not seem important to you now, but saving a few bytes definitely mattered back in the 1970s, when C was designed.
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.
Pettenò: Debunking x32 myths Posted Jun 27, 2012 13:49 UTC (Wed) by nix (subscriber, #2304) [Link] char is "the smallest addressable unit" (in practice always 1 byte)It's not a matter of 'in practice'. char is, by definition, one byte long. In closely adjacent paragraphs of every C Standard ever published, sizeof() is defined as yielding 'the size (in bytes) of its operand', and then sizeof (char) is defined as returning 1. If you change sizeof (char), you change the definition of a byte on that platform's C ABI.
Pettenò: Debunking x32 myths Posted Jun 27, 2012 14:22 UTC (Wed) by mansr (guest, #85328) [Link] Whilechar is always and by definition one byte, a byte is not always one octet.
Pettenò: Debunking x32 myths Posted Jun 27, 2012 21:27 UTC (Wed) by nix (subscriber, #2304) [Link]
Exactly. Of course, on any reasonable platform these days (other than tiny DSPs normally not programmed in C at all), a byte is one octet, but in olden days this was not true. Of course by the time C was standardized at all it was pretty widely true, and by the time of C99 it was universal. But it wasn't always so.
Pettenò: Debunking x32 myths Posted Jun 27, 2012 21:45 UTC (Wed) by mansr (guest, #85328) [Link]
POSIX does mandate 8-bit bytes. As for those DSPs, a lot of code running on them is actually written in C. Only the critical parts are typically done in assembly.
Pettenò: Debunking x32 myths Posted Jun 29, 2012 4:57 UTC (Fri) by sethml (subscriber, #8471) [Link]
Check out the TI C2000 / TMS320 architecture. I've written a lot of C++ with 16-bit chars on that architecture over the past few years. Yes, it's a bit of a brain-dead architecture, but there are definitely archs with non 8 bit chars around still.
Pettenò: Debunking x32 myths Posted Jun 29, 2012 12:11 UTC (Fri) by nix (subscriber, #2304) [Link]
At least that's a multiple of 8. Are there any 9/18/36-bit bytes around these days? I hope not :}
Pettenò: Debunking x32 myths Posted Jun 27, 2012 8:38 UTC (Wed) by dgm (subscriber, #49227) [Link]
> The mistake was introducing the "char", "short", "int" and "long" keywords in C without specifying their meaning.
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.
Pettenò: Debunking x32 myths Posted Jun 28, 2012 17:45 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
Of course you say "use <stdint.h>" *now*. It wasn't officially part of C until C99 as I recall, and many codebases have code that's noticeably older than that. Furthermore, just because it was in C99 didn't mean all compilers had it in 1999. (Although I'll grant many had it before then.)
|
|||||||||||||