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 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-21 20:50 -0700 |
| Subject | Something C might need |
| Message-ID | <1cc86992-d71e-42b9-818f-f883b78e79ce@googlegroups.com> |
I look upon the addition of two integers as the
philosophical prototype of computing. I see the
concept of "int" in C as indicating the size of
the integers in the prototypical addition.
There is no reason not to do all integer additions
in registers that are the normal maximum size. So
we may want the concepts of "short" and "char" for
smaller integer types that are extended to "int"
when actually added.
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.
What we seem to need is operators, call them
":=" and "=:" with the semantics and constraints:
a := b
means a is an int, b is a long int and the
execution is to assign the value in the
upper half of b to a. Conversely
b =: a
assigns the value in a to the upper half of b.
In the case of division "b / a" b is a long or
a smaller int extended to long. It is possible
for b / a to extend larger than an int so
it is long but b % a is always an int.
I know C doesn't NEED these operators. But IMO
they would give it a kind of completion.
[toc] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-09-22 01:15 -0500 |
| Message-ID | <h8a9scdbthi1nne8inlksq039o5a855499@4ax.com> |
| In reply to | #120124 |
On Thu, 21 Sep 2017 20:50:48 -0700 (PDT), David Kleinecke <dkleinecke@gmail.com> wrote: >I look upon the addition of two integers as the >philosophical prototype of computing. I see the >concept of "int" in C as indicating the size of >the integers in the prototypical addition. > >There is no reason not to do all integer additions >in registers that are the normal maximum size. So >we may want the concepts of "short" and "char" for >smaller integer types that are extended to "int" >when actually added. > >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. > >What we seem to need is operators, call them >":=" and "=:" with the semantics and constraints: > a := b >means a is an int, b is a long int and the >execution is to assign the value in the >upper half of b to a. Conversely > b =: a >assigns the value in a to the upper half of b. > >In the case of division "b / a" b is a long or >a smaller int extended to long. It is possible >for b / a to extend larger than an int so >it is long but b % a is always an int. > >I know C doesn't NEED these operators. But IMO >they would give it a kind of completion. C lacks several features useful for implementing multiple-precision arithmetic, including double width multiplications results, carries from addition and subtraction, and double width dividends in divisions, and the remainders from such double width divisions. All on both signed and unsigned numbers. Remainders from single width divisions of signed numbers are provided by the div() family of functions. I think it would be reasonable to provide such, but standard library functions would be adequate, on the assumption that most compilers would inline them. Far more useful, however, would be to make a bignum library a part of the standard library.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-09-22 01:21 -0500 |
| Message-ID | <8ta9schesohq6i0s74oe5t5v8h1e6gdu70@4ax.com> |
| In reply to | #120125 |
On Fri, 22 Sep 2017 01:15:44 -0500, Robert Wessel <robertwessel2@yahoo.com> wrote: >On Thu, 21 Sep 2017 20:50:48 -0700 (PDT), David Kleinecke ><dkleinecke@gmail.com> wrote: > >>I look upon the addition of two integers as the >>philosophical prototype of computing. I see the >>concept of "int" in C as indicating the size of >>the integers in the prototypical addition. >> >>There is no reason not to do all integer additions >>in registers that are the normal maximum size. So >>we may want the concepts of "short" and "char" for >>smaller integer types that are extended to "int" >>when actually added. >> >>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. >> >>What we seem to need is operators, call them >>":=" and "=:" with the semantics and constraints: >> a := b >>means a is an int, b is a long int and the >>execution is to assign the value in the >>upper half of b to a. Conversely >> b =: a >>assigns the value in a to the upper half of b. >> >>In the case of division "b / a" b is a long or >>a smaller int extended to long. It is possible >>for b / a to extend larger than an int so >>it is long but b % a is always an int. >> >>I know C doesn't NEED these operators. But IMO >>they would give it a kind of completion. > > >C lacks several features useful for implementing multiple-precision >arithmetic, including double width multiplications results, carries >from addition and subtraction, and double width dividends in >divisions, and the remainders from such double width divisions. All >on both signed and unsigned numbers. Remainders from single width >divisions of signed numbers are provided by the div() family of >functions. > >I think it would be reasonable to provide such, but standard library >functions would be adequate, on the assumption that most compilers >would inline them. > >Far more useful, however, would be to make a bignum library a part of >the standard library. And addition and subtraction functions that accept a carry in would need to be provided as well.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-09-22 00:44 -0700 |
| Message-ID | <e7947260-e057-485e-a995-f91ddcbee5b0@googlegroups.com> |
| In reply to | #120124 |
W dniu piątek, 22 września 2017 05:51:05 UTC+2 użytkownik David Kleinecke napisał: > I look upon the addition of two integers as the > philosophical prototype of computing. I see the > concept of "int" in C as indicating the size of > the integers in the prototypical addition. > > There is no reason not to do all integer additions > in registers that are the normal maximum size. So > we may want the concepts of "short" and "char" for > smaller integer types that are extended to "int" > when actually added. > > 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. > > What we seem to need is operators, call them > ":=" and "=:" with the semantics and constraints: > a := b > means a is an int, b is a long int and the > execution is to assign the value in the > upper half of b to a. Conversely > b =: a > assigns the value in a to the upper half of b. > > In the case of division "b / a" b is a long or > a smaller int extended to long. It is possible > for b / a to extend larger than an int so > it is long but b % a is always an int. > > I know C doesn't NEED these operators. But IMO > they would give it a kind of completion. im not sure if i understood what you mean here above but if to just copy to upper part its better tu use b.high = a where .higha and .low denote higher and lower parts; same help could be used for .mantisa .exponent and .sign it calso cn be used for carry c = a + b d + = c.carry (i thought once on just using free keyword "carry" that would caarry state but it coyuld be confusing probabbly better to tie it given value) (there is also doubt if not to enable such carry arithmetic in the bacground)
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-09-22 11:02 +0200 |
| Message-ID | <oq2jk0$r3v$1@dont-email.me> |
| In reply to | #120124 |
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
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-09-22 12:35 -0500 |
| Message-ID | <feiasc5h0024ts0o853lq8t1v6nulioiif@4ax.com> |
| In reply to | #120130 |
On Fri, 22 Sep 2017 11:02:53 +0200, Noob <root@127.0.0.1> 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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-09-22 13:46 -0400 |
| Message-ID | <P%bxB.189383$TH2.30767@fx02.iad> |
| In reply to | #120144 |
On 9/22/17 1:35 PM, Robert Wessel wrote:
> On Fri, 22 Sep 2017 11:02:53 +0200, Noob <root@127.0.0.1> 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.
>
Bit if an issue if you want an integral type that is twice as big as the
biggest integral type. f you got it, suddenly you don't anymore as you
have a new biggest integral type.
If you do need this, then you need to get into 'Big Num' math, which
tend to use as a base, something no bigger than 1/2 the bit width of the
biggest type, so it can support this sort of thing.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-22 11:47 -0700 |
| Message-ID | <7ac3b44a-b838-4462-88c8-adcd77d61ce1@googlegroups.com> |
| In reply to | #120145 |
On Friday, September 22, 2017 at 10:46:40 AM UTC-7, Richard Damon wrote:
> On 9/22/17 1:35 PM, Robert Wessel wrote:
> > On Fri, 22 Sep 2017 11:02:53 +0200, Noob <root@127.0.0.1> 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.
> >
>
>
> Bit if an issue if you want an integral type that is twice as big as the
> biggest integral type. f you got it, suddenly you don't anymore as you
> have a new biggest integral type.
>
> If you do need this, then you need to get into 'Big Num' math, which
> tend to use as a base, something no bigger than 1/2 the bit width of the
> biggest type, so it can support this sort of thing.
Another, nastier approach would be a unary operator - call it "$"
that chops off the lower half of a value.
Arithmetic on a n-bit computer - according to my definition -
is modulo 2^n arithmetic - unless one does something to
prevent it. In standard implementations division already
deviates because division makes no consistent sense in
modulo arithmetic. For example, in modulo 8
5/3 == 7
The nomenclature of C makes 32-bit the natural it. Because
the integer sizes are then:
char, short, int, long
But the natural int from the computer point-of-view is the
arithmetic modulo size. There seems to be a movement toward
what are called 64-bit implementations but I confess to not
knowing whether these implementations do modulo 2^64
arithmetic.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-22 12:16 -0700 |
| Message-ID | <b9f79976-91a0-48c9-884b-a673513911e1@googlegroups.com> |
| In reply to | #120147 |
On Friday, September 22, 2017 at 1:47:23 PM UTC-5, David Kleinecke wrote: > Another, nastier approach would be a unary operator - call it "$" > that chops off the lower half of a value. I could see some usefulness for operators +>>, ->>, and *>>, which when applied to matching non-promoted unsigned operands x and y, would compute the whole-number arithmetical value of (x+y)/(UINT_MAX+1) [or the max for the appropriate type], (x-y)/(UINT_MAX+1), or (x*y)/(UINT_MAX+1). I could also see usefulness for a /<< operator which would compute the arithmetical value of (x*(UINT_MAX+1))/y. > Arithmetic on a n-bit computer - according to my definition - > is modulo 2^n arithmetic - unless one does something to > prevent it. Allowing a compiler to perform integer arithmetic with larger types when it sees fit, while maintaining mod-wrapping behavior with whatever types it does happen to use, would allow many useful optimizations which would be impossible if programmers had to avoid integer overflow at all costs.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-09-22 18:10 -0400 |
| Message-ID | <eTfxB.189385$TH2.161875@fx02.iad> |
| In reply to | #120147 |
On 9/22/17 2:47 PM, David Kleinecke wrote:
> On Friday, September 22, 2017 at 10:46:40 AM UTC-7, Richard Damon wrote:
>> On 9/22/17 1:35 PM, Robert Wessel wrote:
>>> On Fri, 22 Sep 2017 11:02:53 +0200, Noob <root@127.0.0.1> 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.
>>>
>>
>>
>> Bit if an issue if you want an integral type that is twice as big as the
>> biggest integral type. f you got it, suddenly you don't anymore as you
>> have a new biggest integral type.
>>
>> If you do need this, then you need to get into 'Big Num' math, which
>> tend to use as a base, something no bigger than 1/2 the bit width of the
>> biggest type, so it can support this sort of thing.
>
> Another, nastier approach would be a unary operator - call it "$"
> that chops off the lower half of a value.
>
What's the problem with that? Returning only half the bits of a value is
easy, presumably you mean $x gives the upper half of x. Need to define
what to do with an odd number of bits, and the type of the results (the
C default would be int/unsigned unless x was a type with over twice the
number of bits of an int).
Now, if you mean to use it as a way to get the lost bits of the
multiply, it would need some very special wording, as $(a*b) would by
the basic grammar be too late to retrieve them.
> Arithmetic on a n-bit computer - according to my definition -
> is modulo 2^n arithmetic - unless one does something to
> prevent it. In standard implementations division already
> deviates because division makes no consistent sense in
> modulo arithmetic. For example, in modulo 8
> 5/3 == 7
Maybe your definition but not the Standards. (and what do you consider
5/2 to be?) The standard doesn't define all the values to represent an
equivalence class mod 2^n, but each number represents the base value and
results (for unsigned values) are reduced by modulo arithmetic into the
available range.
>
> The nomenclature of C makes 32-bit the natural it. Because
> the integer sizes are then:
> char, short, int, long
> But the natural int from the computer point-of-view is the
> arithmetic modulo size. There seems to be a movement toward
> what are called 64-bit implementations but I confess to not
> knowing whether these implementations do modulo 2^64
> arithmetic.
>
When C started, then 'normal' sizes (normal != required, but typical for
mainstream processors) was char=8b, short=16b, int=16b, long=32b, as the
most common processors had 16 bit primary registers (and these sizes are
reflected in the minimum allowed ranges for the types). These machines
were typically called 16 bit processors.
When processors started having 32 bit registers (and 32 bit pointers),
int was often promoted to having 32 bit (but many earlier systems might
have still kept it 16 bits, at least as an option, to keep from breaking
broken code). Some machines would go as far as making long 64 bits when
int when to 32 bits since the processor typically would support it, and
some programs assumed long was twice the size of int to allow full
precision multiplies for instance. Now the common sizes for 32 bit
machines are char=8b, short=16b, int=32b, long=64b.
Moving to 64 bits gives us an issue even bigger than before. Registers
ARE 64 bits, and we get natural arithmetic module 2^64, so ideally, int
would move to 64 bits, but then we run out of standard names for the
smaller types, having 3 sizes 8, 16, 32 but only two names char, short.
Because of this, some just keep int being 32 bits. (Some have proposed
that we need to add a type 'long short' to be the 32 bit type, or make
short be 32 bits and have a 'short short' type for 16 bits.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-22 15:24 -0700 |
| Message-ID | <ln60ca4bj6.fsf@kst-u.example.com> |
| In reply to | #120164 |
Richard Damon <Richard@Damon-Family.org> writes:
[...]
> When C started, then 'normal' sizes (normal != required, but typical for
> mainstream processors) was char=8b, short=16b, int=16b, long=32b, as the
> most common processors had 16 bit primary registers (and these sizes are
> reflected in the minimum allowed ranges for the types). These machines
> were typically called 16 bit processors.
K&R1, published in 1978, shows systems with 16-bit, 32-bit, and 36-bit
int.
[...]
> Moving to 64 bits gives us an issue even bigger than before. Registers
> ARE 64 bits, and we get natural arithmetic module 2^64, so ideally, int
> would move to 64 bits, but then we run out of standard names for the
> smaller types, having 3 sizes 8, 16, 32 but only two names char, short.
> Because of this, some just keep int being 32 bits. (Some have proposed
> that we need to add a type 'long short' to be the 32 bit type, or make
> short be 32 bits and have a 'short short' type for 16 bits.
My suggestion, requiring no changes to the language, would be to define
extended integer types for the intermediate sizes, and then define
[u]intN_t in terms of those types. That way if you specifically want 32
bits you can use int32_t (or int_fast32_t, or int_least32_t).
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-22 15:52 -0700 |
| Message-ID | <3dcd4745-8d42-4d82-87bf-7f304cfbdedb@googlegroups.com> |
| In reply to | #120165 |
On Friday, September 22, 2017 at 5:24:46 PM UTC-5, Keith Thompson wrote: > My suggestion, requiring no changes to the language, would be to define > extended integer types for the intermediate sizes, and then define > [u]intN_t in terms of those types. That way if you specifically want 32 > bits you can use int32_t (or int_fast32_t, or int_least32_t). I'd rather see a standard way of specifying what qualities of an integer type one does or doesn't care about, in such a way that existing implementations could use the preprocessor to handle specifications for types they already support [e.g. if code says it needs something that behaves as a 16-bit unsigned value that will be promoted to a 32-bit int when used in computation, and doesn't care about endianness, padding, or trap representations, a typical 32-bit implementation could simply make that an alias for "unsigned short"; existing 36-bit implementations would likely not support a type, but could be adapted to support code that would require them (whereas such implementations would be unable to support a conforming uint16_t at all except by making *all* operations on *all* types ignore four bits of every word).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-23 12:29 +0200 |
| Message-ID | <oq5d2l$ipp$1@dont-email.me> |
| In reply to | #120165 |
On 23/09/17 00:24, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: > [...] >> When C started, then 'normal' sizes (normal != required, but typical for >> mainstream processors) was char=8b, short=16b, int=16b, long=32b, as the >> most common processors had 16 bit primary registers (and these sizes are >> reflected in the minimum allowed ranges for the types). These machines >> were typically called 16 bit processors. > > K&R1, published in 1978, shows systems with 16-bit, 32-bit, and 36-bit > int. > > [...] > >> Moving to 64 bits gives us an issue even bigger than before. Registers >> ARE 64 bits, and we get natural arithmetic module 2^64, so ideally, int >> would move to 64 bits, but then we run out of standard names for the >> smaller types, having 3 sizes 8, 16, 32 but only two names char, short. >> Because of this, some just keep int being 32 bits. (Some have proposed >> that we need to add a type 'long short' to be the 32 bit type, or make >> short be 32 bits and have a 'short short' type for 16 bits. > > My suggestion, requiring no changes to the language, would be to define > extended integer types for the intermediate sizes, and then define > [u]intN_t in terms of those types. That way if you specifically want 32 > bits you can use int32_t (or int_fast32_t, or int_least32_t). > That would be nice. But I see a challenge here with types like uint8_t, on targets that have CHAR_BIT > 8. I don't think you can add an extended integer type that is smaller than "char". Of course a compiler can always simulate a type that is smaller than its natural smallest unit, but in doing so would not that new type become "char" ? At the other end of the scale, you can't add extended integers that are bigger than "long long" without having to change intmax_t - and that might easily go against a target's ABI. (That is, I believe, why gcc supports __int128 on many platforms but can't call it int128_t and it is technically not an extended integer type.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-23 08:29 -0700 |
| Message-ID | <7d15b601-ff45-4ff2-aab1-9c72f2dbcf48@googlegroups.com> |
| In reply to | #120194 |
On Saturday, September 23, 2017 at 5:29:47 AM UTC-5, David Brown wrote: > That would be nice. But I see a challenge here with types like uint8_t, > on targets that have CHAR_BIT > 8. I don't think you can add an > extended integer type that is smaller than "char". Of course a compiler > can always simulate a type that is smaller than its natural smallest > unit, but in doing so would not that new type become "char" ? Any type whose range is smaller than "unsigned char" would necessarily include padding bits, but if there were a way of specifying a variable type which is 8 bits with as much padding as needed to fill a "char", as well as a 16-bit type comprising two of those in big-endian, or little-endian, or compiler-preferred-endian order, a 32-bit type comprising two of those, etc. I don't see any problem with larger-char systems being able to process code written specifically for octet- based systems.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-23 18:06 -0700 |
| Message-ID | <lno9q03nxd.fsf@kst-u.example.com> |
| In reply to | #120194 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> That would be nice. But I see a challenge here with types like uint8_t,
> on targets that have CHAR_BIT > 8.
An implementation with CHAR_BIT > 8 cannot define uint8_t.
> At the other end of the scale, you can't add extended integers that are
> bigger than "long long" without having to change intmax_t - and that
> might easily go against a target's ABI. (That is, I believe, why gcc
> supports __int128 on many platforms but can't call it int128_t and it is
> technically not an extended integer type.)
Yes, I've complained about that before.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-24 12:28 +0200 |
| Message-ID | <oq81bg$j41$1@dont-email.me> |
| In reply to | #120216 |
On 24/09/17 03:06, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> That would be nice. But I see a challenge here with types like uint8_t, >> on targets that have CHAR_BIT > 8. > > An implementation with CHAR_BIT > 8 cannot define uint8_t. That's the point. You suggested that implementations that don't have standard types corresponding to types like in32_t could have extended integer types that they would then use. I think that's a good idea, but it can't be used for uint8_t on targets with CHAT_BIT > 8. You only talked about the intermediate sizes, which could be defined as extended integer types. I am just saying that it is unfortunate that the same process cannot be used to get uint8_t (etc.) when these are smaller than char. In my experience with DSP's with CHAR_BIT > 8, it is the small types like uint8_t you miss the most. > >> At the other end of the scale, you can't add extended integers that are >> bigger than "long long" without having to change intmax_t - and that >> might easily go against a target's ABI. (That is, I believe, why gcc >> supports __int128 on many platforms but can't call it int128_t and it is >> technically not an extended integer type.) > > Yes, I've complained about that before. >
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-22 16:17 -0700 |
| Message-ID | <f31a92e8-010b-4e0d-9e2d-8c43d240311e@googlegroups.com> |
| In reply to | #120164 |
On Friday, September 22, 2017 at 3:10:38 PM UTC-7, Richard Damon wrote:
> On 9/22/17 2:47 PM, David Kleinecke wrote:
> > On Friday, September 22, 2017 at 10:46:40 AM UTC-7, Richard Damon wrote:
> >> On 9/22/17 1:35 PM, Robert Wessel wrote:
> >>> On Fri, 22 Sep 2017 11:02:53 +0200, Noob <root@127.0.0.1> 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.
> >>>
> >>
> >>
> >> Bit if an issue if you want an integral type that is twice as big as the
> >> biggest integral type. f you got it, suddenly you don't anymore as you
> >> have a new biggest integral type.
> >>
> >> If you do need this, then you need to get into 'Big Num' math, which
> >> tend to use as a base, something no bigger than 1/2 the bit width of the
> >> biggest type, so it can support this sort of thing.
> >
> > Another, nastier approach would be a unary operator - call it "$"
> > that chops off the lower half of a value.
> >
> What's the problem with that? Returning only half the bits of a value is
> easy, presumably you mean $x gives the upper half of x. Need to define
> what to do with an odd number of bits, and the type of the results (the
> C default would be int/unsigned unless x was a type with over twice the
> number of bits of an int).
>
> Now, if you mean to use it as a way to get the lost bits of the
> multiply, it would need some very special wording, as $(a*b) would by
> the basic grammar be too late to retrieve them.
>
>
> > Arithmetic on a n-bit computer - according to my definition -
> > is modulo 2^n arithmetic - unless one does something to
> > prevent it. In standard implementations division already
> > deviates because division makes no consistent sense in
> > modulo arithmetic. For example, in modulo 8
> > 5/3 == 7
>
> Maybe your definition but not the Standards. (and what do you consider
> 5/2 to be?) The standard doesn't define all the values to represent an
> equivalence class mod 2^n, but each number represents the base value and
> results (for unsigned values) are reduced by modulo arithmetic into the
> available range.
>
> >
> > The nomenclature of C makes 32-bit the natural it. Because
> > the integer sizes are then:
> > char, short, int, long
> > But the natural int from the computer point-of-view is the
> > arithmetic modulo size. There seems to be a movement toward
> > what are called 64-bit implementations but I confess to not
> > knowing whether these implementations do modulo 2^64
> > arithmetic.
> >
>
> When C started, then 'normal' sizes (normal != required, but typical for
> mainstream processors) was char=8b, short=16b, int=16b, long=32b, as the
> most common processors had 16 bit primary registers (and these sizes are
> reflected in the minimum allowed ranges for the types). These machines
> were typically called 16 bit processors.
>
> When processors started having 32 bit registers (and 32 bit pointers),
> int was often promoted to having 32 bit (but many earlier systems might
> have still kept it 16 bits, at least as an option, to keep from breaking
> broken code). Some machines would go as far as making long 64 bits when
> int when to 32 bits since the processor typically would support it, and
> some programs assumed long was twice the size of int to allow full
> precision multiplies for instance. Now the common sizes for 32 bit
> machines are char=8b, short=16b, int=32b, long=64b.
>
> Moving to 64 bits gives us an issue even bigger than before. Registers
> ARE 64 bits, and we get natural arithmetic module 2^64, so ideally, int
> would move to 64 bits, but then we run out of standard names for the
> smaller types, having 3 sizes 8, 16, 32 but only two names char, short.
> Because of this, some just keep int being 32 bits. (Some have proposed
> that we need to add a type 'long short' to be the 32 bit type, or make
> short be 32 bits and have a 'short short' type for 16 bits.
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-22 18:20 -0700 |
| Message-ID | <ln1smy43e2.fsf@kst-u.example.com> |
| In reply to | #120169 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> Assuming the hardware arithmetic is 64-bit then I think it
> would be best to have "short" be 32-bit, char 8-bit and
> 16-bit "long char". "Wide char" would be more standard but
> why introduce a new keyword. "Short short" for 16-bit would
> be in the spirit of "long long" (which I assume no longer
> would exist).
How much existing code do you want to break?
--
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 | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-22 22:45 -0700 |
| Message-ID | <c53af292-20ea-4e60-9447-40d58bb26b25@googlegroups.com> |
| In reply to | #120178 |
On Friday, September 22, 2017 at 6:20:35 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > [...] > > Assuming the hardware arithmetic is 64-bit then I think it > > would be best to have "short" be 32-bit, char 8-bit and > > 16-bit "long char". "Wide char" would be more standard but > > why introduce a new keyword. "Short short" for 16-bit would > > be in the spirit of "long long" (which I assume no longer > > would exist). > > How much existing code do you want to break? Ah ha - a major difference in viewpoint. I wasn't addressing existing code at all. I have no desire to even bend any of it. I am looking forward. What I see is people using types like "uint8_t" instead of "unsigned char". I was trying bring the old C nomenclature back into good repute. IMO if one writes a program that depends on the bit size of one of the types one needs to document the fact and, hopefully, test early on that the size (in bytes) is correct. I think machine that are not byte-based need to used with great care and lots of special bells and whistles.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-23 12:22 +0200 |
| Message-ID | <oq5ckd$g80$1@dont-email.me> |
| In reply to | #120183 |
On 23/09/17 07:45, David Kleinecke wrote: > On Friday, September 22, 2017 at 6:20:35 PM UTC-7, Keith Thompson wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >> [...] >>> Assuming the hardware arithmetic is 64-bit then I think it >>> would be best to have "short" be 32-bit, char 8-bit and >>> 16-bit "long char". "Wide char" would be more standard but >>> why introduce a new keyword. "Short short" for 16-bit would >>> be in the spirit of "long long" (which I assume no longer >>> would exist). >> >> How much existing code do you want to break? > > Ah ha - a major difference in viewpoint. > > I wasn't addressing existing code at all. I have no > desire to even bend any of it. > > I am looking forward. What I see is people using types > like "uint8_t" instead of "unsigned char". I was trying > bring the old C nomenclature back into good repute. Why? The "old" - i.e., "real" C nomenclature is doing just fine. People are happy to use these types. And when people want size specific types, the C99 types like int32_t do the job (I use these extensively for my programming). Picking new meanings for the existing C type names with specific sizes seems like the worst possible combination of what we have today while ensuring that you break /all/ existing code, whether it uses "int" or "int32_t". > > IMO if one writes a program that depends on the bit size > of one of the types one needs to document the fact and, > hopefully, test early on that the size (in bytes) is > correct. I think machine that are not byte-based need to > used with great care and lots of special bells and > whistles. > Using types like uint8_t /is/ documenting that you depend on a particular bit size, and it tests at compile time that this size is supported.
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web