Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #120124 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2017-09-21 20:50 -0700 |
| Last post | 2017-09-22 09:12 -0700 |
| Articles | 20 on this page of 178 — 26 participants |
Back to article view | Back to comp.lang.c
Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-21 20:50 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 01:15 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 01:21 -0500
Re: Something C might need fir <profesor.fir@gmail.com> - 2017-09-22 00:44 -0700
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-22 11:02 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 12:35 -0500
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-22 13:46 -0400
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 11:47 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-22 12:16 -0700
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-22 18:10 -0400
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 15:24 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-22 15:52 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-23 12:29 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-23 08:29 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:06 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 12:28 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 16:17 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 18:20 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 22:45 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-23 12:22 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 11:29 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-23 10:25 -0400
Re: Something C might need Reinhardt Behm <rbehm@hushmail.com> - 2017-09-24 22:09 +0800
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 15:32 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 13:17 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 21:53 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 14:54 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 23:10 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 16:14 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 01:04 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 17:23 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 08:48 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-25 11:50 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 21:59 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-25 14:25 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 09:39 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-26 11:50 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:44 -0500
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 18:57 -0400
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 00:08 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 20:51 -0400
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 02:10 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 22:22 -0400
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 06:35 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 16:16 +0200
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 07:47 -0700
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 13:38 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:29 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 17:40 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:30 -0500
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-25 08:58 -0400
Re: Something C might need supercat@casperkitty.com - 2017-09-23 08:41 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 17:32 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-23 11:32 -0700
Re: Something C might need Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-25 14:43 +0000
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 22:07 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-25 13:34 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-26 10:04 +1300
Re: Something C might need Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-26 14:31 +0000
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-27 08:38 +1300
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 17:49 -0700
Re: Something C might need gordonb.w32iq@burditt.org (Gordon Burditt) - 2017-09-23 21:21 -0500
Re: Something C might need supercat@casperkitty.com - 2017-09-24 11:27 -0700
Re: Something C might need gordonb.woyvd@burditt.org (Gordon Burditt) - 2017-09-25 01:08 -0500
Re: Something C might need supercat@casperkitty.com - 2017-09-25 09:38 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-25 10:00 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 11:32 +0100
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 12:29 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 20:38 +0100
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 15:25 -0700
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-23 20:36 -0400
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 01:42 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:03 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 22:47 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:03 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-24 15:10 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 16:20 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-24 16:44 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:00 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-24 16:51 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:11 +0200
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:04 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 22:10 +0100
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-24 10:19 +1300
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 01:38 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 02:14 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:41 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 11:16 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 11:41 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:15 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:23 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 14:03 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 13:59 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 16:08 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 21:50 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 21:40 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:28 +0200
Re: Something C might need luser droog <luser.droog@gmail.com> - 2017-09-26 06:28 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-26 07:47 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-27 08:26 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-27 07:22 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-27 09:01 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-27 09:42 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:42 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 19:22 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:48 +0200
Re: Something C might need scott@slp53.sl.home (Scott Lurndal) - 2017-09-28 17:31 +0000
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 22:09 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 22:44 +0100
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 01:57 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 02:02 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 19:10 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 16:27 +0100
Re: Something C might need Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-27 09:26 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:53 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-27 10:52 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 19:20 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-27 11:44 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:57 +0200
Re: Something C might need James Kuyper <jameskuyper@verizon.net> - 2017-09-24 14:49 -0400
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 22:06 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 20:09 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:12 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 20:46 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:41 +0200
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 21:05 +0100
Re: Something C might need gordonb.r273i@burditt.org (Gordon Burditt) - 2017-09-23 21:34 -0500
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 09:01 +0100
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-24 19:34 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:53 -0500
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-25 12:27 -0400
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-25 20:33 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:52 -0500
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-25 23:23 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-25 15:15 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 17:49 -0500
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 09:46 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 07:32 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 21:50 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 14:32 -0700
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-26 22:34 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 14:39 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 19:38 +0100
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-25 15:00 -0400
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-25 12:29 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 22:12 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-22 11:38 +0100
Re: Something C might need Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-22 04:21 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-22 14:54 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 08:02 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 06:49 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-22 20:24 +0100
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 12:45 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 09:00 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 17:34 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 10:49 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 19:25 -0400
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-22 19:35 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 11:52 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 18:25 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 13:36 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 20:20 -0700
Rick says C is a dying language. (Was: Something C might need) gazelle@shell.xmission.com (Kenny McCormack) - 2017-09-23 09:15 +0000
Re: Rick says C is a dying language. (Was: Something C might need) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-23 04:40 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 13:00 +0100
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-23 10:28 -0400
Re: Something C might need James Kuyper <jameskuyper@verizon.net> - 2017-09-22 23:22 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 18:01 +1200
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-22 20:31 -0400
Re: Something C might need jladasky@itu.edu - 2017-09-22 16:27 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 16:34 -0700
Re: Something C might need scott@slp53.sl.home (Scott Lurndal) - 2017-09-26 21:44 +0000
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-26 14:53 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 02:14 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-22 21:31 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-22 14:02 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 17:29 -0400
Re: Something C might need supercat@casperkitty.com - 2017-09-22 09:12 -0700
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-24 22:06 +0200 |
| Message-ID | <oq938o$gcb$1@dont-email.me> |
| In reply to | #120234 |
On 24/09/17 20:49, James Kuyper wrote: > On 09/24/2017 08:03 AM, David Brown wrote: >> On 24/09/17 12:16, bartc wrote: > ... >> Now, if you have read these two pages and /still/ don't know what a >> "long long" is, and why neither "twice as long as long" nor "at least as >> wide as long" is a description of the type, then ask again. I promise I >> will then give you an explanation. > > "twice as long as long" is inaccurate, because a conforming > implementation can have a "long long" type which violates that > specification - but the same is not true about "at least as wide as > long". I'm not sure why you imply that those two statements are equally > objectionable. Neither is complete, but the second one is both true and > important. When they were given as complete descriptions of "long long", both statements are wrong. Of course it is better to have a statement that is true but incomplete, than one that is merely true (and incomplete) on some platforms. > > ... >> It does not have types like uint_least27_t for those that want 27 bit >> types, but that's because the number of users is going to be rather >> small. But the standard says how they should work, if an implementation >> wants to provide them. > > The standard makes precisely as much provision for uint_least27_t as it > does for int32_t. Both types are optional, but neither the types nor the > corresponding macros can be supported unless the corresponding type is > actually supported in the fashion specified by the standard. Exactly. > >>> And even in C99 and later, int32_t etc is a poor solution. People want >>> to just write 'int' and be able to use "%d" and "INT_MAX". >>> >> >> /You/ might want to do that. Other people are quite happy with writing >> "int32_t" and friends. > > Actually, I'm not. In a new language which had no need to retain > backwards compatibility with C89, I'd have preferred simpler names for > the size-named types. I did not mean to imply that /all/ other people are quite happy with the C99 <stdint.h> types - merely that at least /some/ are. Certainly I have no problem with them, and I see them used regularly by others. I do know that some people dislike the names, and prefer something like "i32", or perhaps "int32". (I don't know what names /you/ would prefer.) Personally, however, I really can't see the fuss - they are fairly succinct and clear. The names like "int_least8_t" and "uint_fast16_t" are more cumbersome, and that might affect their popularity (or lack thereof), but I can't think of significantly better names. > But, unlike Bartc, I'm willing to understand the > necessity of maintaining backwards compatibility, and the corresponding > clumsiness in the way that the language has added new features. For > instance, we should have had "var" meaning "variable" rather than > "const" meaning "constant", because "const" should have been the default > - not that I expect Bartc to agree with me about that particular judgment. > For what it is worth, /I/ agree with you here about var and const. I'd also make "static" the default for file-scope functions and objects, and require an explicit "extern" or perhaps "public" declaration for exporting symbols.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-24 20:09 +0100 |
| Message-ID | <GpTxB.1205179$842.755578@fx23.am4> |
| In reply to | #120226 |
On 24/09/2017 13:03, David Brown wrote: > On 24/09/17 12:16, bartc wrote: > <http://en.cppreference.com/w/c/language/arithmetic_types> > > You'll also find this useful: > > <http://en.cppreference.com/w/c/language/type> > > > Now, if you have read these two pages and /still/ don't know what a > "long long" is, and why neither "twice as long as long" nor "at least as > wide as long" is a description of the type, then ask again. I promise I > will then give you an explanation. I missed this part of your post this morning. Some comments: * I didn't say that long long is 'twice as long as long' * My remark that 'long long is at least as wide as long' was in response to the OP who did say it, in the context of the relative widths of int types * From what I have been able to glean from other posts, my remark is not actually wrong. * After perusing the references that people suggested I look at, the C standard and the links, I still haven't got a clue as to what as incorrect or objectionable about my comment * You imply that I don't know what 'long long' is, which I find farcical. Let me ask you: what do YOU think that I think 'long long' is? You must have some idea otherwise you wouldn't be able to say that I got it wrong.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-24 12:12 -0700 |
| Message-ID | <lnbmlz3o7g.fsf@kst-u.example.com> |
| In reply to | #120223 |
bartc <bc@freeuk.com> writes:
> On 24/09/2017 02:41, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 24/09/2017 01:38, Ben Bacarisse wrote:
>>>> bartc <bc@freeuk.com> writes:
>>>>
>>>>> On 23/09/2017 20:29, David Kleinecke wrote:
>>>> <snip>
>>>>>> I work from C89 so "long long" isn't part of what I talked
>>>>>> about but it is obvious what it means - a value twice as
>>>>>> long as a long.
>>>>>
>>>>> That's what you would think. But not when dealing with C where
>>>>> everything has to have an unexpected twist.
>>>>>
>>>>> long long simply means a type at l[e]ast as wide as a long.
>>>>
>>>> No it doesn't. You could have find out what it means if you wanted to,
>>>> but I expect you'd rather just complain about how it's all so confusing.
>>>
>>> So, what does it mean then?
>>
>> The answer to your question is in n1570.pdf.
>
> Why do you guys do this?
[...]
> Give me a clue please.
LLONG_MIN must be no greater than -9223372036854775807, and LLONG_MAX
must be no less than +9223372036854775807, implying that long long must
be at least 64 bits. That's the main point you didn't mention.
[...]
>> Java, as I recall, has fixed sizes for its predefined types. What if I
>> want a type that's at least N bits and as efficient as possible? I can
>> do that in C.
>
> What does that even mean? And has anybody ever actually used such a type?
In C it's called int_fastN_t, which exists for at least N = 8, 16, 32,
and 64.
> (How do you say in Ada that you want a type that can represent at least
> the range 0 to 16383?)
type Whatever is range 0 .. 16383; -- Why do you ask?
(Ada's predefined integer types are similar to C's, with Integer,
Long_Integer, and so forth. The main difference is that Ada, unlike C,
provides a way to define your own integer types with specified ranges.)
>>> So, if you're coding for x86, which one, if any, is 32 bits, and no
>>> wider, on both Windows and Linux?
>>
>> int32_t or uint32_t. But you already knew that.
>
> The context here is the classic pre-C99 which is what the OP is
> interested in.
Pre-C99 is obsolete. I don't know why the OP is so interested in it.
And there are implementations of <stdint.h> for pre-C99 implementations
(it's one of the easier features of C99 to implement, so it was often
provided before full C99 compliance was possible).
> And even in C99 and later, int32_t etc is a poor solution. People want
> to just write 'int' and be able to use "%d" and "INT_MAX".
Does "People" refer to anyone other than you?
--
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 | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-24 20:46 +0100 |
| Message-ID | <PYTxB.1556011$lu5.237881@fx42.am4> |
| In reply to | #120237 |
On 24/09/2017 20:12, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> Why do you guys do this? > [...] >> Give me a clue please. > > LLONG_MIN must be no greater than -9223372036854775807, and LLONG_MAX > must be no less than +9223372036854775807, implying that long long must > be at least 64 bits. That's the main point you didn't mention. At last; thank you. With the minimum widths, I don't go into that for int either, but I touched on that aspect of it here: "While every other language has four distinct types covering the VERY common widths 8, 16, 32, 64 bits, C has to have types A B C D E which have no predefined widths, except that A is at least 8 bits, C is at least 16 but might be 32, D at least 32 but might be 64 and that each successive type is not narrower than the last. Or maybe all of them are exactly 77 bits." What I was replying to was the misconception that an extra 'long' will always double the type's width. >> (How do you say in Ada that you want a type that can represent at least >> the range 0 to 16383?) > > type Whatever is range 0 .. 16383; -- Why do you ask? I was wondering if there was any annotation that was the equivalent of 'fast' or 'least' in C's int_xxxxN_t types. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-25 09:41 +0200 |
| Message-ID | <oqabuq$as0$1@dont-email.me> |
| In reply to | #120240 |
On 24/09/17 21:46, bartc wrote: > On 24/09/2017 20:12, Keith Thompson wrote: >> bartc <bc@freeuk.com> writes: > >>> Why do you guys do this? >> [...] >>> Give me a clue please. >> >> LLONG_MIN must be no greater than -9223372036854775807, and LLONG_MAX >> must be no less than +9223372036854775807, implying that long long must >> be at least 64 bits. That's the main point you didn't mention. > > At last; thank you. The clue is given quite clearly in the C standards (search for "long long"), and also in the web reference I gave you. > > With the minimum widths, I don't go into that for int either, but I > touched on that aspect of it here: > > "While every other language has four distinct > types covering the VERY common widths 8, 16, 32, 64 bits, C has to have > types A B C D E which have no predefined widths, except that A is at > least 8 bits, C is at least 16 but might be 32, D at least 32 but might > be 64 and that each successive type is not narrower than the last. Or > maybe all of them are exactly 77 bits." Your list here is correct, AFAICS. You might have added "E at least 64", and that each type has to be at least as big as the previous one, but there are no errors in that list. It is not that list that people had said was wrong. > > What I was replying to was the misconception that an extra 'long' will > always double the type's width. > Yes. It is unfortunate that you replied to that misconception with another misconception. But hopefully everything is sorted now, and you know all you need to know about "long long". >>> (How do you say in Ada that you want a type that can represent at least >>> the range 0 to 16383?) >> >> type Whatever is range 0 .. 16383; -- Why do you ask? > > I was wondering if there was any annotation that was the equivalent of > 'fast' or 'least' in C's int_xxxxN_t types. > It is a long time since I have done any Ada programming, and even then it was only a very small amount - so you would have to check with an Ada expert.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-24 21:05 +0100 |
| Message-ID | <871smv500p.fsf@bsb.me.uk> |
| In reply to | #120223 |
bartc <bc@freeuk.com> writes: > On 24/09/2017 02:41, Keith Thompson wrote: >> bartc <bc@freeuk.com> writes: >>> On 24/09/2017 01:38, Ben Bacarisse wrote: >>>> bartc <bc@freeuk.com> writes: <snip> >>>>> long long simply means a type at l[e]ast as wide as a long. >>>> >>>> No it doesn't. You could have find out what it means if you wanted to, >>>> but I expect you'd rather just complain about how it's all so confusing. >>> >>> So, what does it mean then? >> >> The answer to your question is in n1570.pdf. > > Why do you guys do this? > > Obviously there must be some nuance that I've missed out, but then > both of you suggest I can find the answer in a 700-page reference > manual. If you search for "long long" the second hit shows you that the minimum permitted width of long long is 64 bits. Since I imagine you know that long is not required to be that wide, you can conclude that long long is not simply a type at least as wide as long. <snip> > FWIW I've looked at every instance of 'long long' and all it does is > go on and on about ranks, about the order in which constants are > converted to int types, about format codes, about the allowed > combinations and longs and ints, or it just appears in the > declarations certain standard functions. The first hit tells you that long long appeared in "the second edition" of ISO C (that's C99) and the second tells you it can't be the same width as a 32-bit long. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.r273i@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2017-09-23 21:34 -0500 |
| Message-ID | <IrOdnTsW_6UrhFrEnZ2dnUU7-N-dnZ2d@posted.internetamerica> |
| In reply to | #120212 |
>> long long simply means a type at last as wide as a long. Example: FreeBSD in the amd64 architure: long and long long are both 64-bit types.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-24 09:01 +0100 |
| Message-ID | <87bmm04jae.fsf@bsb.me.uk> |
| In reply to | #120220 |
gordonb.r273i@burditt.org (Gordon Burditt) writes: >>> long long simply means a type at last as wide as a long. > > Example: FreeBSD in the amd64 architure: long and long long are > both 64-bit types. Please don't reply without attribution lines. You also replied to a post by me but did not quote anything I wrote. I don't see how that example helps. There are lots of example of long long being at least as wide a long (indeed it must be). The error was to say that that is all that long long must be. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-09-24 19:34 +0200 |
| Message-ID | <oq8qbp$9n4$1@dont-email.me> |
| In reply to | #120144 |
On 22/09/2017 19:35, Robert Wessel wrote:
> On Fri, 22 Sep 2017 11:02:53 +0200, Noob wrote:
>
>> On 22/09/2017 05:50, David Kleinecke wrote:
>>
>>> But these ideal ints fail when we multiple. The product of two ints
>>> is - conceptually - twice the size of an int. Hence we need "long".
>>> But C, as it stands, does not implement that situation.
>>
>> Good compilers have been able to recognize the "widening multiply" pattern
>> for years, if not decades. I don't think it justifies adding new operators.
>>
>> Consider the following example, for which gcc (as, I'm sure, all modern
>> compilers) generates the amd64 code below.
>>
>> int64_t wide_mult(int32_t u, int32_t v)
>> {
>> return (int64_t)u * v;
>> }
>>
>> wide_mult:
>> movslq %edi, %rax # copy u to RAX
>> movslq %esi, %rdi # copy v to RDI
>> imulq %rdi, %rax # write u*v to RAX
>> ret
>
>
> That doesn't help if you want the full result of a multiplication of
> the largest type.
Do you mean 64x64->128? GCC supports that as well, of course.
u128 wide_mult(u64 u, u64 v)
{
return (u128)u*v;
}
wide_mult:
movq %rdi, %rax # copy u to RAX
mulq %rsi # write u*v to RDX:RAX
ret
It's possible to write optimized arbitrary-width code using
just C.
Regards.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-09-24 23:53 -0500 |
| Message-ID | <2s2hscl99m82tj6h2bkgis6c1i7fa2dpun@4ax.com> |
| In reply to | #120232 |
On Sun, 24 Sep 2017 19:34:41 +0200, Noob <root@127.0.0.1> wrote:
>On 22/09/2017 19:35, Robert Wessel wrote:
>
>> On Fri, 22 Sep 2017 11:02:53 +0200, Noob wrote:
>>
>>> On 22/09/2017 05:50, David Kleinecke wrote:
>>>
>>>> But these ideal ints fail when we multiple. The product of two ints
>>>> is - conceptually - twice the size of an int. Hence we need "long".
>>>> But C, as it stands, does not implement that situation.
>>>
>>> Good compilers have been able to recognize the "widening multiply" pattern
>>> for years, if not decades. I don't think it justifies adding new operators.
>>>
>>> Consider the following example, for which gcc (as, I'm sure, all modern
>>> compilers) generates the amd64 code below.
>>>
>>> int64_t wide_mult(int32_t u, int32_t v)
>>> {
>>> return (int64_t)u * v;
>>> }
>>>
>>> wide_mult:
>>> movslq %edi, %rax # copy u to RAX
>>> movslq %esi, %rdi # copy v to RDI
>>> imulq %rdi, %rax # write u*v to RAX
>>> ret
>>
>>
>> That doesn't help if you want the full result of a multiplication of
>> the largest type.
>
>Do you mean 64x64->128? GCC supports that as well, of course.
>
>u128 wide_mult(u64 u, u64 v)
>{
> return (u128)u*v;
>}
>
>wide_mult:
> movq %rdi, %rax # copy u to RAX
> mulq %rsi # write u*v to RDX:RAX
> ret
>
>It's possible to write optimized arbitrary-width code using
>just C.
Several compilers have support for extensions like that. But they're
extensions.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-09-25 12:27 -0400 |
| Message-ID | <0c235d98-b91e-3a2e-1936-c87b035bea6d@verizon.net> |
| In reply to | #120268 |
On 2017-09-25 00:53, Robert Wessel wrote:
> On Sun, 24 Sep 2017 19:34:41 +0200, Noob <root@127.0.0.1> wrote:
...
>> Do you mean 64x64->128? GCC supports that as well, of course.
>>
>> u128 wide_mult(u64 u, u64 v)
>> {
>> return (u128)u*v;
>> }
Which version of gcc supports that? Are any particular options needed to
enable it? On my desktop machine I have gcc 4.8.5, which does not
recognize u128 or u64 in default mode.
>> wide_mult:
>> movq %rdi, %rax # copy u to RAX
>> mulq %rsi # write u*v to RDX:RAX
>> ret
>>
>> It's possible to write optimized arbitrary-width code using
>> just C.
>
>
> Several compilers have support for extensions like that. But they're
> extensions.
Standard C is sufficient to enable writing code that could be optimized
similarly:
#include <stdint.h>
#ifndef UINT_FAST128_MAX
#error uint_fast128_t not supported
#endif
uint_fast128_t wide_mult(uint_fast64_t u, uint_fast64_t v)
{
return (uint_fast128_t)u*v;
}
Support for uint_fast128_t is optional, but it should be available on
any platform where your u128 is - a statement I'll stick with even
though it fails in the only place I can easily test. Some experimenting
shows that the gcc I'm using supports __int128, but neither __uint128,
nor uint_least128_t. That strikes me as quite odd.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-09-25 20:33 +0200 |
| Message-ID | <oqbi5u$gi3$1@dont-email.me> |
| In reply to | #120312 |
On 25/09/2017 18:27, James R. Kuyper wrote:
> On Sun, 24 Sep 2017 19:34:41 +0200, Noob wrote:
>
>> u128 wide_mult(u64 u, u64 v)
>> {
>> return (u128)u*v;
>> }
>
> Which version of gcc supports that? Are any particular options needed
> to enable it? On my desktop machine I have gcc 4.8.5, which does not
> recognize u128 or u64 in default mode.
Sorry. The full program is:
typedef unsigned __int128 u128;
typedef unsigned long long u64;
u128 wide_mult(u64 u, u64 v)
{
return (u128)u*v;
}
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
Compile with gcc -O3 -S
You can try it here:
https://godbolt.org/
> Support for uint_fast128_t is optional, but it should be available on
> any platform where your u128 is - a statement I'll stick with even
> though it fails in the only place I can easily test. Some experimenting
> shows that the gcc I'm using supports __int128, but neither __uint128,
> nor uint_least128_t. That strikes me as quite odd.
Agreed. They call it 'unsigned __int128' instead of __uint128.
Regards.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-09-25 15:52 -0500 |
| Message-ID | <63riscpj1g49grn3e1ubikat6miiqh3guh@4ax.com> |
| In reply to | #120317 |
On Mon, 25 Sep 2017 20:33:33 +0200, Noob <root@127.0.0.1> wrote:
>On 25/09/2017 18:27, James R. Kuyper wrote:
>
>> On Sun, 24 Sep 2017 19:34:41 +0200, Noob wrote:
>>
>>> u128 wide_mult(u64 u, u64 v)
>>> {
>>> return (u128)u*v;
>>> }
>>
>> Which version of gcc supports that? Are any particular options needed
>> to enable it? On my desktop machine I have gcc 4.8.5, which does not
>> recognize u128 or u64 in default mode.
>
>Sorry. The full program is:
>
>typedef unsigned __int128 u128;
>typedef unsigned long long u64;
>u128 wide_mult(u64 u, u64 v)
>{
> return (u128)u*v;
>}
>
>https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
>
>Compile with gcc -O3 -S
>You can try it here:
>https://godbolt.org/
>
>> Support for uint_fast128_t is optional, but it should be available on
>> any platform where your u128 is - a statement I'll stick with even
>> though it fails in the only place I can easily test. Some experimenting
>> shows that the gcc I'm using supports __int128, but neither __uint128,
>> nor uint_least128_t. That strikes me as quite odd.
>
>Agreed. They call it 'unsigned __int128' instead of __uint128.
Unless it's changed, it's also not supported by all GCC targets.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-09-25 23:23 +0200 |
| Message-ID | <oqbs5d$198$1@dont-email.me> |
| In reply to | #120329 |
On 25/09/2017 22:52, Robert Wessel wrote: > [ The __int128 type ] is not supported by all GCC targets. Why would you need __int128 on all GCC targets? It is useful on platforms that provide widening instructions, such as imulq on amd64. Regards.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-25 15:15 -0700 |
| Message-ID | <ln60c61l2v.fsf@kst-u.example.com> |
| In reply to | #120333 |
Noob <root@127.0.0.1> writes:
> On 25/09/2017 22:52, Robert Wessel wrote:
>
>> [ The __int128 type ] is not supported by all GCC targets.
>
> Why would you need __int128 on all GCC targets?
Um, because I want to do 128-bit arithmetic?
> It is useful on platforms that provide widening instructions,
> such as imulq on amd64.
If I want to do 128-bit arithmetic (or if I don't), I'm not likely to
care about whether it uses an imulq instruction or a function call.
On the other hand, I can understand the gcc folks not implementing it
on targets that can't support easily it in hardware. It's probably
a reasonable tradeoff -- but annoying if you want to do 128-bit
arithmetic and all you have is a 32-bit x86.
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-09-25 17:49 -0500 |
| Message-ID | <kg1jsc95f128pac42mn15fge376q7js9fa@4ax.com> |
| In reply to | #120333 |
On Mon, 25 Sep 2017 23:23:55 +0200, Noob <root@127.0.0.1> wrote:
>On 25/09/2017 22:52, Robert Wessel wrote:
>
>> [ The __int128 type ] is not supported by all GCC targets.
>
>Why would you need __int128 on all GCC targets?
>
>It is useful on platforms that provide widening instructions,
>such as imulq on amd64.
It was being presented as a "standard" way of requesting a double
width multiplication result. My point was that this is a GCC
extension, and not even implemented for all GCC targets.
Even fairly small systems now implement encryption, usually to support
SSL, which requires arithmetic on large integers. Implementing a
bignum multiplication routine efficiently in C difficult to do without
knowing something about the underlying machine and possibly using
non-standard extensions (like being able to get the result of a
widening multiplication instruction). Often we just implement the
limbs ("digits") used to implement the bignum library as half the size
of the biggest conveniently available type (long long, these days). On
some processors it might be best to do 16-bit limbs, on others
64x64->128 bit multiplications are available in the ISA, and we'd want
to use those (and 64-bit limbs). Half-sized limbs also make handling
carry propagation easier.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-26 09:46 +0200 |
| Message-ID | <oqd0ka$2eo$1@dont-email.me> |
| In reply to | #120338 |
On 26/09/17 00:49, Robert Wessel wrote:
> On Mon, 25 Sep 2017 23:23:55 +0200, Noob <root@127.0.0.1> wrote:
>
>> On 25/09/2017 22:52, Robert Wessel wrote:
>>
>>> [ The __int128 type ] is not supported by all GCC targets.
>>
>> Why would you need __int128 on all GCC targets?
>>
>> It is useful on platforms that provide widening instructions,
>> such as imulq on amd64.
>
>
> It was being presented as a "standard" way of requesting a double
> width multiplication result. My point was that this is a GCC
> extension, and not even implemented for all GCC targets.
>
> Even fairly small systems now implement encryption, usually to support
> SSL, which requires arithmetic on large integers. Implementing a
> bignum multiplication routine efficiently in C difficult to do without
> knowing something about the underlying machine and possibly using
> non-standard extensions (like being able to get the result of a
> widening multiplication instruction). Often we just implement the
> limbs ("digits") used to implement the bignum library as half the size
> of the biggest conveniently available type (long long, these days). On
> some processors it might be best to do 16-bit limbs, on others
> 64x64->128 bit multiplications are available in the ISA, and we'd want
> to use those (and 64-bit limbs). Half-sized limbs also make handling
> carry propagation easier.
>
I don't know which gcc targets fail to support 128-bit integers. But
efficiency goes downhill quite quickly once you go beyond twice the size
of hardware instructions, and it is a real pain when you don't have
enough registers to hold all the bits. I'd imagine 128-bit arithmetic
on 32-bit x86 would be very messy to do efficiently with so few
registers - a bignum library would probably be easier and faster without
128-bit arithmetic on such targets.
Still, big integers can be convenient for occasional use. I have used
64-bit integers on an 8-bit microcontroller - it can be handy, even if
it is inefficient.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-26 07:32 -0700 |
| Message-ID | <52c93dea-f139-4d7e-b05a-56c7084d2361@googlegroups.com> |
| In reply to | #120341 |
On Tuesday, September 26, 2017 at 2:46:31 AM UTC-5, David Brown wrote: > I don't know which gcc targets fail to support 128-bit integers. But > efficiency goes downhill quite quickly once you go beyond twice the size > of hardware instructions, and it is a real pain when you don't have > enough registers to hold all the bits. I'd imagine 128-bit arithmetic > on 32-bit x86 would be very messy to do efficiently with so few > registers - a bignum library would probably be easier and faster without > 128-bit arithmetic on such targets. On many processors, probably a majority of 8, 16, 32, or 64-bit ones, 128- bit addition and subtraction would take about twice as long as 64-bit, and 128-bit multiplication would take about four times as long as 64-bit, if operands will be fetched from memory and results are stored back in either case. Given that the larger operations are effectively doing two or four times as much work, I would consider that practical. Processors that cannot efficiently go beyond double-word math are not particularly rare, but I think they're in a minority. For maximal efficiency, however, big-number arithmetic sometimes needs available addition and subtraction primitives that produce a result which is one machine-word larger than the operands. On a 64-bit system, the result of adding two 64-bit values should logically be 128 bits, but on a 32, 16, or 8-bit platform the optimal sizes would be 96, 80, or 72 bits. While support for 128-bit math would be reasonably practical even on an 8-bit platform in cases where one genuinely needed to process 128-bit operands, the biggest "problem" I think is that in many cases where one would need values larger than 64 bits one wouldn't really need 128-bit values. Although power-of-two sizes are very good as a *storage* format, in many cases computations would be best performed using types that are slightly larger than a power of two. While may people think padding bits are silly, I think it's better to allocate storage and not use it, than to have to perform calculations on useless bits.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-26 21:50 +0200 |
| Message-ID | <oqeb1v$4aj$1@dont-email.me> |
| In reply to | #120345 |
On 26/09/17 16:32, supercat@casperkitty.com wrote: > On Tuesday, September 26, 2017 at 2:46:31 AM UTC-5, David Brown wrote: >> I don't know which gcc targets fail to support 128-bit integers. But >> efficiency goes downhill quite quickly once you go beyond twice the size >> of hardware instructions, and it is a real pain when you don't have >> enough registers to hold all the bits. I'd imagine 128-bit arithmetic >> on 32-bit x86 would be very messy to do efficiently with so few >> registers - a bignum library would probably be easier and faster without >> 128-bit arithmetic on such targets. > > On many processors, probably a majority of 8, 16, 32, or 64-bit ones, 128- > bit addition and subtraction would take about twice as long as 64-bit, and > 128-bit multiplication would take about four times as long as 64-bit, if > operands will be fetched from memory and results are stored back in either > case. It would be worse than that in many cases - as the data would /have/ to be in memory rather than registers. Multiplication involves a fair amount of intermediary data that would be particularly hard to squeeze into registers. On an 8-bit device, 128-bit integers take 16 registers! Additionally, supporting these types efficiently would mean a fair amount of extra work for compiler writers as well as debugger tools - you would have to deal with types that are spread across registers and memory. It is just a lot of work for a feature that is rarely helpful.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-26 14:32 -0700 |
| Message-ID | <a438e76e-b77c-4d01-8a60-8b4016ba03eb@googlegroups.com> |
| In reply to | #120349 |
On Tuesday, September 26, 2017 at 2:50:31 PM UTC-5, David Brown wrote: > It would be worse than that in many cases - as the data would /have/ to > be in memory rather than registers. Multiplication involves a fair > amount of intermediary data that would be particularly hard to squeeze > into registers. On an 8-bit device, 128-bit integers take 16 registers! Some smaller processors might be able to manage 32-bit operations without shuffling everything to memory, but 64-bit operands are likely going to have to use a memory-based "accumulator" on any 8-bit or 16-bit processsor. On the 32-bit ARM devices which include a "multiply accumulate" instruction it would be practical to use R0-R3 to hold the partial product, R4-R7 to hold one multiplicand, R8 to hold a pointer to the other, and R9 to hold one word of it [each word would be fetched once]. On something like a Cortex-M0, a 128x128 multiply would be rather slow, but even a 64x64 multiply would be slow on that platform. While the 128x128 may have a worst-case behavior that is more than four times as slow, it would most likely be worthwhile for both 64x64 and 128x128 library functions to optimize cases where some halfwords are zero; since 128x128 multiplies would more often involve more zero halfwords, typical performance may be less than four times as slow as 64x64.
[toc] | [prev] | [next] | [standalone]
Page 7 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