Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #93363 > unrolled thread
| Started by | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| First post | 2016-09-10 14:23 -0700 |
| Last post | 2016-09-13 07:47 -0700 |
| Articles | 20 on this page of 171 — 17 participants |
Back to article view | Back to comp.lang.c
Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-10 14:23 -0700
Re: Portable 16 bit binary integer write Barry Schwarz <schwarzb@dqel.com> - 2016-09-10 17:11 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 07:00 -0700
Re: Portable 16 bit binary integer write Richard Damon <Richard@Damon-Family.org> - 2016-09-13 08:41 -0400
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-13 06:24 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-13 16:19 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-13 10:20 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-13 11:07 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-13 20:47 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-14 08:24 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-15 12:17 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-15 11:27 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 09:03 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-15 11:21 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-15 18:39 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 12:26 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-15 23:12 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 16:17 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-15 18:35 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 11:10 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 08:43 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 19:59 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 13:34 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-16 16:23 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 15:31 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-16 19:06 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 23:27 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-17 15:04 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-17 20:35 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 00:09 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-18 19:36 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 15:29 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-19 01:20 +0100
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-18 09:48 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 19:38 +0200
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-18 15:33 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 13:58 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 14:15 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-18 23:15 +0100
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 15:46 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-19 17:03 +1200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 07:40 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 10:54 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 10:51 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 22:03 +0200
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 15:44 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-20 09:02 +0200
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-19 21:12 +0100
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 15:58 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 09:49 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 02:37 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 13:20 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 06:22 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-19 12:46 +0100
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 16:20 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 07:32 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 11:26 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 09:10 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 09:33 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 11:54 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 22:14 +0200
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 22:12 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 14:32 -0700
Re: Portable 16 bit binary integer write Robert Wessel <robertwessel2@yahoo.com> - 2016-09-19 22:58 -0500
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-20 09:45 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-20 07:49 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-20 19:43 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-20 11:15 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 22:36 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 21:30 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-22 23:58 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-23 19:45 +1200
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 08:17 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-28 09:59 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-29 07:59 +1300
Re: Portable 16 bit binary integer write Ike Naar <ike@iceland.freeshell.org> - 2016-09-28 19:26 +0000
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-28 12:37 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-09 03:46 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 13:53 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-21 21:03 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-21 22:23 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-22 08:09 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 10:31 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-23 10:56 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 08:03 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-30 07:39 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-22 09:49 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-22 08:34 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-22 17:44 +0100
Re: Portable 16 bit binary integer write Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-22 17:16 +0000
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-22 18:26 +0100
Re: Portable 16 bit binary integer write Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-22 17:33 +0000
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-23 10:23 +0200
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-23 13:43 +0100
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-23 14:58 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-22 18:14 -0700
Re: Portable 16 bit binary integer write luser droog <luser.droog@gmail.com> - 2016-09-22 20:28 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-23 00:12 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-22 10:57 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-23 10:18 +0200
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 11:48 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-23 15:58 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 08:21 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-30 07:42 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-23 23:38 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-24 11:42 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-24 14:13 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-24 23:03 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-25 11:29 +0100
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 14:02 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 15:17 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 16:52 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 13:59 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 15:13 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 15:50 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 08:13 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-24 16:06 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-24 11:53 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-24 14:23 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 14:16 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 15:18 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 16:39 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 23:33 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-26 02:08 -0700
Re: Portable 16 bit binary integer write Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 10:25 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-26 03:05 -0700
Re: Portable 16 bit binary integer write Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 11:09 +0100
Re: Portable 16 bit binary integer write "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-26 09:29 -0700
Re: Portable 16 bit binary integer write Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 17:37 +0100
Re: Portable 16 bit binary integer write "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-26 12:29 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-26 11:12 +0100
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-26 13:19 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-26 18:34 -0700
Re: Portable 16 bit binary integer write Ike Naar <ike@iceland.freeshell.org> - 2016-09-27 06:43 +0000
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-27 00:51 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-27 08:42 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-22 11:40 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 10:00 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-23 10:34 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 08:13 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 00:06 +0200
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-17 17:32 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 15:57 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-17 20:46 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 16:08 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 10:03 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-17 23:59 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-17 16:49 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-18 01:19 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 07:16 -0700
Re: Portable 16 bit binary integer write "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 10:19 -0400
Re: Portable 16 bit binary integer write luser droog <luser.droog@gmail.com> - 2016-09-18 13:26 -0700
Re: Portable 16 bit binary integer write "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 17:04 -0400
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 01:21 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-15 12:07 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 00:32 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 16:30 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-15 18:35 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-15 22:00 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 22:17 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-16 18:12 +1200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 00:46 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-16 10:23 +0100
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-16 10:59 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 04:13 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 08:58 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 10:16 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-16 09:11 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 20:14 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 20:37 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-13 07:47 -0700
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-19 22:14 +0200 |
| Message-ID | <nrpgvq$d3u$2@dont-email.me> |
| In reply to | #93813 |
On 19/09/16 20:54, Keith Thompson wrote: > Keith Thompson <kst-u@mib.org> writes: > [...] >> I haven't looked into the relative performance of 32-bit and 64-bit >> arithmetic on modern 64-bit systems. It seems plausible (but is quite >> possibly wrong) that an N-bit system will perform most efficiently on >> N-bit data. > [...] > > One data point of questionable significance: the GNU C library > for x86_64 uses 64 bits for int_fast16_t and int_fast32_t. > (The <stdint.h> header is provided by glibc, not by gcc, and it > does this if __WORDSIZE == 64.) > That's interesting - I should probably have read this post before making my previous post! We can certainly conclude that we would want the C standards folks to investigate thoroughly before making any decisions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-19 22:12 +0200 |
| Message-ID | <nrpgro$d3u$1@dont-email.me> |
| In reply to | #93809 |
On 19/09/16 20:26, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> Perhaps the more significant change is that currently the C standards >> document are each written to succeed and replace previous versions. >> There is only one current valid ISO C standard - the version known as >> C11. A "C compiler" made today has to follow that version of the >> standard. If a future C standard dropped support for some older >> hardware, then there would really need to be a fork in the standards - >> so that C11 would still be a valid standard for old systems, with C20 >> (or whatever) going onward for modern ones. > > The previous editions of the standard are officially obsolete in the > eyes of ISO. That doesn't prevent anyone from using them. I'm not > convinced that a formal fork would be necessary. Implementations > could still claim C99 or C11 conformance. > > [...] > >> No, 64-bit int is not a sensible idea (IMHO). Extended integer types >> could solve some of the problems it would create, but at significant >> effort to toolchain authors, library writers (someone has to make a >> "printf" that supports the different sizes in some way), and significant >> inconvenience in data exchange. It is data exchange (by network >> protocols, file formats, etc.) that drives the need for standardisation >> here. > > N1570 6.2.5p5: > > A "plain" int object has the natural size suggested by the > architecture of the execution environment [...]. > > For a 64-bit target, surely 64 bits is "the natural size suggested by > the architecture". I don't think "natural size" is well enough defined here for this to be determined. Certainly 64-bit ints is a reasonable match according to the standards - but (baring things like Crays) the same cpus can work equally "naturally" with 32-bit values or 16-bit values (or even 8-bit values). 32-bit seems to be a value that works very well in practice. > >> And what is to be gained with 64-bit int? There is some hardware that >> can operate more efficiently on a 64-bit object than a 32-bit object - >> but such hardware is niche or obsolete (i.e., old Cray machines), and >> therefore excluded. Is there any software benefit in having 64-bit int? >> I think not - it is rare indeed that you actually need such a large >> integer type, and C already has perfectly good ones that you can use in >> that case (int64_t and long long int). > > I haven't looked into the relative performance of 32-bit and 64-bit > arithmetic on modern 64-bit systems. It seems plausible (but is quite > possibly wrong) that an N-bit system will perform most efficiently on > N-bit data. It is wrong, for most systems, at least for most purposes. Most cpus can handle arithmetic and other operations between registers equally well with all sizes up to their bit width. Loads and stores may be more efficient with certain sizes - usually smaller sizes means less memory bandwidth and more efficient use of caches. Some operations, such as multiplication and in particular division, may be slower for bigger sizes. There are some 32-bit architectures that are a little slower for some 8-bit and 16-bit operations - such as the DEC alpha (I think) and older ARM designs. I'd class these devices as obsolete, however. > > On the other hand, I'm sure designers have expended some effort to make > 32-bit arithmetic efficient -- largely *because* C implementations > typically have 32-bit int. It's a chicken and egg situation - most cpus are designed with a view to running C efficiently. > >> It is not a coincidence that the only systems with 64-bit int are >> ancient, and pre-date the common usage of 64-bit processors. > > Are there *no* modern 64-bit processors on which 64-bit arithmetic is > faster than 32-bit arithmetic? Can you be sure there will be no such > processors in the future? > There are none that I know of - but I don't know them all, and I certainly don't know so much about future processors!
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-19 14:32 -0700 |
| Message-ID | <5299a08d-ac1e-4a51-a672-216c9d6e3516@googlegroups.com> |
| In reply to | #93827 |
On Monday, September 19, 2016 at 3:12:53 PM UTC-5, David Brown wrote:
> There are some 32-bit architectures that are a little slower for some
> 8-bit and 16-bit operations - such as the DEC alpha (I think) and older
> ARM designs. I'd class these devices as obsolete, however.
The 32-bit ARM processors have no operations other than loads and stores
that operate on values smaller than 32 bits, and they're hardly obsolete.
If anything, it is the idea that processors should operate on types smaller
than their natural word size (except for loads and stores) which is obsolete.
The DEC Alpha had no operations smaller than 64 bits, other than 32-bit
loads and stores. Updating an 8-bit or 16-bit value in memory would
require a read-modify-write sequence.
When using a decent compiler, operations on values smaller than 32 bits
should generally not be much slower than operations on 32-bit values,
since the processor need not clip off the upper bits except in cases where
their values would actually matter. Given, e.g.
int32_t test(void)
{
int16_t sum=0;
for (int i=0; i<100000; i++)
sum+=someFunction();
return sum;
}
a compiler would be required to generate a sign-extension instruction
to clip the "sum" value to 16 bits (note that storing an out-of-range
value to an "int16_t" is required to either yield an Implementation-
Defined value or *consistently* raise an implementation-defined signal;
it's not UB) but there's no need to perform the truncation on every
pass through the loop. The compiler could compute the sum as a 32-bit
value without generating any code to truncate it at all during the loop,
and simply truncate the value at the end. The 32-bit register used to
compute the sum might overflow, but if the compiler doesn't try to use
that as an excuse to perform UB-based optimization the overflow in the
upper bits shouldn't matter since anything above the bottom 16 bits will
be ignored anyhow.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-09-19 22:58 -0500 |
| Message-ID | <vac1ubt89cd6l48eua4qh7tgv0crk6af3p@4ax.com> |
| In reply to | #93831 |
On Mon, 19 Sep 2016 14:32:29 -0700 (PDT), supercat@casperkitty.com wrote: >On Monday, September 19, 2016 at 3:12:53 PM UTC-5, David Brown wrote: >> There are some 32-bit architectures that are a little slower for some >> 8-bit and 16-bit operations - such as the DEC alpha (I think) and older >> ARM designs. I'd class these devices as obsolete, however. > >The 32-bit ARM processors have no operations other than loads and stores >that operate on values smaller than 32 bits, and they're hardly obsolete. >If anything, it is the idea that processors should operate on types smaller >than their natural word size (except for loads and stores) which is obsolete. > >The DEC Alpha had no operations smaller than 64 bits, other than 32-bit >loads and stores. Updating an 8-bit or 16-bit value in memory would >require a read-modify-write sequence. The omission of byte loads and stores was (fairly) quickly recognized as an error, and Alpha added byte loads and stores in the second iteration. ARM has the group of Load and Store Word or Unsigned Byte instructions, in addition to a number of other instructions that reference memory (Swap Byte, Store with Translation).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-20 09:45 +0200 |
| Message-ID | <nrqpdv$egf$1@dont-email.me> |
| In reply to | #93831 |
On 19/09/16 23:32, supercat@casperkitty.com wrote: > On Monday, September 19, 2016 at 3:12:53 PM UTC-5, David Brown wrote: >> There are some 32-bit architectures that are a little slower for some >> 8-bit and 16-bit operations - such as the DEC alpha (I think) and older >> ARM designs. I'd class these devices as obsolete, however. > > The 32-bit ARM processors have no operations other than loads and stores > that operate on values smaller than 32 bits, and they're hardly obsolete. The older and (IMHO obsolete) ARM devices I was referring to have no operations for loading or storing 8-bit or 16-bit values. So storing a value smaller than 32-bit was slow - the processor would load in the previous 32-bit block, use masking and shifting to insert the new 8 or 16 bit value, then store the 32-bit block again. Modern ARMs are quite happy with operations on smaller values. The reason they don't have "8-bit add" instructions is that they are not needed - they only have 8-bit and 16-bit instructions when such instructions are different from the 32-bit instructions. (There would be a difference in the way some flags are updated, but that is usually irrelevant, and it is not worth the cost in instruction code space.) Where smaller size matters, ARMs support them. They even have instructions for treating a 32-bit register as a pair of 16-bit values or a quad of 8-bit values that can be added to another pair or quad as a single operation. > If anything, it is the idea that processors should operate on types smaller > than their natural word size (except for loads and stores) which is obsolete. Modern processors and modern compilers work together to give you efficient code regardless of the size of the operand.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-20 07:49 -0700 |
| Message-ID | <734d2b06-c5e8-4b56-b381-a97a0d522657@googlegroups.com> |
| In reply to | #93841 |
On Tuesday, September 20, 2016 at 2:45:18 AM UTC-5, David Brown wrote: > Modern ARMs are quite happy with operations on smaller values. The > reason they don't have "8-bit add" instructions is that they are not > needed - they only have 8-bit and 16-bit instructions when such > instructions are different from the 32-bit instructions. (There would > be a difference in the way some flags are updated, but that is usually > irrelevant, and it is not worth the cost in instruction code space.) On a 32-bit two's-complement system, given "int16_t x,y,z;" the behavior of x=y+z; will be defined in cases where the result would overflow a 16-bit value, and the lack of 16-bit "add" instruction would require the addition of an extra instruction (or, on the ARM7-TDMI, two instructions) to yield the Standard-mandated result. Using "int32_t x,y,z;" would be faster. If values will be stored in RAM rather than registers, however, using int16_t will be just as fast as int32_t, and if caching is involved may be faster. What would be optimal for efficiency would be a type that allowed a compiler to arbitrarily use 16 or 32 bits at its convenience based upon context, but the C Standard does not allow for such types.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-20 19:43 +0200 |
| Message-ID | <nrrsg1$bpm$1@dont-email.me> |
| In reply to | #93856 |
On 20/09/16 16:49, supercat@casperkitty.com wrote: > On Tuesday, September 20, 2016 at 2:45:18 AM UTC-5, David Brown wrote: >> Modern ARMs are quite happy with operations on smaller values. The >> reason they don't have "8-bit add" instructions is that they are not >> needed - they only have 8-bit and 16-bit instructions when such >> instructions are different from the 32-bit instructions. (There would >> be a difference in the way some flags are updated, but that is usually >> irrelevant, and it is not worth the cost in instruction code space.) > > On a 32-bit two's-complement system, given "int16_t x,y,z;" the behavior > of x=y+z; will be defined in cases where the result would overflow a 16-bit > value, and the lack of 16-bit "add" instruction would require the addition > of an extra instruction (or, on the ARM7-TDMI, two instructions) to yield > the Standard-mandated result. The standard does not mandate behaviour here - the conversion of an int32_t to an int16_t is implementation defined (if the value does not fit). Sometimes this will mean an extra "truncate" instruction is needed. But it is rare - or at least, it is rare that it will have a significant effect. One does not often write code that does nothing but add a couple of numbers. And if the result is going to be stored in memory, the truncation happens automatically as part of the store instruction. > Using "int32_t x,y,z;" would be faster. If > values will be stored in RAM rather than registers, however, using int16_t > will be just as fast as int32_t, and if caching is involved may be faster. > > What would be optimal for efficiency would be a type that allowed a compiler > to arbitrarily use 16 or 32 bits at its convenience based upon context, but > the C Standard does not allow for such types. > Yes, the C standard allows the compiler the freedom to use whatever type suits it - as long as the observable behaviour matches the behaviour given in the code. It is unlikely that a compiler will choose to store a value as 16-bit in memory when the code says 32-bit, but it is conceivable. It is certainly possible for the compiler to work with 32-bit values internally even though the code says 16-bit, as long as the results are correct.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-20 11:15 -0700 |
| Message-ID | <9bf8c399-09ec-4c61-b14e-5a1f5d34b0cb@googlegroups.com> |
| In reply to | #93863 |
On Tuesday, September 20, 2016 at 12:43:43 PM UTC-5, David Brown wrote: > On 20/09/16 16:49, supercat wrote: > The standard does not mandate behaviour here - the conversion of an > int32_t to an int16_t is implementation defined (if the value does not fit). The Standard mandates that an implementation must compute a value in consistent fashion or else signal in consistent fashion. The cheapest consistent fashion on many ARM chips would be sign extension. > Sometimes this will mean an extra "truncate" instruction is needed. But > it is rare - or at least, it is rare that it will have a significant > effect. One does not often write code that does nothing but add a > couple of numbers. And if the result is going to be stored in memory, > the truncation happens automatically as part of the store instruction. The straightforward code-generation cost isn't huge, so the payoff from eliminating it wouldn't be huge either, but it should be relatively low hanging fruit. Since compiler writers are pushing aggressive optimizers to pursue optimizations with even smaller payoffs, I would think that the payoff should be worth pursuing.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-19 22:36 -0700 |
| Message-ID | <119bd09a-db65-4c7b-96d7-c8055c7db355@googlegroups.com> |
| In reply to | #93827 |
On Monday, September 19, 2016 at 9:12:53 PM UTC+1, David Brown wrote: > > > For a 64-bit target, surely 64 bits is "the natural size suggested by > > the architecture". > > I don't think "natural size" is well enough defined here for this to be > determined. Certainly 64-bit ints is a reasonable match according to > the standards - but (baring things like Crays) the same cpus can work > equally "naturally" with 32-bit values or 16-bit values (or even 8-bit > values). 32-bit seems to be a value that works very well in practice. > int needs to be able to index a normal array, but not necessarily one set up in subsidiary mass memory of some description.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-22 21:30 -0700 |
| Message-ID | <kfnvaxndyqz.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93836 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, September 19, 2016 at 9:12:53 PM UTC+1, David Brown wrote: >> >>> For a 64-bit target, surely 64 bits is "the natural size suggested by >>> the architecture". >> >> I don't think "natural size" is well enough defined here for this to be >> determined. Certainly 64-bit ints is a reasonable match according to >> the standards - but (baring things like Crays) the same cpus can work >> equally "naturally" with 32-bit values or 16-bit values (or even 8-bit >> values). 32-bit seems to be a value that works very well in practice. > > int needs to be able to index a normal array, [...] That seems like an arrogant statement, considering the large number of people who don't agree with it. These days it is common for personal desktop systems, or even laptops for that matter, to support regular C arrays larger than can be indexed either with int or unsigned int.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-22 23:58 -0700 |
| Message-ID | <eb58c8df-cd2a-43a8-bb07-d53b4a0bd31b@googlegroups.com> |
| In reply to | #93923 |
On Friday, September 23, 2016 at 5:30:21 AM UTC+1, Tim Rentsch wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Monday, September 19, 2016 at 9:12:53 PM UTC+1, David Brown wrote: > >> > >>> For a 64-bit target, surely 64 bits is "the natural size suggested by > >>> the architecture". > >> > >> I don't think "natural size" is well enough defined here for this to be > >> determined. Certainly 64-bit ints is a reasonable match according to > >> the standards - but (baring things like Crays) the same cpus can work > >> equally "naturally" with 32-bit values or 16-bit values (or even 8-bit > >> values). 32-bit seems to be a value that works very well in practice. > > > > int needs to be able to index a normal array, [...] > > That seems like an arrogant statement, considering the large > number of people who don't agree with it. These days it is > common for personal desktop systems, or even laptops for that > matter, to support regular C arrays larger than can be indexed > either with int or unsigned int. > It breaks the language. size_t becomes the new int.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-09-23 19:45 +1200 |
| Message-ID | <e4k4tnF8u5mU2@mid.individual.net> |
| In reply to | #93926 |
On 09/23/16 06:58 PM, Malcolm McLean wrote: > On Friday, September 23, 2016 at 5:30:21 AM UTC+1, Tim Rentsch wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> On Monday, September 19, 2016 at 9:12:53 PM UTC+1, David Brown wrote: >>>> >>>>> For a 64-bit target, surely 64 bits is "the natural size suggested by >>>>> the architecture". >>>> >>>> I don't think "natural size" is well enough defined here for this to be >>>> determined. Certainly 64-bit ints is a reasonable match according to >>>> the standards - but (baring things like Crays) the same cpus can work >>>> equally "naturally" with 32-bit values or 16-bit values (or even 8-bit >>>> values). 32-bit seems to be a value that works very well in practice. >>> >>> int needs to be able to index a normal array, [...] >> >> That seems like an arrogant statement, considering the large >> number of people who don't agree with it. These days it is >> common for personal desktop systems, or even laptops for that >> matter, to support regular C arrays larger than can be indexed >> either with int or unsigned int. >> > It breaks the language. > > size_t becomes the new int. No it doesn't. In most people's code array indexes are a small subset of the variables. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-28 08:17 -0700 |
| Message-ID | <kfnmvisaw9y.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93926 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, September 23, 2016 at 5:30:21 AM UTC+1, Tim Rentsch wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> On Monday, September 19, 2016 at 9:12:53 PM UTC+1, David Brown wrote: >>>> >>>>> For a 64-bit target, surely 64 bits is "the natural size suggested by >>>>> the architecture". >>>> >>>> I don't think "natural size" is well enough defined here for this to be >>>> determined. Certainly 64-bit ints is a reasonable match according to >>>> the standards - but (baring things like Crays) the same cpus can work >>>> equally "naturally" with 32-bit values or 16-bit values (or even 8-bit >>>> values). 32-bit seems to be a value that works very well in practice. >>> >>> int needs to be able to index a normal array, [...] >> >> That seems like an arrogant statement, considering the large >> number of people who don't agree with it. These days it is >> common for personal desktop systems, or even laptops for that >> matter, to support regular C arrays larger than can be indexed >> either with int or unsigned int. > > It breaks the language. You mean it breaks your concept of the language. It does not break mine, nor does it for many other people. > size_t becomes the new int. The type for you is ptrdiff_t. Just start using ptrdiff_t in place of int, and you can get off this soapbox.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-28 09:59 -0700 |
| Message-ID | <213983a1-f45c-4b05-a07b-bcb8afa8627e@googlegroups.com> |
| In reply to | #94188 |
On Wednesday, September 28, 2016 at 4:17:52 PM UTC+1, Tim Rentsch wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Friday, September 23, 2016 at 5:30:21 AM UTC+1, Tim Rentsch wrote: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> > > >> That seems like an arrogant statement, considering the large > >> number of people who don't agree with it. These days it is > >> common for personal desktop systems, or even laptops for that > >> matter, to support regular C arrays larger than can be indexed > >> either with int or unsigned int. > > > > It breaks the language. > > You mean it breaks your concept of the language. It does not > break mine, nor does it for many other people. > > All functions that accept arrays as parameters and do not place a restriction on array length are now broken by the introduction of size_t. Not badly. But still broken.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-09-29 07:59 +1300 |
| Message-ID | <e52i8aF1ud9U1@mid.individual.net> |
| In reply to | #94199 |
On 09/29/16 05:59 AM, Malcolm McLean wrote: > On Wednesday, September 28, 2016 at 4:17:52 PM UTC+1, Tim Rentsch wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> On Friday, September 23, 2016 at 5:30:21 AM UTC+1, Tim Rentsch wrote: >>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>> >> >>>> That seems like an arrogant statement, considering the large >>>> number of people who don't agree with it. These days it is >>>> common for personal desktop systems, or even laptops for that >>>> matter, to support regular C arrays larger than can be indexed >>>> either with int or unsigned int. >>> >>> It breaks the language. >> >> You mean it breaks your concept of the language. It does not >> break mine, nor does it for many other people. >> >> > All functions that accept arrays as parameters and do not place a restriction > on array length are now broken by the introduction of size_t. Not badly. > But still broken. So you claim that even the most basic standard library functions such as memcpy and basic I/O are all broken now? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-09-28 19:26 +0000 |
| Message-ID | <slrn3vfsnuo6ab.1ke.ike@iceland.freeshell.org> |
| In reply to | #94207 |
On 2016-09-28, Ian Collins <ian-news@hotmail.com> wrote: > On 09/29/16 05:59 AM, Malcolm McLean wrote: >> On Wednesday, September 28, 2016 at 4:17:52 PM UTC+1, Tim Rentsch wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> >>>> On Friday, September 23, 2016 at 5:30:21 AM UTC+1, Tim Rentsch wrote: >>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>>> >>> >>>>> That seems like an arrogant statement, considering the large >>>>> number of people who don't agree with it. These days it is >>>>> common for personal desktop systems, or even laptops for that >>>>> matter, to support regular C arrays larger than can be indexed >>>>> either with int or unsigned int. >>>> >>>> It breaks the language. >>> >>> You mean it breaks your concept of the language. It does not >>> break mine, nor does it for many other people. >>> >>> >> All functions that accept arrays as parameters and do not place a restriction >> on array length are now broken by the introduction of size_t. Not badly. >> But still broken. > > So you claim that even the most basic standard library functions such as > memcpy and basic I/O are all broken now? Not broken, just Malcolm-broken.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-28 12:37 -0700 |
| Message-ID | <lnbmz7stmx.fsf@kst-u.example.com> |
| In reply to | #94199 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, September 28, 2016 at 4:17:52 PM UTC+1, Tim Rentsch wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> > On Friday, September 23, 2016 at 5:30:21 AM UTC+1, Tim Rentsch wrote:
>> >> That seems like an arrogant statement, considering the large
>> >> number of people who don't agree with it. These days it is
>> >> common for personal desktop systems, or even laptops for that
>> >> matter, to support regular C arrays larger than can be indexed
>> >> either with int or unsigned int.
>> >
>> > It breaks the language.
>>
>> You mean it breaks your concept of the language. It does not
>> break mine, nor does it for many other people.
>>
> All functions that accept arrays as parameters and do not place a restriction
> on array length are now broken by the introduction of size_t. Not badly.
> But still broken.
Well that's ok, because *no* functions accept arrays as parameters.
Presumably you're referring to functions with a parameter of pointer
type, where the pointer is expected to point to the initial element
of an array (the pointer parameter declaration can use either array
or pointer syntax) . The "introduction of size_t" occurred in the
1989 ANSI standard, if not earlier. And it hardly broke anything;
rather, it made it possible to specify sizes portably.
I don't know whether any pre-ANSI compilers supported objects
bigger than INT_MAX bytes or elements. If some did, then the
introduction of size_t made it possible to write more portable code
for such systems. If not, then the introduction of size_t made it
possible to support such objects, without making int artificially
wider than it needs to be.
The functions you're referring to were already broken. Adding
size_t, (which, again, is hardly a new addition) made it possible
to *fix* those functions.
Yes, requiring int to be at least wide enough to hold the size of
any object, or the length of any array, would have been another
solution. That's not the decision that was made 27 years ago,
and it's not going to change in any language calling itself "C".
Perhaps it's time to get used to that.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-10-09 03:46 -0700 |
| Message-ID | <kfnbmyt94v3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #94199 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, September 28, 2016 at 4:17:52 PM UTC+1, Tim Rentsch wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> On Friday, September 23, 2016 at 5:30:21 AM UTC+1, Tim Rentsch wrote: >>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>> >> >>>> That seems like an arrogant statement, considering the large >>>> number of people who don't agree with it. These days it is >>>> common for personal desktop systems, or even laptops for that >>>> matter, to support regular C arrays larger than can be indexed >>>> either with int or unsigned int. >>> >>> It breaks the language. >> >> You mean it breaks your concept of the language. It does not >> break mine, nor does it for many other people. > > All functions that accept arrays as parameters and do not place a > restriction on array length are now broken by the introduction of > size_t. [...] This statement is either nonsensical or it is simply false.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-18 13:53 -0700 |
| Message-ID | <781ac1da-4a06-419d-ab30-50bd9aa2b1bb@googlegroups.com> |
| In reply to | #93732 |
On Sunday, September 18, 2016 at 9:27:52 AM UTC-5, Keith Thompson wrote:
> Too complicated. If non-two's-complement systems are really obsolete,
> why not just have the next C standard require two's-complement? If
> there are any remaining one's-complement or sign-and-magnitude systems,
> let them claim conformance to the old C11 standard, or just let them be
> non-conforming.
There are many tasks which can be performed most efficiently using features
or guarantees that could be cheaply supported by most platforms. If a
using some feature would make 5% of programs more efficient than they would
be without it, but only 95% of implementations can support it, which be
most helpful:
1. Say that the Standard will be inapplicable to those programs unless they
are written inefficiently.
2. Say that the Standard will be inapplicable to the implementations that
can't support that feature or guarantee.
3. Say that the Standard will describe the behavior of the programs that use
that feature or guarantee on the 95% of platforms where it is available,
while also describing the behavior of the 95% of programs that have no
need for the feature on 100% of platforms, including those that don't
support the feature.
I would think #3 would be the most useful course of action, and that it's
what the authors of the Standard intended, but they didn't imagine that
compiler writers targeting the x86 architecture in the 21st century would
not want to support the same behaviors as compiler writers for that platform
were supporting in 1987 (the present x86 architecture debuted with the 80386
in 1985).
> That's assuming we can make that assumption. It's likely that there's
> no good reason to use anything other than two's-complement, but I'm not
> 100% confident that that will never change. This requires input from
> people who know more about this stuff than I do.
Any platform which can perform Standard-compliant unsigned math efficiently
will perform two's-complement math reasonably efficiently. The only
platforms which can perform other forms of integer math significantly more
efficiently than two's-complement are those where either:
1. Compatibility with other systems compels the use of other formats,
something which isn't likely to happen.
2. Unsigned math is significantly less efficient than signed math because
it has to be "emulated" using sequences of signed-math instructions.
There are some implementations where unsigned math is less efficient than
signed math, but that's mainly because C doesn't have any unsigned types
that don't require a compiler to truncate values deterministically after
each computation.
> And of course two's-complement representation doesn't necessarily imply
> the usual two's complement behavior in all cases; it tells us how
> negative integers are represented, but it doesn't tell us the result of
> evaluating INT_MAX+1 or -5<<3. That's another set of assumptions that
> might or might not be sensible to make in a hypothetical new standard.
There are many cases where a compiler could reap some huge advantages to
be able to treat integers as though they promote to arbitrary larger types
whose upper bits may be non-deterministically retained or dropped whenever
the compiler sees fit. There are also cases where it may be useful to have
a compiler guarantee that it will trap in implementation-defined fashion
in cases where arithmetic overflow occurs that might affect a computed
result, but not necessarily in cases where any lost precision would end up
being ignored anyway. In cases where the above behaviors would meet an
application's requirements, a compiler that could guarantee to uphold them
would be capable of meeting application requirements more efficiently than
one which couldn't (if the result of a particular computation is sometimes
ignored, a compiler that recognized those cases could omit not just the
overflow check but the entire computation; if user code checks for and
traps on overflows, however, a compiler could would be required to perform
the checks even for the otherwise-irrelevant computations.
> C already explicitly allows the two's-complement representation with
> sign bit 1 and all value bits 0 to be a trap representation. As for
> -0x7FFFFFFF00000000, I'm skeptical that any such systems exist or are
> worth considering.
If a 32-bit system recognizes 0x80000000 as a NaN, it could easily
recognize any 64-bit number whose upper word is 0x80000000 as a NaN,
and uphold NaN semantics. If the system needs to add 0x123456789 to
0x7FFFFFFFFFFFFFFF, it could process the lower word (yielding 0x23456788
plus a carry), and then the upper word (yielding an overflow, and thus
a 0x80000000 NaN). If the only valid NaN form were 0x8000000000000000
it would be necessary to revisit the lower word after each computation
to ensure that it was zeroed if the upper portion of the number yielded
a NaN result.
Some applications require that the usable range of integer values extend
all the way from -2^63-1 to +2^63-1, but most applications don't need the
entire range. Being able to detect that overflows have occurred would be
a useful feature, and including integer NaN support in future architectures
would not be hard, but unless a language would allow implementations to
expose it to a programmer in useful fashion there wouldn't be much point.
> > How would you multiply a signed number by 2^N in such a fashion as to
> > yield defined behavior in all cases where the result would be
> > representable, without relying upon implementation-defined behavior?
>
> I'd probably use the "*" operator, for example -5 * (1<<3).
That operator will yield UB in cases where << would not, and I haven't seen
any nice expressions which don't rely upon implementation-defined
conversions from unsigned to signed, and which don't fail for either -1<<(#
of value bits) or for INT_MIN<<0, both of which are perfectly defined on
two's-complement systems. Conversion to unsigned would work on commonplace systems, but I think it's more more intuitive to say that shifting a number
which contains an infinite number of 1 bits followed by "1011" left by
three bits should yield an infinite number of 1 bits followed by "1011000"
than to say that one should (using 16 bits for numerical simplicity) add
65536 to convert -5 to an unsigned int (yielding 65531), multiply that by
8, subtracting 458752 to bring the result back in range (yielding 65496),
and then convert that to a signed value by subtacting 65536 (yielding
-40).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-21 21:03 -0700 |
| Message-ID | <kfnh998fuoa.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93689 |
Keith Thompson <kst-u@mib.org> writes: > [...] > > Perhaps it's time for the next edition of the C standard to mandate > 2's-complement [...] I see no reason to do so, and in fact would express it more strongly - it is IMO philosophically wrongheaded. Most applications don't care. Any that do care can easily enforce that they will compile only on 2's complement implementations. Obviously it is an advantage for the language to be available as widely as possible, including on hardware that employs alternate representation schemes. Arbitrarily excluding such hardware would be a poor choice for C, which IIANM is available on a more diverse range of hardware than any other programming language. That is one of C's most important strengths - any move in a direction that would weaken that should be viewed with suspicion.
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web