Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #4783 > unrolled thread
| Started by | Duncan Bayne <dhgbayne@gmail.com> |
|---|---|
| First post | 2011-05-25 20:27 -0700 |
| Last post | 2011-05-26 18:02 +0100 |
| Articles | 20 on this page of 150 — 40 participants |
Back to article view | Back to comp.lang.c
C programming in 2011 Duncan Bayne <dhgbayne@gmail.com> - 2011-05-25 20:27 -0700
Re: C programming in 2011 Shao Miller <sha0.miller@gmail.com> - 2011-05-25 22:33 -0500
Re: C programming in 2011 Duncan Bayne <dhgbayne@gmail.com> - 2011-05-25 20:58 -0700
Re: C programming in 2011 Duncan Bayne <dhgbayne@gmail.com> - 2011-05-25 21:06 -0700
Re: C programming in 2011 Shao Miller <sha0.miller@gmail.com> - 2011-05-25 23:24 -0500
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-26 07:51 +0000
Re: C programming in 2011 Chris H <chris@phaedsys.org> - 2011-05-26 11:15 +0100
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-26 06:53 -0400
Re: C programming in 2011 Ian Collins <ian-news@hotmail.com> - 2011-05-27 09:12 +1200
Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-05-29 00:39 +0100
Re: C programming in 2011 Noob <root@127.0.0.1> - 2011-06-01 17:38 +0200
Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-06-01 22:34 +0100
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-01 21:42 +0000
Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-06-02 00:33 +0100
Re: C programming in 2011 Duncan Bayne <dhgbayne@gmail.com> - 2011-05-26 03:41 -0700
Re: C programming in 2011 Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-28 00:46 +0000
Re: C programming in 2011 Chad <cdalten@gmail.com> - 2011-05-26 14:09 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-26 15:07 -0700
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-27 07:42 +0000
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-27 07:30 -0400
Re: C programming in 2011 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-29 01:15 +0300
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-28 22:24 +0000
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-28 16:08 -0700
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-28 23:47 +0000
Re: C programming in 2011 Geoff <geoff@invalid.invalid> - 2011-05-28 16:58 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-28 18:49 -0700
Re: C programming in 2011 Pierre Habouzit <madcoder@debian.org> - 2011-05-29 11:13 +0000
Re: C programming in 2011 Jorge <jorge@jorgechamorro.com> - 2011-06-04 08:05 -0700
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-04 16:20 +0000
Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-05-29 14:35 +0100
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-29 12:49 -0700
OT: Brackets, parentheses, etc. (Was: C programming in 2011) Shao Miller <sha0.miller@gmail.com> - 2011-05-29 16:13 -0500
Re: OT: Brackets, parentheses, etc. (Was: C programming in 2011) "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-05-30 12:17 -0400
Re: OT: Brackets, parentheses, etc. (Was: C programming in 2011) Shao Miller <sha0.miller@gmail.com> - 2011-05-30 12:52 -0500
Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-05-29 23:58 +0100
Re: C programming in 2011 Chris H <chris@phaedsys.org> - 2011-05-30 14:42 +0100
Re: C programming in 2011 Nizumzen <chicken@mcnuggets.com> - 2011-05-30 17:40 +0100
Re: C programming in 2011 Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2011-05-30 22:38 +0200
Re: C programming in 2011 "J. J. Farrell" <jjf@bcs.org.uk> - 2011-05-30 00:38 +0100
Re: C programming in 2011 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-30 11:14 +0300
Re: C programming in 2011 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-29 06:55 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-28 18:47 -0700
Re: C programming in 2011 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-30 15:02 +0300
Re: C programming in 2011 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-30 11:01 +0300
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-30 08:51 +0000
Re: C programming in 2011 Nobody <nobody@nowhere.com> - 2011-05-31 01:54 +0100
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-05-31 12:00 +0000
Re: C programming in 2011 Seebs <usenet-nospam@seebs.net> - 2011-05-31 16:44 +0000
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-31 11:43 -0700
Re: C programming in 2011 Chris H <chris@phaedsys.org> - 2011-05-26 11:13 +0100
Re: C programming in 2011 Francois Grieu <fgrieu@gmail.com> - 2011-05-26 16:04 +0200
Re: C programming in 2011 Branimir Maksimovic <bmaxa@hotmail.com> - 2011-05-26 16:21 +0200
Re: C programming in 2011 Francois Grieu <fgrieu@gmail.com> - 2011-05-26 17:23 +0200
Re: C programming in 2011 Branimir Maksimovic <bmaxa@hotmail.com> - 2011-05-26 19:15 +0200
Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-05-26 17:29 +0000
Re: C programming in 2011 Branimir Maksimovic <bmaxa@hotmail.com> - 2011-05-26 20:10 +0200
Re: C programming in 2011 Pierre Habouzit <madcoder@debian.org> - 2011-05-26 17:35 +0000
Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-05-26 17:53 +0000
Re: C programming in 2011 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-26 11:13 -0700
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-26 21:57 -0400
Re: C programming in 2011 Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-31 01:13 -0700
Re: C programming in 2011 Branimir Maksimovic <bmaxa@hotmail.com> - 2011-05-26 20:06 +0200
Re: C programming in 2011 Ralf Damaschke <rwspam@gmx.de> - 2011-05-26 17:57 +0000
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-26 11:31 -0700
Re: C programming in 2011 Ralf Damaschke <rwspam@gmx.de> - 2011-05-26 20:43 +0000
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-26 14:53 -0700
Re: C programming in 2011 Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-31 01:03 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-31 01:59 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-31 02:55 -0700
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-31 06:36 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-31 05:57 -0700
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-05-31 09:23 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-31 07:50 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-05-31 11:41 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 01:46 -0700
Re: C programming in 2011 Ike Naar <ike@iceland.freeshell.org> - 2011-06-01 10:07 +0000
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 04:12 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 07:46 -0700
Re: C programming in 2011 Seebs <usenet-nospam@seebs.net> - 2011-06-01 17:53 +0000
Re: C programming in 2011 lawrence.jones@siemens.com - 2011-06-01 16:28 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 23:28 -0700
Re: C programming in 2011 Uno <Uno@example.invalid> - 2011-06-09 21:24 -0600
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 10:04 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 08:21 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 09:37 -0700
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 12:55 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 11:52 -0700
Re: C programming in 2011 "J. J. Farrell" <jjf@bcs.org.uk> - 2011-06-02 00:00 +0100
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 23:19 -0700
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 12:53 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 11:55 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-01 08:41 -0700
Re: C programming in 2011 Noob <root@127.0.0.1> - 2011-06-01 17:12 +0200
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-01 09:28 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-01 08:38 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 01:00 -0700
Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-06-02 09:13 +0000
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 02:52 -0700
Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-06-02 11:41 +0000
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 05:53 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 06:49 -0700
Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-06-02 14:18 +0000
Re: C programming in 2011 Seebs <usenet-nospam@seebs.net> - 2011-06-02 21:02 +0000
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 23:55 -0700
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-03 08:37 +0000
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-03 06:49 -0400
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-03 11:52 +0000
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 11:11 -0700
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-03 18:23 +0000
Re: C programming in 2011 Seebs <usenet-nospam@seebs.net> - 2011-06-03 18:59 +0000
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-03 19:48 +0000
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 15:02 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-03 12:19 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 13:40 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-03 15:11 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 15:24 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-03 15:34 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-03 17:10 -0700
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-03 17:34 -0700
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-04 09:47 -0400
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-02 10:02 -0400
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-02 12:17 +0000
Re: C programming in 2011 Keith Thompson <kst-u@mib.org> - 2011-06-02 08:48 -0700
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-02 10:35 -0700
Re: C programming in 2011 gordonb.jpem8@burditt.org (Gordon Burditt) - 2011-06-05 23:32 -0500
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-06 00:12 -0700
Re: C programming in 2011 gordonb.5k8u2@burditt.org (Gordon Burditt) - 2011-06-06 05:18 -0500
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-06 08:16 -0700
Re: C programming in 2011 Michael Press <rubrum@pacbell.net> - 2011-06-03 18:06 -0700
Re: C programming in 2011 gordonb.zourz@burditt.org (Gordon Burditt) - 2011-06-05 21:25 -0500
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-06 01:14 -0700
Re: C programming in 2011 gordonb.donaz@burditt.org (Gordon Burditt) - 2011-06-06 04:36 -0500
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-06 09:02 -0700
Re: C programming in 2011 gordonb.k6ruq@burditt.org (Gordon Burditt) - 2011-06-06 18:36 -0500
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-07 10:14 -0700
Re: C programming in 2011 "J. J. Farrell" <jjf@bcs.org.uk> - 2011-05-31 19:56 +0100
Re: C programming in 2011 Noob <root@127.0.0.1> - 2011-06-01 14:54 +0200
Re: C programming in 2011 Angel <angel+news@spamcop.net> - 2011-06-01 13:07 +0000
Re: C programming in 2011 pete <pfiland@mindspring.com> - 2011-06-01 14:10 -0400
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 19:58 -0400
Re: C programming in 2011 Willem <willem@toad.stack.nl> - 2011-06-01 09:07 +0000
Re: C programming in 2011 James Kuyper <jameskuyper@verizon.net> - 2011-06-01 09:29 -0400
Re: C programming in 2011 David Thompson <dave.thompson2@verizon.net> - 2011-06-07 02:18 -0400
Re: C programming in 2011 "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-06-07 09:31 -0700
Re: C programming in 2011 Patrick Scheible <kkt@zipcon.net> - 2011-06-09 14:55 -0700
Re: C programming in 2011 Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-01 02:35 -0700
Re: C programming in 2011 Francois Grieu <fgrieu@gmail.com> - 2011-05-31 21:57 +0200
Re: C programming in 2011 Francois Grieu <fgrieu@gmail.com> - 2011-05-31 22:03 +0200
Re: C programming in 2011 Kenneth Brody <kenbrody@spamcop.net> - 2011-05-26 12:27 -0400
Re: C programming in 2011 Nobody <nobody@nowhere.com> - 2011-05-26 18:02 +0100
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-01 23:28 -0700 |
| Message-ID | <a2feb7e6-73e5-4ade-bd91-79a7a1eb3c57@b42g2000yqi.googlegroups.com> |
| In reply to | #5241 |
On Jun 1, 10:28 pm, lawrence.jo...@siemens.com wrote: > Kleuskes & Moos <kleu...@xs4all.nl> wrote: > > > > > There is a reason, and a very good one, too, that sign-and-magnitude > > isn't used anymore. If you have a different opinion, please post the > > hardware in question. I'd be curious. > > Note the decimal arithmetic was dead, buried, and fossilized until IBM > resurrected it a couple years ago and it suddenly became the hotest > thing in hardware design. If you think that's the 'hottest thing in hardware design', you haven't been paying attention to actual 'hot things' in hardware design.
[toc] | [prev] | [next] | [standalone]
| From | Uno <Uno@example.invalid> |
|---|---|
| Date | 2011-06-09 21:24 -0600 |
| Message-ID | <95dh2kFm5mU1@mid.individual.net> |
| In reply to | #5241 |
On 06/01/2011 02:28 PM, lawrence.jones@siemens.com wrote: > Kleuskes& Moos<kleuske@xs4all.nl> wrote: >> >> There is a reason, and a very good one, too, that sign-and-magnitude >> isn't used anymore. If you have a different opinion, please post the >> hardware in question. I'd be curious. > > Note the decimal arithmetic was dead, buried, and fossilized until IBM > resurrected it a couple years ago and it suddenly became the [hottest] > thing in hardware design. That's news to me. Is hot good? -- Uno
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-06-01 10:04 -0400 |
| Message-ID | <is5gsr$24o$1@dont-email.me> |
| In reply to | #5163 |
On 06/01/2011 04:46 AM, Kleuskes & Moos wrote: > On May 31, 8:41�pm, Keith Thompson <ks...@mib.org> wrote: >> "Kleuskes & Moos" <kleu...@xs4all.nl> writes: >>> On May 31, 3:23�pm, James Kuyper <jameskuy...@verizon.net> wrote: ... >>>> An obvious possibility is a platform with no hardware support for >>>> unsigned integers - depending upon the precise details of it's >>>> instruction set, it could be easiest to implement unsigned ints as >>>> signed ints with a range restricted to non-negative values. However, I >>>> claim no familiarity with any such system. >> >>> Such a system would not be able to operate, since every relative jmp- >>> instruction involves the addition (or subtraction, which is basically >>> the same). So name that fabled platform. >> >> How do you know what's involved in relative jump instructions on a >> hypothetical system that might not even exist? > > What other methods of doing relative jumps did you have in mind? Since > you think there's an alternative, it's up to you to name it. How about adding a signed integer value to the current address, which is also a signed integer, giving a result which is also a signed integer, and therefore a valid address on that platform? >>> Not so obscure that unsigned integers are not supported, after all, >>> every physical and logical memory address is, basically, an unsigned >>> integer. >> >> On some systems, yes. �On the hypothetical system in question, it's >> likely that physical and logical memory addresses are represented as >> signed integers. �For example, if it's a 32-bit system, addresses might >> range from -2147483648 to +2147483647. > > Ah. Another hypothetical system that defies the laws of common > sense... No, it's not another hypothetical system, it's a more specific example of the same hypothetical. Keith said as much: "On the hypothetical system in question ...". You might try reading more closely. ... > To me, the flurry of hypotheticals merely indicates that i was right, > but you don't like admitting it, so you're grasping at hypothetical > straws. No, it simply means that we prefer to avoid writing code that relies upon guarantees not provided by the standard. You don't care about that, and you have every right not to care about it. With that right comes the responsibility of accepting the consequences in the event (which you consider very unlikely to occur) that your code needs to be ported to an implementation which violates them. > Besides, a pattern of bits on the address bus, and this would be the > best objection you can make, can be interpreted as signed _or_ > unsigned at the whim of whomsoever is interpreting it. It really makes > no difference, it's just a question of how you interpret them. It makes no difference in 2's complement; it can make a big difference in the other two permitted representations of signed integers. But you are, of course, free to assumes that 2's complement is the only representation in use now or ever again in the future, if that's what you want to assume. ... >> On such a system, it would make sense to have: >> � � INT_MIN = -2147483648 >> � � INT_MAX = +2147483647 >> � � UINT_MAX = INT_MAX Actually, Keith's example is somewhat poorly chosen. Because of the equivalence between 2's complement signed operations and corresponding unsigned operations, a platform which could only natively support signed math would have to be using one of the other two representations. >> and for unsigned int to have a single padding bit in place of >> signed int's sign bit. �And that would probably result in much more >> efficient code than forcing unsigned int to have 32 value bits and >> perform most unsigned operations in software. �(Perhaps unsigned long >> would be 32 bits wide, and be slower than unsigned int.) > > Ok. > > Let me pose two simple questions... > > How does a CPU add 1 and 1 and arrive at the (correct) answer: 2? We postulated that this hypothetical platform has built-in hardware support for signed arithmetic. Do you need details in the form of hardware layout and a list of the supported machine instructions? I'm not a hardware designer, I'm sure I'd make lots of mistakes in any attempt to provide such a specification. Are you really in doubt about the feasibility of implementing signed arithmetic? > How do signed and unsigned versions of this operation differ? The signed instructions interpret the memory as signed integers in, let's say, 1's complement representation. Unsigned versions of the operation are non-existent, and unsigned arithmetic must therefore be emulated, since the signed operations would not produce the correct result if the unsigned result would be greater than INT_MAX, or if the result of applying those operations would be negative. > The question "why doesn't anyone design a computer that does not > support unsigned arithmatic" should be obvious, if you got the above > two questions right, and hypothetical, highly unpractical systems > should then be laid to rest. You'll need to explain the point you're trying to make. It's not at all clear to me what problem you're thinking of, so I can't evaluate whether it makes any sense to worry about that problem. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-01 08:21 -0700 |
| Message-ID | <bdc98020-79b4-4978-847c-cd676a0ab1b8@p13g2000yqh.googlegroups.com> |
| In reply to | #5180 |
On Jun 1, 4:04 pm, James Kuyper <jameskuy...@verizon.net> wrote: > On 06/01/2011 04:46 AM, Kleuskes & Moos wrote: > > > > > > > > > > > On May 31, 8:41 pm, Keith Thompson <ks...@mib.org> wrote: > >> "Kleuskes & Moos" <kleu...@xs4all.nl> writes: > >>> On May 31, 3:23 pm, James Kuyper <jameskuy...@verizon.net> wrote: > ... > >>>> An obvious possibility is a platform with no hardware support for > >>>> unsigned integers - depending upon the precise details of it's > >>>> instruction set, it could be easiest to implement unsigned ints as > >>>> signed ints with a range restricted to non-negative values. However, I > >>>> claim no familiarity with any such system. > > >>> Such a system would not be able to operate, since every relative jmp- > >>> instruction involves the addition (or subtraction, which is basically > >>> the same). So name that fabled platform. > > >> How do you know what's involved in relative jump instructions on a > >> hypothetical system that might not even exist? > > > What other methods of doing relative jumps did you have in mind? Since > > you think there's an alternative, it's up to you to name it. > > How about adding a signed integer value to the current address, which is > also a signed integer, giving a result which is also a signed integer, > and therefore a valid address on that platform As i already pointed out elsethread, it doesn't make any difference. Most relative jumps rely on signed integers for the offset anyway, but ultimately any idea of 'signed integers' is something _we_ assign to a specified set of bits, it's not inherent in the contents of the address-bus and memory chips only look to see whether an adressline is high or low. So you can interpret addresses any way you want, treating them as unsigned integers is simply more convenient. But hey... If you prefer to view them as signed integers... > >>> Not so obscure that unsigned integers are not supported, after all, > >>> every physical and logical memory address is, basically, an unsigned > >>> integer. > > >> On some systems, yes. On the hypothetical system in question, it's > >> likely that physical and logical memory addresses are represented as > >> signed integers. For example, if it's a 32-bit system, addresses might > >> range from -2147483648 to +2147483647. > > > Ah. Another hypothetical system that defies the laws of common > > sense... > > No, it's not another hypothetical system, it's a more specific example > of the same hypothetical. Keith said as much: "On the hypothetical > system in question ...". You might try reading more closely. The 'hypothetical' was enough. 'Hypothetical' means 'I have no counterexample so i'll just start playing games'. At least Ike dug up a nice fossil of a brontosaur. > > To me, the flurry of hypotheticals merely indicates that i was right, > > but you don't like admitting it, so you're grasping at hypothetical > > straws. > > No, it simply means that we prefer to avoid writing code that relies > upon guarantees not provided by the standard. How nice. > You don't care about that, Nope. I just program _real_ computers instead of hypothetical ones. Besides, your claim to know what i care about or not is not only presumptious, but also quite pigheaded. > and you have every right not to care about it. How nice. > With that right comes the > responsibility of accepting the consequences in the event (which you > consider very unlikely to occur) that your code needs to be ported to an > implementation which violates them. So far, we've got one example out of the dark ages which _might_ satisfy the condition that started this subthread, and a host of hypothetical, and highly implausible systems which might if the designers of the CPU were _very_ silly. Your rather pompous assertions about my sense of responsability does nothing to convince me otherwise, but achieve rather the opposite and convinces me you have no arguments but ad-hominem ones. > > Besides, a pattern of bits on the address bus, and this would be the > > best objection you can make, can be interpreted as signed _or_ > > unsigned at the whim of whomsoever is interpreting it. It really makes > > no difference, it's just a question of how you interpret them. > > It makes no difference in 2's complement; it can make a big difference > in the other two permitted representations of signed integers. But you > are, of course, free to assumes that 2's complement is the only > representation in use now or ever again in the future, if that's what > you want to assume. If i ever encounter an UNIVAC 7094 again, i'll be on my toes. And thanks for pointing out in such clarity why the other two mandated numbersystems are obsolete by now. <snip boring stuff> > > Let me pose two simple questions... > > > How does a CPU add 1 and 1 and arrive at the (correct) answer: 2? > > We postulated that this hypothetical platform has built-in hardware > support for signed arithmetic. Anyone can postulate anything, but no-one can run any software on postulated machines, so the answer is already wrong. Do you need details in the form of > hardware layout and a list of the supported machine instructions? Just the basic circuit will do. Even a list of components for a 2-bit adder > I'm > not a hardware designer, I'm sure I'd make lots of mistakes in any > attempt to provide such a specification. Are you really in doubt about > the feasibility of implementing signed arithmetic? Nope. I just wanted to know whether or not you have any idea what you're talking about. It appears you have no idea. See http://en.wikipedia.org/wiki/Full_adder > > How do signed and unsigned versions of this operation differ? > > The signed instructions interpret the memory as signed integers in, > let's say, 1's complement representation. Unsigned versions of the > operation are non-existent, and unsigned arithmetic must therefore be > emulated, since the signed operations would not produce the correct > result if the unsigned result would be greater than INT_MAX, or if the > result of applying those operations would be negative. > > > The question "why doesn't anyone design a computer that does not > > support unsigned arithmatic" should be obvious, if you got the above > > two questions right, and hypothetical, highly unpractical systems > > should then be laid to rest. > > You'll need to explain the point you're trying to make. It's not at all > clear to me what problem you're thinking of, so I can't evaluate whether > it makes any sense to worry about that problem. In terms of hardware, the actual gates being used, both 1's complement (mainly because of the double 0) and signed magnitude are expensive. You need extra hardware to take care of a lot of things and extra hardware costs time, money and dissipates power. 2's complement can use the same circuits to do addition, subtraction (and hence comparisons), signed and unsigned, using the same circuits. That, basically, is why every processor uses 2's complement nowadays, instead of one of the others. And that's why i feel quite comfortable knowing UINT_MAX==INT_MAX only in hypothetical cases.
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-01 09:37 -0700 |
| Message-ID | <0d058b4a-57d5-419e-b095-4c327370ab35@d1g2000yqm.googlegroups.com> |
| In reply to | #5194 |
On Jun 1, 5:21 pm, "Kleuskes & Moos" <kleu...@xs4all.nl> wrote: > On Jun 1, 4:04 pm, James Kuyper <jameskuy...@verizon.net> wrote: > > > > > > > > > > > On 06/01/2011 04:46 AM, Kleuskes & Moos wrote: > > > > On May 31, 8:41 pm, Keith Thompson <ks...@mib.org> wrote: > > >> "Kleuskes & Moos" <kleu...@xs4all.nl> writes: > > >>> On May 31, 3:23 pm, James Kuyper <jameskuy...@verizon.net> wrote: > > ... > > >>>> An obvious possibility is a platform with no hardware support for > > >>>> unsigned integers - depending upon the precise details of it's > > >>>> instruction set, it could be easiest to implement unsigned ints as > > >>>> signed ints with a range restricted to non-negative values. However, I > > >>>> claim no familiarity with any such system. > > > >>> Such a system would not be able to operate, since every relative jmp- > > >>> instruction involves the addition (or subtraction, which is basically > > >>> the same). So name that fabled platform. > > > >> How do you know what's involved in relative jump instructions on a > > >> hypothetical system that might not even exist? > > > > What other methods of doing relative jumps did you have in mind? Since > > > you think there's an alternative, it's up to you to name it. > > > How about adding a signed integer value to the current address, which is > > also a signed integer, giving a result which is also a signed integer, > > and therefore a valid address on that platform > > As i already pointed out elsethread, it doesn't make any difference. > Most relative jumps rely on signed integers for the offset anyway, but > ultimately any idea of 'signed integers' is something _we_ assign to a > specified set of bits, it's not inherent in the contents of the > address-bus and memory chips only look to see whether an adressline is > high or low. So you can interpret addresses any way you want, treating > them as unsigned integers is simply more convenient. > > But hey... If you prefer to view them as signed integers... > > > >>> Not so obscure that unsigned integers are not supported, after all, > > >>> every physical and logical memory address is, basically, an unsigned > > >>> integer. > > > >> On some systems, yes. On the hypothetical system in question, it's > > >> likely that physical and logical memory addresses are represented as > > >> signed integers. For example, if it's a 32-bit system, addresses might > > >> range from -2147483648 to +2147483647. > > > > Ah. Another hypothetical system that defies the laws of common > > > sense... > > > No, it's not another hypothetical system, it's a more specific example > > of the same hypothetical. Keith said as much: "On the hypothetical > > system in question ...". You might try reading more closely. > > The 'hypothetical' was enough. 'Hypothetical' means 'I have no > counterexample so i'll just start playing games'. At least Ike dug up > a nice fossil of a brontosaur. > > > > To me, the flurry of hypotheticals merely indicates that i was right, > > > but you don't like admitting it, so you're grasping at hypothetical > > > straws. > > > No, it simply means that we prefer to avoid writing code that relies > > upon guarantees not provided by the standard. > > How nice. > > > You don't care about that, > > Nope. I just program _real_ computers instead of hypothetical ones. > Besides, your claim to know what i care about or not is not only > presumptious, but also quite pigheaded. > > > and you have every right not to care about it. > > How nice. > > > With that right comes the > > responsibility of accepting the consequences in the event (which you > > consider very unlikely to occur) that your code needs to be ported to an > > implementation which violates them. > > So far, we've got one example out of the dark ages which _might_ > satisfy the condition that started this subthread, and a host of > hypothetical, and highly implausible systems which might if the > designers of the CPU were _very_ silly. > > Your rather pompous assertions about my sense of responsability does > nothing to convince me otherwise, but achieve rather the opposite and > convinces me you have no arguments but ad-hominem ones. > > > > Besides, a pattern of bits on the address bus, and this would be the > > > best objection you can make, can be interpreted as signed _or_ > > > unsigned at the whim of whomsoever is interpreting it. It really makes > > > no difference, it's just a question of how you interpret them. > > > It makes no difference in 2's complement; it can make a big difference > > in the other two permitted representations of signed integers. But you > > are, of course, free to assumes that 2's complement is the only > > representation in use now or ever again in the future, if that's what > > you want to assume. > > If i ever encounter an UNIVAC 7094 again, i'll be on my toes. And > thanks for pointing out in such clarity why the other two mandated > numbersystems are obsolete by now. > <snip boring stuff> > > > > Let me pose two simple questions... > > > > How does a CPU add 1 and 1 and arrive at the (correct) answer: 2? > > > We postulated that this hypothetical platform has built-in hardware > > support for signed arithmetic. > > Anyone can postulate anything, but no-one can run any software on > postulated machines, so the answer is already wrong. > > Do you need details in the form of > > > hardware layout and a list of the supported machine instructions? > > Just the basic circuit will do. Even a list of components for a 2-bit > adder > > > I'm > > not a hardware designer, I'm sure I'd make lots of mistakes in any > > attempt to provide such a specification. Are you really in doubt about > > the feasibility of implementing signed arithmetic? > > Nope. I just wanted to know whether or not you have any idea what > you're talking about. It appears you have no idea. > > Seehttp://en.wikipedia.org/wiki/Full_adder > > > > > > > > > > > > How do signed and unsigned versions of this operation differ? > > > The signed instructions interpret the memory as signed integers in, > > let's say, 1's complement representation. Unsigned versions of the > > operation are non-existent, and unsigned arithmetic must therefore be > > emulated, since the signed operations would not produce the correct > > result if the unsigned result would be greater than INT_MAX, or if the > > result of applying those operations would be negative. > > > > The question "why doesn't anyone design a computer that does not > > > support unsigned arithmatic" should be obvious, if you got the above > > > two questions right, and hypothetical, highly unpractical systems > > > should then be laid to rest. > > > You'll need to explain the point you're trying to make. It's not at all > > clear to me what problem you're thinking of, so I can't evaluate whether > > it makes any sense to worry about that problem. > > In terms of hardware, the actual gates being used, both 1's complement > (mainly because of the double 0) and signed magnitude are expensive. > You need extra hardware to take care of a lot of things and extra > hardware costs time, money and dissipates power. > 2's complement can use the same circuits to do addition, subtraction > (and hence comparisons), signed and unsigned, using the same circuits. > That, basically, is why every processor uses 2's complement nowadays, > instead of one of the others. > > And that's why i feel quite comfortable knowing UINT_MAX==INT_MAX only > in hypothetical cases. Adding to that, i've never in my career encountered a situation where i had to assume anything beyond what's in the standard about either UINT_MAX or INT_MAX.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-06-01 12:55 -0400 |
| Message-ID | <is5qte$8bo$2@dont-email.me> |
| In reply to | #5201 |
On 06/01/2011 12:37 PM, Kleuskes & Moos wrote: ... > Adding to that, i've never in my career encountered a situation where > i had to assume anything beyond what's in the standard about either > UINT_MAX or INT_MAX. Then why in the world are you arguing against restricting one's assumptions to those guaranteed by the standard? -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-01 11:52 -0700 |
| Message-ID | <51fdbf8b-c7e9-41f5-98b3-a71e5fee9b13@24g2000yqk.googlegroups.com> |
| In reply to | #5207 |
On Jun 1, 6:55 pm, James Kuyper <jameskuy...@verizon.net> wrote: > On 06/01/2011 12:37 PM, Kleuskes & Moos wrote: > ... > > > Adding to that, i've never in my career encountered a situation where > > i had to assume anything beyond what's in the standard about either > > UINT_MAX or INT_MAX. > > Then why in the world are you arguing against restricting one's > assumptions to those guaranteed by the standard? I wasn't. I was just making the point.
[toc] | [prev] | [next] | [standalone]
| From | "J. J. Farrell" <jjf@bcs.org.uk> |
|---|---|
| Date | 2011-06-02 00:00 +0100 |
| Message-ID | <is6gb9$tpn$1@dont-email.me> |
| In reply to | #5220 |
Kleuskes & Moos wrote: > On Jun 1, 6:55 pm, James Kuyper <jameskuy...@verizon.net> wrote: >> On 06/01/2011 12:37 PM, Kleuskes & Moos wrote: >> ... >> >>> Adding to that, i've never in my career encountered a situation where >>> i had to assume anything beyond what's in the standard about either >>> UINT_MAX or INT_MAX. >> Then why in the world are you arguing against restricting one's >> assumptions to those guaranteed by the standard? > > I wasn't. I was just making the point. Would you mind clarifying what your point is exactly, I've been struggling to understand it. Someone said, in effect, "if you want to write code which is correct on all possible C implementations then you need to allow for the fact that UINT_MAX == INT_MAX may be true". You appear to be countering with "if you want to write code which is correct on all known and foreseeable C implementations, then you don't need to allow for the fact that UINT_MAX == INT_MAX may be true". I don't see any conflict between these statements. What exactly is this vehement discussion about?
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-01 23:19 -0700 |
| Message-ID | <f56a76b1-cea6-4c75-b94f-7846c7ee7e1e@h9g2000yqk.googlegroups.com> |
| In reply to | #5242 |
On Jun 2, 1:00 am, "J. J. Farrell" <j...@bcs.org.uk> wrote: > Kleuskes & Moos wrote: > > On Jun 1, 6:55 pm, James Kuyper <jameskuy...@verizon.net> wrote: > >> On 06/01/2011 12:37 PM, Kleuskes & Moos wrote: > >> ... > > >>> Adding to that, i've never in my career encountered a situation where > >>> i had to assume anything beyond what's in the standard about either > >>> UINT_MAX or INT_MAX. > >> Then why in the world are you arguing against restricting one's > >> assumptions to those guaranteed by the standard? > > > I wasn't. I was just making the point. > > Would you mind clarifying what your point is exactly, I've been > struggling to understand it. 'UINT_MAX == INTMAX' is only true in hypothetical cases*). <snip> > What exactly is this vehement discussion about? As far as i can gather... next to nothing. Or, if i formulate a bit more friendly, wether or not hypothetical, highly implausible fringe- cases should be a consideration when designing software. *) Anno domini 2011, in the 60's and 70's it may have had some validity on some machines.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-06-01 12:53 -0400 |
| Message-ID | <is5qqb$8bo$1@dont-email.me> |
| In reply to | #5194 |
On 06/01/2011 11:21 AM, Kleuskes & Moos wrote: > On Jun 1, 4:04�pm, James Kuyper <jameskuy...@verizon.net> wrote: ... > The 'hypothetical' was enough. 'Hypothetical' means 'I have no > counterexample so i'll just start playing games'. It doesn't bother me that I have no counter-example, because the point I'm making only concerns with what the standard mandates and allows. Keeping track of what's actually true on all current implementations of C is something that would require more work than I have time for. If that constitutes "playing games" in your book, then feel free to think of it that way; I'll continue to think of what you're doing as "making unjustified assumptions". ... >> No, it simply means that we prefer to avoid writing code that relies >> upon guarantees not provided by the standard. > > How nice. > >> You don't care about that, > > Nope. I just program _real_ computers instead of hypothetical ones. I program real computers with code that will work even on hypothetical ones, so long as there is a compiler on those machines which is at least backwardly compatible with C99; which means my code will continue to work even if your assumptions about what "real machines" do become inaccurate. ... > Besides, your claim to know what i care about or not is not only > presumptious, but also quite pigheaded. You're correct, I can only infer what you care about from your actual words, you could secretly care about these issues far more than your words imply. But I can only pay attention to your words, I don't have the power to read your mind. I'll have to form my guesses as to what you care about based upon your actual words. If those guesses are inaccurate, it's due to a failure of your words to correctly reflect your true beliefs. ... >> With that right comes the >> responsibility of accepting the consequences in the event (which you >> consider very unlikely to occur) that your code needs to be ported to an >> implementation which violates them. ... > Your rather pompous assertions about my sense of responsability I said nothing about your sense of responsibility, only your responsibilities themselves. That you might be insensible of those responsibilities seems entirely plausible, and even likely. ... >> I'm >> not a hardware designer, I'm sure I'd make lots of mistakes in any >> attempt to provide such a specification. Are you really in doubt about >> the feasibility of implementing signed arithmetic? > > Nope. I just wanted to know whether or not you have any idea what > you're talking about. It appears you have no idea. I have an idea, it's just not my specialty. I know enough to know that all three of the methods permitted by the C standard for representing signed integers have actually been implemented, on the hardware level, on real machines, and that only one of those methods (admittedly, the most popular) provides any support for your arguments. That is, it would provide such support for your arguments, if it were the only possible way of doing signed integer arithmetic; but it isn't. ... >> You'll need to explain the point you're trying to make. It's not at all >> clear to me what problem you're thinking of, so I can't evaluate whether >> it makes any sense to worry about that problem. > > In terms of hardware, the actual gates being used, both 1's complement > (mainly because of the double 0) and signed magnitude are expensive. Which is very different from being impossible, which is what would need to be the case to support your argument. The other ways of representing signed integers have their own peculiar advantages, or they would never have been tried. When our current technologies for making computer chips have become obsolete, and something entirely different comes along to replace them, with it's own unique cost structure, the costs could easily swing the other way. I don't know whether this particular assumption will ever fail. But if you make a habit of relying on such assumptions, as seems likely, I can virtually guarantee that one of your assumptions will fail. Code which avoids making unnecessary assumptions about such things will survive such a transition; the programmers who have to port the other code will spend a lot of time swearing at you. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-01 11:55 -0700 |
| Message-ID | <f0111e7a-bcb8-4eae-b994-562a8b9c9009@v10g2000yqn.googlegroups.com> |
| In reply to | #5206 |
On Jun 1, 6:53 pm, James Kuyper <jameskuy...@verizon.net> wrote: > On 06/01/2011 11:21 AM, Kleuskes & Moos wrote: > > > On Jun 1, 4:04 pm, James Kuyper <jameskuy...@verizon.net> wrote: > ... > > The 'hypothetical' was enough. 'Hypothetical' means 'I have no > > counterexample so i'll just start playing games'. > > It doesn't bother me that I have no counter-example, because the point > I'm making only concerns with what the standard mandates and allows. > Keeping track of what's actually true on all current implementations of > C is something that would require more work than I have time for. > > If that constitutes "playing games" in your book, then feel free to > think of it that way; I'll continue to think of what you're doing as > "making unjustified assumptions". > > ... > > >> No, it simply means that we prefer to avoid writing code that relies > >> upon guarantees not provided by the standard. > > > How nice. > > >> You don't care about that, > > > Nope. I just program _real_ computers instead of hypothetical ones. > > I program real computers with code that will work even on hypothetical > ones, so long as there is a compiler on those machines which is at least > backwardly compatible with C99; which means my code will continue to > work even if your assumptions about what "real machines" do become > inaccurate. > > ... > > > Besides, your claim to know what i care about or not is not only > > presumptious, but also quite pigheaded. > > You're correct, I can only infer what you care about from your actual > words, you could secretly care about these issues far more than your > words imply. But I can only pay attention to your words, I don't have > the power to read your mind. I'll have to form my guesses as to what you > care about based upon your actual words. If those guesses are > inaccurate, it's due to a failure of your words to correctly reflect > your true beliefs. > > ... > > >> With that right comes the > >> responsibility of accepting the consequences in the event (which you > >> consider very unlikely to occur) that your code needs to be ported to an > >> implementation which violates them. > ... > > Your rather pompous assertions about my sense of responsability > > I said nothing about your sense of responsibility, only your > responsibilities themselves. That you might be insensible of those > responsibilities seems entirely plausible, and even likely. <snip> Ok. Now the debate has degraded to ad-hominem remarks, any further discussion is a waste of time. Have a nice day.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-06-01 08:41 -0700 |
| Message-ID | <lnoc2hmudj.fsf@nuthaus.mib.org> |
| In reply to | #5180 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 06/01/2011 04:46 AM, Kleuskes & Moos wrote:
>> On May 31, 8:41 pm, Keith Thompson <ks...@mib.org> wrote:
[...]
>>> On such a system, it would make sense to have:
>>> INT_MIN = -2147483648
>>> INT_MAX = +2147483647
>>> UINT_MAX = INT_MAX
>
> Actually, Keith's example is somewhat poorly chosen. Because of the
> equivalence between 2's complement signed operations and corresponding
> unsigned operations, a platform which could only natively support signed
> math would have to be using one of the other two representations.
I was thinking of a (hypothetical) system that traps on signed overflow.
This might be more plausible for a virtual machine than for real hardware.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2011-06-01 17:12 +0200 |
| Message-ID | <is5kt0$drb$1@speranza.aioe.org> |
| In reply to | #5163 |
Kleuskes & Moos wrote: > How does a CPU add 1 and 1 and arrive at the (correct) answer: 2? > How do signed and unsigned versions of this operation differ? Tangential nit :-) Not all operations can ignore the "signed-ness" of its operands. Consider a platform (such as x86) with 32-bit registers, and a 32x32->64 multiply operation. Regards.
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-01 09:28 -0700 |
| Message-ID | <b818b1fc-6075-40d0-9e62-6c063a05200e@x6g2000yqj.googlegroups.com> |
| In reply to | #5192 |
On Jun 1, 5:12 pm, Noob <r...@127.0.0.1> wrote: > Kleuskes & Moos wrote: > > How does a CPU add 1 and 1 and arrive at the (correct) answer: 2? > > How do signed and unsigned versions of this operation differ? > > Tangential nit :-) > > Not all operations can ignore the "signed-ness" of its operands. > Consider a platform (such as x86) with 32-bit registers, and a > 32x32->64 multiply operation. > > Regards. Absolutely right.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-06-01 08:38 -0700 |
| Message-ID | <lnsjrtmuie.fsf@nuthaus.mib.org> |
| In reply to | #5163 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes:
> On May 31, 8:41 pm, Keith Thompson <ks...@mib.org> wrote:
>> "Kleuskes & Moos" <kleu...@xs4all.nl> writes:
>> > On May 31, 3:23 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>> >> On 05/31/2011 08:57 AM, Kleuskes & Moos wrote:
>> >> > On May 31, 12:36 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>> >> ...
>> >> >> The closest the standard comes to directly constraining UINT_MAX
>> >> >> relative to INT_MAX is in 6.2.5p9: "The range of nonnegative values of a
>> >> >> signed integer type is a subrange of the corresponding unsigned integer
>> >> >> type, ...". That corresponds to the constraint UINT_MAX >= INT_MAX; it
>> >> >> is not violated by UINT_MAX==INT_MAX.
>>
>> >> > True. But then there's "not violating a constraint" and there's sheer,
>> >> > unadulterated sillyness of actually creating an implementation in
>> >> > which UINT_MAX==INT_MAX, since you would be throwing away half the
>> >> > range of the unsigned integer (and that goes in all three mandated
>> >> > numbersystems).
>>
>> >> > So while it may not violate the standard, it _is_ silly, and i would
>> >> > very much like to know which compiler meets UINT_MAX==INT_MAX. Just so
>> >> > that i can avoid it.
>> [...]
>> >> An obvious possibility is a platform with no hardware support for
>> >> unsigned integers - depending upon the precise details of it's
>> >> instruction set, it could be easiest to implement unsigned ints as
>> >> signed ints with a range restricted to non-negative values. However, I
>> >> claim no familiarity with any such system.
>>
>> > Such a system would not be able to operate, since every relative jmp-
>> > instruction involves the addition (or subtraction, which is basically
>> > the same). So name that fabled platform.
>>
>> How do you know what's involved in relative jump instructions on a
>> hypothetical system that might not even exist?
>
> What other methods of doing relative jumps did you have in mind? Since
> you think there's an alternative, it's up to you to name it.
I have no idea, and no, it's not up to me to name it. You've made an
assertion about how relative jump instructions work, presumably on *all*
systems.
>
> <snip>
>
>> > Not so obscure that unsigned integers are not supported, after all,
>> > every physical and logical memory address is, basically, an unsigned
>> > integer.
>>
>> On some systems, yes. On the hypothetical system in question, it's
>> likely that physical and logical memory addresses are represented as
>> signed integers. For example, if it's a 32-bit system, addresses might
>> range from -2147483648 to +2147483647.
>
> Ah. Another hypothetical system that defies the laws of common
> sense... Great, what advantages does your hypothetical system with
> signed memory addresses have? More importantly, how does that jive
> with the electronics of the address-bus of that hypothetical system?
("jibe")
I wasn't aware that signed addresses defied the laws of common
sense. Perhaps they do. I do not claim that such systems have
any particular advantages, or even that they necessarily exist (I
honestly don't know whether they do or not), merely that they're
possible.
Now that I think about it, perhaps a virtual machine would be more
likely to have such characteristics, especially if it's implemented
in a language that doesn't support unsigned arithmetic (Pascal,
for example). I have some documentation on the old UCSD Pascal system;
I'll look into it later.
> Objections concerning some hypothetical system which uses signed
> integers as memory addresses and do not support nsigned integers are
> not quite taken seriously on my side of the NNTP-server. Why not
> invent a hypothetical system which uses pink bunnies to address
> memory?
Why not? There's no particular reason such a system coulnd't
support a conforming C implementation.
>> > So, noting the absence of any argument otherwise, UINT_MAX==INT_MAX is
>> > only possible theoretically, but the chances of actually running into
>> > it are virtually nonexistent, that is, somewhere between "highly
>> > unlikely" and "absolute zero". In practice UINT_MAX > INT_MAX, and i
>> > dare you to show me an example to the contrary.
>>
>> I do not claim that such an example exists, but it *could*.
>
> Yes. And the chip-select signal might be delivered by invisible pink
> unicorns, the Carry Flag might be hoisted by Daffy Duck and interrupts
> might be implemented by Yosemity Sam, firing his guns at the hootenest-
> tootenest-shootenest programmable interrupt controller north, east,
> south AAAAND west of the Pecos.
And you find these as plausible as UINT_MAX==INT_MAX?
> To me, the flurry of hypotheticals merely indicates that i was right,
> but you don't like admitting it, so you're grasping at hypothetical
> straws.
You were right about what, exactly?
This is not a zero-sum game where one of us wins and one of us loses.
It's a technical discussion.
Do any systems with UINT_MAX==INT_MAX actually exist? I don't know; I
make no claim one way or the other. You claim that there are no such
systems; as far as I know, you may be right.
But this is comp.lang.c, not comp.arch, and the main point I've been
making is that such systems are permitted by the C standard. (I'm
reasonably sure I'm right about that; if you agree, that doens't mean
you're admitting defeat.)
>> Perhaps it could be a specialized system, not primarily designed with C
>> in mind, but intended to support an environment which has no need for
>> unsigned arithmetic (and no, address calculations don't *necessarily*
>> require unsigned integer arithmetic).
>
> Ok. So name a (non-hypothetical) example of adddresses not being
> unsigned integers. I wager a case of Grolsch you won't be able to. Not
> because it's not possible, just because it's unpractical.
You're asking me to support a claim I never made.
> Besides, a pattern of bits on the address bus, and this would be the
> best objection you can make, can be interpreted as signed _or_
> unsigned at the whim of whomsoever is interpreting it. It really makes
> no difference, it's just a question of how you interpret them.
But ok, let's say we have a system with a 16-bit address space,
with addresses ranging from 0 to 65535, and with each byte in that
range being addressible. What happens if you start with a pointer
to memory location 65535, and then increment it? Unless there's
hardware checking, the result will probably point to address 0.
Or, equivalently, we started with address -1 and incremented it to
address 0.
> But, given the practicalities of hardware design, they are usually
> interpreted as being unsigned, simply because it's more convenient.
If address arithmetic doesn't check for overflow or wraparound, it may
be *conceptually* more convenient to think of addresses as unsigned, but
the hardware doesn't necessarily care.
>> On such a system, it would make sense to have:
>> INT_MIN = -2147483648
>> INT_MAX = +2147483647
>> UINT_MAX = INT_MAX
>> and for unsigned int to have a single padding bit in place of
>> signed int's sign bit. And that would probably result in much more
>> efficient code than forcing unsigned int to have 32 value bits and
>> perform most unsigned operations in software. (Perhaps unsigned long
>> would be 32 bits wide, and be slower than unsigned int.)
>
> Ok.
>
> Let me pose two simple questions...
>
> How does a CPU add 1 and 1 and arrive at the (correct) answer: 2?
Magic. 8-)} Seriously, I'm not much of a hardware guy, but we can
agree that CPUs can add.
> How do signed and unsigned versions of this operation differ?
Depends on the system. On some systems, there might be a hardware trap
on overflow; the conditions in which that trap will be triggered might
differ for signed and unsigned add instructions. Maybe. And no, I
don't have concrete examples.
> The question "why doesn't anyone design a computer that does not
> support unsigned arithmatic" should be obvious, if you got the above
> two questions right, and hypothetical, highly unpractical systems
> should then be laid to rest.
>
>> The point is that C is designed to be implementable with reasonable
>> efficiency on a wide variety of systems.
>
> True. But i doubt you'll find ANY that match the exotic, nay,
> excentric hardware you describe. I still dare yoou to name a single
> CPU that does not support unsigned integers, and i'm very confident
> you won't find any.
Again, I've never claimed that such a CPU exists.
>> There are more things in heaven and earth, Horatio, ...
>
> True. But that's no argument.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-02 01:00 -0700 |
| Message-ID | <34987001-82df-4e25-9173-e79d84b6e340@h7g2000yqa.googlegroups.com> |
| In reply to | #5196 |
On Jun 1, 5:38 pm, Keith Thompson <ks...@mib.org> wrote:
> "Kleuskes & Moos" <kleu...@xs4all.nl> writes:
>
>
>
>
>
>
>
>
>
> > On May 31, 8:41 pm, Keith Thompson <ks...@mib.org> wrote:
> >> "Kleuskes & Moos" <kleu...@xs4all.nl> writes:
> >> > On May 31, 3:23 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> >> >> On 05/31/2011 08:57 AM, Kleuskes & Moos wrote:
> >> >> > On May 31, 12:36 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> >> >> ...
> >> >> >> The closest the standard comes to directly constraining UINT_MAX
> >> >> >> relative to INT_MAX is in 6.2.5p9: "The range of nonnegative values of a
> >> >> >> signed integer type is a subrange of the corresponding unsigned integer
> >> >> >> type, ...". That corresponds to the constraint UINT_MAX >= INT_MAX; it
> >> >> >> is not violated by UINT_MAX==INT_MAX.
>
> >> >> > True. But then there's "not violating a constraint" and there's sheer,
> >> >> > unadulterated sillyness of actually creating an implementation in
> >> >> > which UINT_MAX==INT_MAX, since you would be throwing away half the
> >> >> > range of the unsigned integer (and that goes in all three mandated
> >> >> > numbersystems).
>
> >> >> > So while it may not violate the standard, it _is_ silly, and i would
> >> >> > very much like to know which compiler meets UINT_MAX==INT_MAX. Just so
> >> >> > that i can avoid it.
> >> [...]
> >> >> An obvious possibility is a platform with no hardware support for
> >> >> unsigned integers - depending upon the precise details of it's
> >> >> instruction set, it could be easiest to implement unsigned ints as
> >> >> signed ints with a range restricted to non-negative values. However, I
> >> >> claim no familiarity with any such system.
>
> >> > Such a system would not be able to operate, since every relative jmp-
> >> > instruction involves the addition (or subtraction, which is basically
> >> > the same). So name that fabled platform.
>
> >> How do you know what's involved in relative jump instructions on a
> >> hypothetical system that might not even exist?
>
> > What other methods of doing relative jumps did you have in mind? Since
> > you think there's an alternative, it's up to you to name it.
>
> I have no idea, and no, it's not up to me to name it. You've made an
> assertion about how relative jump instructions work, presumably on *all*
> systems.
I have, since it's the only plausible way to implement them, simply
because the simplest definition of a relative jump is
PC <-- PC+offset
and, frankly, i don't see any other way to implement one. But that may
be just my lack of imagination, so if you do know of another method,
then please.
<snip>
> > Ah. Another hypothetical system that defies the laws of common
> > sense... Great, what advantages does your hypothetical system with
> > signed memory addresses have? More importantly, how does that jive
> > with the electronics of the address-bus of that hypothetical system?
>
> ("jibe")
>
> I wasn't aware that signed addresses defied the laws of common
> sense. Perhaps they do. I do not claim that such systems have
> any particular advantages, or even that they necessarily exist (I
> honestly don't know whether they do or not), merely that they're
> possible.
As pointed out elsthread, signed or unsigned is in the eye of the
beholder. Viewing them as unsigned is simply more convenient, having
an address range [0...MemSize>.
> Now that I think about it, perhaps a virtual machine would be more
> likely to have such characteristics, especially if it's implemented
> in a language that doesn't support unsigned arithmetic (Pascal,
> for example).
Implementing a virtual machine in Pascal? Sure it's possible, pascal
is turing-complete, after all.
> I have some documentation on the old UCSD Pascal system;
> I'll look into it later.
I'd be interested, but i was talking about _real_ processors. Virtual
ones have quite a different set of constraints and design
considerations.
> > Objections concerning some hypothetical system which uses signed
> > integers as memory addresses and do not support nsigned integers are
> > not quite taken seriously on my side of the NNTP-server. Why not
> > invent a hypothetical system which uses pink bunnies to address
> > memory?
>
> Why not? There's no particular reason such a system coulnd't
> support a conforming C implementation.
True, but the chances of one actually getting a) designed b)
implemented and c) bought and used are approaching 0 with a
frightening speed and such systems do not interest me.
<snip>
> > Yes. And the chip-select signal might be delivered by invisible pink
> > unicorns, the Carry Flag might be hoisted by Daffy Duck and interrupts
> > might be implemented by Yosemity Sam, firing his guns at the hootenest-
> > tootenest-shootenest programmable interrupt controller north, east,
> > south AAAAND west of the Pecos.
>
> And you find these as plausible as UINT_MAX==INT_MAX?
Slightly less plausible. I'm surprized at having to explain such an
obvious rethorical remark.
> > To me, the flurry of hypotheticals merely indicates that i was right,
> > but you don't like admitting it, so you're grasping at hypothetical
> > straws.
>
> You were right about what, exactly?
UINT_MAX == INTE_MAX is only valid in hypothetical cases, as i've
already explained several times.
> This is not a zero-sum game where one of us wins and one of us loses.
> It's a technical discussion.
Aye. "Winning, loosing, no matter. Make good fight."
> Do any systems with UINT_MAX==INT_MAX actually exist? I don't know; I
> make no claim one way or the other. You claim that there are no such
> systems; as far as I know, you may be right.
Ok.
> But this is comp.lang.c, not comp.arch, and the main point I've been
> making is that such systems are permitted by the C standard. (I'm
> reasonably sure I'm right about that; if you agree, that doens't mean
> you're admitting defeat.)
The C standard, by it's very nature, is stated as generally as
possible, and, as i've stated upthread, the standard allows for a lot
of implausible implementations including ones in which the condition
in question is true, simply to give compiler-makers enough leeway to
cater to even the most obscure hardware. That's a good thing.
That does not mean that every possibility allowed by the standard
should be taken into consideration, especially those that, by their
very nature, are _very_ implausible.
Even if it's allowed by the standard, i would not expect any system to
launch the complete nuclear arsenal of the western world every time
someone invokes undefined behavior, nor do i take that into account
when designing software.
> >> Perhaps it could be a specialized system, not primarily designed with C
> >> in mind, but intended to support an environment which has no need for
> >> unsigned arithmetic (and no, address calculations don't *necessarily*
> >> require unsigned integer arithmetic).
>
> > Ok. So name a (non-hypothetical) example of adddresses not being
> > unsigned integers. I wager a case of Grolsch you won't be able to. Not
> > because it's not possible, just because it's unpractical.
>
> You're asking me to support a claim I never made.
Perhaps.
> > Besides, a pattern of bits on the address bus, and this would be the
> > best objection you can make, can be interpreted as signed _or_
> > unsigned at the whim of whomsoever is interpreting it. It really makes
> > no difference, it's just a question of how you interpret them.
>
> But ok, let's say we have a system with a 16-bit address space,
> with addresses ranging from 0 to 65535, and with each byte in that
> range being addressible. What happens if you start with a pointer
> to memory location 65535, and then increment it?
I'm sure you can figure that one out for yourself.
> Unless there's hardware checking, the result will probably point to
> address 0.
> Or, equivalently, we started with address -1 and incremented it to
> address 0.
That seems plausible. What's the point?
> > But, given the practicalities of hardware design, they are usually
> > interpreted as being unsigned, simply because it's more convenient.
>
> If address arithmetic doesn't check for overflow or wraparound, it may
> be *conceptually* more convenient to think of addresses as unsigned, but
> the hardware doesn't necessarily care.
That was the point i made above.
<snip>
> > How does a CPU add 1 and 1 and arrive at the (correct) answer: 2?
>
> Magic. 8-)} Seriously, I'm not much of a hardware guy, but we can
> agree that CPUs can add.
>
> > How do signed and unsigned versions of this operation differ?
>
> Depends on the system. On some systems, there might be a hardware trap
> on overflow; the conditions in which that trap will be triggered might
> differ for signed and unsigned add instructions. Maybe. And no, I
> don't have concrete examples.
On 2's complement systems, they do not differ. As explained
elsethread, that's one of the main reasons 2's-complement is the de-
facto standard nowadays.
> > The question "why doesn't anyone design a computer that does not
> > support unsigned arithmatic" should be obvious, if you got the above
> > two questions right, and hypothetical, highly unpractical systems
> > should then be laid to rest.
>
> >> The point is that C is designed to be implementable with reasonable
> >> efficiency on a wide variety of systems.
>
> > True. But i doubt you'll find ANY that match the exotic, nay,
> > excentric hardware you describe. I still dare yoou to name a single
> > CPU that does not support unsigned integers, and i'm very confident
> > you won't find any.
>
> Again, I've never claimed that such a CPU exists.
Non-existent CPU's are also non-interesting.
[toc] | [prev] | [next] | [standalone]
| From | Willem <willem@toad.stack.nl> |
|---|---|
| Date | 2011-06-02 09:13 +0000 |
| Message-ID | <slrniuel22.10na.willem@toad.stack.nl> |
| In reply to | #5255 |
Kleuskes & Moos wrote:
) I have, since it's the only plausible way to implement them, simply
) because the simplest definition of a relative jump is
)
) PC <-- PC+offset
And how does that involve unsigned integers specifically ?
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-02 02:52 -0700 |
| Message-ID | <feb6a9b3-acd0-402a-91ba-fd0969615839@n11g2000yqf.googlegroups.com> |
| In reply to | #5258 |
On Jun 2, 11:13 am, Willem <wil...@toad.stack.nl> wrote: > Kleuskes & Moos wrote: > > ) I have, since it's the only plausible way to implement them, simply > ) because the simplest definition of a relative jump is > ) > ) PC <-- PC+offset > > And how does that involve unsigned integers specifically ? PC is an unsigned integer, for all intents and purposes.
[toc] | [prev] | [next] | [standalone]
| From | Willem <willem@toad.stack.nl> |
|---|---|
| Date | 2011-06-02 11:41 +0000 |
| Message-ID | <slrniuetmh.1mvh.willem@toad.stack.nl> |
| In reply to | #5259 |
Kleuskes & Moos wrote:
) On Jun 2, 11:13?am, Willem <wil...@toad.stack.nl> wrote:
)> Kleuskes & Moos wrote:
)>
)> ) I have, since it's the only plausible way to implement them, simply
)> ) because the simplest definition of a relative jump is
)> )
)> ) PC <-- PC+offset
)>
)> And how does that involve unsigned integers specifically ?
)
) PC is an unsigned integer, for all intents and purposes.
Begging the question: You're assuming the existence of unsigned integers
to prove the existence of unsigned integers.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-02 05:53 -0700 |
| Message-ID | <c6ceb1e4-7fff-40cf-bb7c-afd2a91f5355@y19g2000yqk.googlegroups.com> |
| In reply to | #5265 |
On Jun 2, 1:41 pm, Willem <wil...@toad.stack.nl> wrote: > Kleuskes & Moos wrote: > > ) On Jun 2, 11:13?am, Willem <wil...@toad.stack.nl> wrote: > )> Kleuskes & Moos wrote: > )> > )> ) I have, since it's the only plausible way to implement them, simply > )> ) because the simplest definition of a relative jump is > )> ) > )> ) PC <-- PC+offset > )> > )> And how does that involve unsigned integers specifically ? > ) > ) PC is an unsigned integer, for all intents and purposes. > > Begging the question: You're assuming the existence of unsigned integers > to prove the existence of unsigned integers. Are you claiming unsigned integers don't exist?
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web