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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-06-02 10:02 -0400 |
| Message-ID | <is855g$iul$1@dont-email.me> |
| In reply to | #5270 |
On 06/02/2011 08:53 AM, Kleuskes & Moos wrote: > 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? That appears to be poor wording on his part. I think that what he actually meant was something like: "You're assuming that support for unsigned integer arithmetic must be available on all systems, in order to prove that it must be available." This appears to be a fairly accurate description of your "argument", such as it is. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Angel <angel+news@spamcop.net> |
|---|---|
| Date | 2011-06-02 12:17 +0000 |
| Message-ID | <slrniuevrf.38c.angel+news@pearlgates.net> |
| In reply to | #5259 |
On 2011-06-02, Kleuskes & Moos <kleuske@xs4all.nl> 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. It's a sequence of bits, nothing more and nothing less. Its existence does not prove that the implementation can handle unsigned integers. CPUs work with sequences of bits only, because that is the only thing they can understand. The CPU doesn't usually know what the bits it is tossing around represent, the interpretation of that happens on a higher abstraction level. -- "C provides a programmer with more than enough rope to hang himself. C++ provides a firing squad, blindfold and last cigarette." - seen in comp.lang.c
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-06-02 08:48 -0700 |
| Message-ID | <lnhb88kzdo.fsf@nuthaus.mib.org> |
| In reply to | #5255 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes:
> 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:
[...]
>> >> 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>
Ok, a relative jump is basically
PC <-- PC+offset
Not that it's necessarily the case that a CPU must directly support
relative jumps, but that's beside the point. (And no, I'm not claiming
that there are CPUs that don't support relative jumps, or that there
aren't; it's just not particularly relevant to C.)
But nothing in that description implies unsigned arithmetic.
Presumably the offset is signed. Why can't the PC (program counter)
be signed?
(Asserting that it's unsigned does not answer the above question.)
>> > 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>.
Sometimes you argue that signed addresses defy the laws of common sense.
And sometimes you argue that addresses can be viewed as either signed or
unsigned, whichever is more convenient. I see a contradiction.
>> 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.
Virtual processors are just as valid a target for a C implementation as
real ones.
>> > 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.
You spend a great deal of time arguing about something that doesn't
interest you.
> <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.
As you've already *asserted* several times.
[...]
>> 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.
The C standard is stated very generally, but *not* "as generally as
possible". There are plenty of characteristics, some of them things
that have existed in real-world systems, that are excluded (some of
which can be worked around in software). Some examples: Bytes must
be at least 8 bits. Type int must be at least 16 bits. Data must
be represented in binary. Signed integers must be represented in
either 2's-complement, 1s'-complement, or sign-and-magnitude (biased
representations are not permitted). Floating-point is mandatory.
Most of the flexibility is there either because there have been
real-world systems that need it, or because a greater range of
permitted characteristics is simpler to describe. It's fairly
safe to assume that there are no systems with 137-bit bytes, but
the standard doesn't go out of its way to forbid it.
> 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.
Not if the hardware doesn't actually interact with the nuclear
arsenal. But some systems do exactly that, and if they're
implemented in C (which, personally, I hope they're not) they had
bloody well better avoid anything approaching undefined behavior.
Perhaps more realistically, you might assume that a C program with
undefined behavior can't possibly reformat your hard drive -- but
if the process it's running in has the capability of invoking the
"please reformat my hard drive" routine, and a function pointer
somewhere gets clobbered, it could very well do that.
[...]
>> > 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.
That wasn't the point of the question.
>> 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?
The point, which you've acknowledged, is that it can be perfectly
reasonable to think of memory addresses as signed integers.
Which means that you can't reasonably use memory addresses as an
argument that all systems *must* support unsigned arithmetic.
>> > 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.
That's one of the two contradictory points you made. The other point
you made is that the "practicalities of hardware design" imply somehow
that addresses are necessarly unsigned.
> <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.
And as I explained, *if the system traps on signed overflow*,
there is a very real difference between signed and unsigned addition.
>> > 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.
Again, you've spent a great deal of time discussing something that you
find non-interesting. Are you trying to convince me that I shouldn't be
interested in them either?
--
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 10:35 -0700 |
| Message-ID | <3efde497-4ad8-47e6-8435-259dfb3ab93b@l26g2000yqm.googlegroups.com> |
| In reply to | #5283 |
On Jun 2, 5:48 pm, Keith Thompson <ks...@mib.org> wrote: > "Kleuskes & Moos" <kleu...@xs4all.nl> writes: > > > 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: > [...] > >> >> 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> > > Ok, a relative jump is basically > PC <-- PC+offset > > Not that it's necessarily the case that a CPU must directly support > relative jumps, but that's beside the point. (And no, I'm not claiming > that there are CPUs that don't support relative jumps, or that there > aren't; it's just not particularly relevant to C.) > > But nothing in that description implies unsigned arithmetic. > Presumably the offset is signed. Why can't the PC (program counter) > be signed? Basically, it makes no big difference, and if you insist on viewing the PC as signed, then you would end up with a consistent picture. It may just not be that convenient. In a simple staightforward addressing scheme, say a 16-bit address bus, your memory layout would be slighly weird if you install 48k (16 ROM/32kRAM) of actual memory. You would have one range [0..32k> and one [-32k..-16k>, assuming the layout of your address-bus isn't something weird, too. And trust me... The hardware guys don't like that and will probably call you "very silly, indeed", in polite terms and/or behind your back, of course, if you ask them to design something like that. > (Asserting that it's unsigned does not answer the above question.) I hope the above satisfies your demand. <snip> > > 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>. > > Sometimes you argue that signed addresses defy the laws of common sense. > And sometimes you argue that addresses can be viewed as either signed or > unsigned, whichever is more convenient. I see a contradiction. In theory, you can view them as whatevery you want. What matters is not what numerical value _we_ assign to an address, its what's presented to the hardware what matters. On many systems, especially if you're dealing with Nkx8 memory, no single memory chip is connected to every address-line, that is, sees the entire address. The numerical values are imposed and you can think of them as being signed, if you like, but as explained above, it just ain't practical. > >> 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. > > Virtual processors are just as valid a target for a C implementation as > real ones. True. > >> > 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. > > You spend a great deal of time arguing about something that doesn't > interest you. True. Bu then again, discussion sharpens the mind, and every participant may end up having learned something, so i still consider it worthwhile to bicker about not-so-interesting hypotheticals. And besides... It's fun. <snip> > >> You were right about what, exactly? > > > UINT_MAX == INTE_MAX is only valid in hypothetical cases, as i've > > already explained several times. > > As you've already *asserted* several times. Yup. I've spent quite some time explaining why i asserted that, written extensive posts, was accused of logical fallacies, rebuked for not strictly adhering to the standard, and called irresonsable by insinuation, but, sofar, nobody's proven the simple assertion wrong. So please. Bring an example and i will stand corrected. > [...] > > >> 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. > > The C standard is stated very generally, but *not* "as generally as > possible". There are plenty of characteristics, some of them things > that have existed in real-world systems, that are excluded (some of > which can be worked around in software). Some examples: Bytes must > be at least 8 bits. Type int must be at least 16 bits. Data must > be represented in binary. Signed integers must be represented in > either 2's-complement, 1s'-complement, or sign-and-magnitude (biased > representations are not permitted). Floating-point is mandatory. Ok. You got a nit. It's _only_ stated _very_ generally and not "as generally as possible". Don't you get a strange feeling that you might be arguing over semantics here? I would. > Most of the flexibility is there either because there have been > real-world systems that need it, or because a greater range of > permitted characteristics is simpler to describe. It's fairly > safe to assume that there are no systems with 137-bit bytes, but > the standard doesn't go out of its way to forbid it. Fortunately not, because there's some _really_ weird hardware out there. Especially in the museum. Did you ever hear of "bit-slicers"? It's perfectly feasable to build a 137-bit computer using those. 68HC11 has 13 bits addresses and a harvard architecture. But the again, it just ain't practical. Last use i heard of a bitslicer was as a fire control in a goalkeeper anti-missile gun, but i don't remember much of the detail. I digress... > > 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. > > Not if the hardware doesn't actually interact with the nuclear > arsenal. But some systems do exactly that, and if they're > implemented in C (which, personally, I hope they're not) they had > bloody well better avoid anything approaching undefined behavior. > > Perhaps more realistically, you might assume that a C program with > undefined behavior can't possibly reformat your hard drive -- but > if the process it's running in has the capability of invoking the > "please reformat my hard drive" routine, and a function pointer > somewhere gets clobbered, it could very well do that. The point to be made was: "not everything allowed by the standard is likely, or even possible". I'm sorry i made you think that i was trying to imply that _any_ invocation of undefined behavior is allowable, but sometimes i think people argueing the details of The Standard are also capable of reading a simple post without making undue inferences. I will try to spell it out next time. > [...] > > >> > 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. > > That wasn't the point of the question. > >> 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? > > The point, which you've acknowledged, is that it can be perfectly > reasonable to think of memory addresses as signed integers. Yes. But it's just not practical, and i've explained above _why_ it's not practical. Besides, i've pointed out on several occasions that it's possible. It's not practical, is the point. > Which means that you can't reasonably use memory addresses as an > argument that all systems *must* support unsigned arithmetic. I don't argue they *must*, i argue they *do*. Not for theoretical reasons, but for very practical reasons. There's a shitload of weird and excentric systems one might, hypothetically, build and which would, theoretically, work, bot the point is, nobody does, since there's no reason to. > >> > 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. > > That's one of the two contradictory points you made. The other point > you made is that the "practicalities of hardware design" imply somehow > that addresses are necessarly unsigned. I said it's more practical to view them as such, because it's simpler. You can just view the n bits of the address line as an n-bit number instead of a 2's complement number. And if you're making electronics- designs, you like things like that to be simple and straightforward and not be hindered by positive and negative adresses when there's no good reason to do so. And since the CPU-designers view adresses as unsigned integers, and the board-designers view adresses as unsigned integers, it's best software guys don't try to invent signed addresses, since that only complicates things for no good reason whatsoever. > > 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. > > And as I explained, *if the system traps on signed overflow*, > there is a very real difference between signed and unsigned addition. Not that big a difference. <snip> > > Non-existent CPU's are also non-interesting. > > Again, you've spent a great deal of time discussing something that you > find non-interesting. I try not to, but then again, you must eat the porridge to get the raisins. > Are you trying to convince me that I shouldn't be interested in them either? Not really. I'm merely trying to avoid getting drawn into a quagmire of ill-conceived, ad-hoc hypotheticals.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.jpem8@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2011-06-05 23:32 -0500 |
| Message-ID | <lcCdnb8oBO3FxXHQnZ2dnUVZ_gidnZ2d@posted.internetamerica> |
| In reply to | #5255 |
> 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 There's no reason you can't add a signed (possibly shorter) offset to an unsigned number and get a reasonable unsigned result. Yes, it might go out of range and trap, or go out of range and execute garbage, or wrap around and trap, or wrap around and execute garbage. The same problem is also likely to happen if you didn't install the maximum amount of memory that you could install, and run off the end. Some machines that have relative branches have only relative branches with short offsets (if you want to go a longer distance, use an absolute branch, which likely takes a longer instruction, or perhaps a longer relative branch, if there is one. x86 has relative branches with 8 and 16-bit offsets, for example). How many bits are in the offset tends to be a function of how many bits are left in the instruction word without extending it, at instruction set design time. So you might have a relative branch with a 13-bit offset on a machine with a 32-bit address. If the *only* branches are relative branches, then you need to be able to branch from anywhere to anywhere, and traps on "overflow" (signed or unsigned) are a problem. It is usually not that much of a problem to ignore the "overflow" indication. (Note: if you can add *positive* integers, you can ignore trapping overflow by adding a bit at the high-order end of the adder, and hard-wire the inputs as 0's, and ignore the output of that bit.) Relative branches with short offsets tend to have signed offsets because they are more useful that way than ones that only go forward or only go backwards. Instruction set designers are aware of this. Some machines have instructions that are multiples of and aligned to something larger than bytes (e.g. 16 bits). On these machines, the formula might be: PC <-- PC + (2 * offset) because the low-order bit of the offset is omitted (it's always 0) and the low-order bit of the PC doesn't really exist (it's hardwired to 0). That 13-bit offset might actually get squeezed into 12 bits.
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-06 00:12 -0700 |
| Message-ID | <f1434e51-ead9-4b62-afec-eff4dd2055a3@f2g2000yqh.googlegroups.com> |
| In reply to | #5543 |
On Jun 6, 6:32 am, gordonb.jp...@burditt.org (Gordon Burditt) 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, frankly, i don't see any other way to implement one. But that may > > There's no reason you can't add a signed (possibly shorter) offset > to an unsigned number and get a reasonable unsigned result. Yes, > it might go out of range and trap, or go out of range and execute > garbage, or wrap around and trap, or wrap around and execute garbage. > The same problem is also likely to happen if you didn't install the > maximum amount of memory that you could install, and run off the > end. True. > Some machines that have relative branches have only relative branches > with short offsets (if you want to go a longer distance, use an > absolute branch, which likely takes a longer instruction, or perhaps > a longer relative branch, if there is one. x86 has relative branches > with 8 and 16-bit offsets, for example). How many bits are in the > offset tends to be a function of how many bits are left in the > instruction word without extending it, at instruction set design > time. So you might have a relative branch with a 13-bit offset on > a machine with a 32-bit address. True. > If the *only* branches are relative branches, then you need to be > able to branch from anywhere to anywhere, and traps on "overflow" > (signed or unsigned) are a problem. It is usually not that much > of a problem to ignore the "overflow" indication. (Note: if you > can add *positive* integers, you can ignore trapping overflow by > adding a bit at the high-order end of the adder, and hard-wire the > inputs as 0's, and ignore the output of that bit.) You could simply ignore the carry flag, but that's picking a nit. > Relative branches with short offsets tend to have signed offsets > because they are more useful that way than ones that only go forward > or only go backwards. Instruction set designers are aware of this. True. > Some machines have instructions that are multiples of and aligned to > something larger than bytes (e.g. 16 bits). On these machines, the > formula might be: > PC <-- PC + (2 * offset) > because the low-order bit of the offset is omitted (it's always 0) > and the low-order bit of the PC doesn't really exist (it's hardwired > to 0). That 13-bit offset might actually get squeezed into 12 bits. True, but that amounts to pretty much the same and still requires an addition (in addition to a right-shift) to do a relative jump. I've read your post with some interest, but i must admit your point has managed to escape me. Could you send in another with a less Houdini-like character?
[toc] | [prev] | [next] | [standalone]
| From | gordonb.5k8u2@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2011-06-06 05:18 -0500 |
| Message-ID | <T-qdnRWDr6LvNHHQnZ2dnUVZ_jGdnZ2d@posted.internetamerica> |
| In reply to | #5546 |
>> > 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 >> >> There's no reason you can't add a signed (possibly shorter) offset >> to an unsigned number and get a reasonable unsigned result. > I've read your post with some interest, but i must admit your point > has managed to escape me. Could you send in another with a less > Houdini-like character? The signedness of the offset in a relative branch instruction has no bearing on whether the PC is considered signed or unsigned. (However, I'll note that having NULL represented as all-bits-zero makes a pretty good case for an unsigned PC (there are *LOTS* of these machines), and having NULL represented the same as INT_MIN or LONG_MIN makes a pretty good case for a signed PC (I know of none of these). It doesn't really make sense for NULL to punch a hole in the "middle" of the memory space, with "middle" determined by the signedness of the PC).
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-06 08:16 -0700 |
| Message-ID | <c0dd75e1-8c20-4ca6-b31a-f212df6604fc@w10g2000yqh.googlegroups.com> |
| In reply to | #5555 |
On Jun 6, 12:18 pm, gordonb.5k...@burditt.org (Gordon Burditt) 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, frankly, i don't see any other way to implement one. But that may > > >> There's no reason you can't add a signed (possibly shorter) offset > >> to an unsigned number and get a reasonable unsigned result. > > I've read your post with some interest, but i must admit your point > > has managed to escape me. Could you send in another with a less > > Houdini-like character? > > The signedness of the offset in a relative branch instruction has > no bearing on whether the PC is considered signed or unsigned. Agreed. > (However, I'll note that having NULL represented as all-bits-zero > makes a pretty good case for an unsigned PC (there are *LOTS* of > these machines), and having NULL represented the same as INT_MIN > or LONG_MIN makes a pretty good case for a signed PC (I know of > none of these). It doesn't really make sense for NULL to punch a > hole in the "middle" of the memory space, with "middle" determined > by the signedness of the PC). Good point.
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-06-03 18:06 -0700 |
| Message-ID | <rubrum-6AE8B4.18060503062011@news.albasani.net> |
| In reply to | #5163 |
In article <307fb2d6-7e7f-475d-ae7d-ef4a8a121639@d1g2000yqm.googlegroups.com>, "Kleuskes & Moos" <kleuske@xs4all.nl> wrote: > How does a CPU add 1 and 1 and arrive at the (correct) answer: 2? That was a hard one. <http://en.wikipedia.org/wiki/Adder_(electronics)> > How do signed and unsigned versions of this operation differ? Twos complement: Unsigned versions look at the carry out of the high bit. Signed versions look at the carry into the high bit, and out of the high bit. If the xor of these two status bits is 1, then the result overflows the register. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | gordonb.zourz@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2011-06-05 21:25 -0500 |
| Message-ID | <SfSdnQi7MM4vp3HQnZ2dnUVZ_rmdnZ2d@posted.internetamerica> |
| In reply to | #5163 |
>> 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.
Virtual memory addresses may be represented with more complex
structure (e.g. permission bits, ring numbers, etc.) in which case
it's hard to tell what 'signed' or 'unsigned' even means as applied
to the address. For real examples of this, see [3456]86 32-bit
protected mode large model (48-bit pointers), although I'm not sure
how much those are actually used.
> 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?
It's actually pretty hard to set up a C-standard-compatible test
to see whether addresses are really signed or unsigned.
I propose this as a test: if you can allocate a struct or array
that straddles the signed boundary (0x7fff.../0x8000... for 2's
complement) and the address of the last element is > the address
of the first element, then addresses are *NOT* signed. If the
address of the last element is < the address of the first element,
the implementation is broken.
If you can allocate a struct or array that straddles the unsigned
boundary (0xffff.../0x0000... for 2's complement) and the address
of the last element is > the address of the first element, then
addresses are *NOT* unsigned. If the address of the last element
is < the address of the first element, the implementation is broken.
If the addresses are not signed *AND* not unsigned (you can allocate
structs or arrays that straddle both boundaries), the implementation
is broken.
Now, the problem is that many implementations, especially on the
large (e.g. an AMD 64 bit machine which has nowhere near a full
address space of memory actually populated) and tiny (e.g. TI
MSP430G2231, which has 128 bytes of RAM and 2k of program flash)
end of things, won't let you allocate structs or array that straddle
either boundary. This especially applies with physical addresses
to machines with less than a full address space of memory. So the
test result is inconclusive. I suspect a lot of 32-bit machines
fall in this category.
Does anyone have a simpler test, or a test that generates answers
on more machines, that's doesn't rely on undefined or
implementation-defined behavior?
A probably easier but non-C-standard-compliant way to tell whether
addresses are treated as signed or unsigned is to compile a function
like:
int addrcmp(char *a, char *b)
{
if (a > b)
return 1;
else
return -1;
}
and look at the generated code. On a 2's complement machine, you're
likely to see a compare instruction followed by a conditional branch.
(Lots but certainly not all machines use "condition flags", bits
which are set by math and compare operations and used by conditional
branches, both ancient and tiny (e.g. 8008) and modern and large)
branch on carry/no carry is an unsigned comparison. branch on
plus/minus is a signed comparison. If it's not a 2's complement
machine, it probably uses either a signed comparison or unsigned
comparison instruction.
The existence of relative-branch instructions with a short signed
offset added to a longer program counter register proves nothing
about the signedness of the program counter.
> 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.
>
> 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.
Structs and arrays have to have ascending addresses for their
members/elements. This plus the operation of the > and < operators
on pointers can make it more than a viewpoint issue.
> But, given the practicalities of hardware design, they are usually
> interpreted as being unsigned, simply because it's more convenient.
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-06 01:14 -0700 |
| Message-ID | <de1f894e-265b-4281-9d12-243f741c2d1f@x3g2000yqj.googlegroups.com> |
| In reply to | #5538 |
On Jun 6, 4:25 am, gordonb.zo...@burditt.org (Gordon Burditt) wrote:
> >> 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.
>
> Virtual memory addresses may be represented with more complex
> structure (e.g. permission bits, ring numbers, etc.) in which case
> it's hard to tell what 'signed' or 'unsigned' even means as applied
> to the address. For real examples of this, see [3456]86 32-bit
> protected mode large model (48-bit pointers), although I'm not sure
> how much those are actually used.
Quite extensively, since segments can be quite convenient in
compartimentalizing memory and making code relocatable. Also memory
protection schemes and paging can be based (as they are with Intel
IA32) on segments. On an Intel/AMD processor you have no choice, since
segment-based adresing cannot be switched off. But then again, with
Intel processors things tend to get _very_ complicated _very_ fast,
since they're quite complex beasts.
Still Intel (after all the segment and paging dust is settled),
reduces the 'logical address' to a 'linear address' with the help of a
segment descriptor table and views the physical address space as
unsigned
<quote Intel IA32 Manual Vol III, section 3.3 "Physical address space"
http://www.intel.com/Assets/PDF/manual/325384.pdf>
In protected mode, the IA-32 architecture provides a normal physical
address space
of 4 GBytes (2^32 bytes). This is the address space that the processor
can address on
its address bus. This address space is flat (unsegmented), with
addresses ranging
continuously from 0 to FFFFFFFFH.
</quote>
It's also worthwhile to note that this manual views 'byte', 'word',
'double-word', 'quad-word' and 'double-quad-words' as fundamental
datatypes and (explicitly) views numerical types as superimposed on
that. See Vol I, chapter 4, (http://www.intel.com/Assets/PDF/manual/
253665.pdf)
> > 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?
>
> It's actually pretty hard to set up a C-standard-compatible test
> to see whether addresses are really signed or unsigned.
I'd say it's damn near impossible, since the _actua_ adressing may be
hidden from view by the compilers implementations.
> I propose this as a test: if you can allocate a struct or array
> that straddles the signed boundary (0x7fff.../0x8000... for 2's
> complement) and the address of the last element is > the address
> of the first element, then addresses are *NOT* signed. If the
> address of the last element is < the address of the first element,
> the implementation is broken.
Hmmm... So you're saying either addresses are unsigned _or_ the
implementation is broken?
> If you can allocate a struct or array that straddles the unsigned
> boundary (0xffff.../0x0000... for 2's complement) and the address
> of the last element is > the address of the first element, then
> addresses are *NOT* unsigned. If the address of the last element
> is < the address of the first element, the implementation is broken.
>
> If the addresses are not signed *AND* not unsigned (you can allocate
> structs or arrays that straddle both boundaries), the implementation
> is broken.
>
> Now, the problem is that many implementations, especially on the
> large (e.g. an AMD 64 bit machine which has nowhere near a full
> address space of memory actually populated) and tiny (e.g. TI
> MSP430G2231, which has 128 bytes of RAM and 2k of program flash)
> end of things, won't let you allocate structs or array that straddle
> either boundary. This especially applies with physical addresses
> to machines with less than a full address space of memory. So the
> test result is inconclusive. I suspect a lot of 32-bit machines
> fall in this category.
>
> Does anyone have a simpler test, or a test that generates answers
> on more machines, that's doesn't rely on undefined or
> implementation-defined behavior?
Nope. Besides you're ignoring the fact that the compiler may clean up
the mess for you and translate 'signed' addresses to a corresponding
'unsigned' internal representation rendering all tests in 'C'
pointless. The CPU _and_ the compiler in this case are strictly
hypothetical, though.
> A probably easier but non-C-standard-compliant way to tell whether
> addresses are treated as signed or unsigned is to compile a function
> like:
> int addrcmp(char *a, char *b)
> {
> if (a > b)
> return 1;
> else
> return -1;}
>
> and look at the generated code. On a 2's complement machine, you're
> likely to see a compare instruction followed by a conditional branch.
> (Lots but certainly not all machines use "condition flags", bits
> which are set by math and compare operations and used by conditional
> branches, both ancient and tiny (e.g. 8008) and modern and large)
> branch on carry/no carry is an unsigned comparison. branch on
> plus/minus is a signed comparison. If it's not a 2's complement
> machine, it probably uses either a signed comparison or unsigned
> comparison instruction.
>
> The existence of relative-branch instructions with a short signed
> offset added to a longer program counter register proves nothing
> about the signedness of the program counter.
True. However, imagine what happens to segment boundaries (on an intel
processor) if you were to use a truly signed program counter. They
would no longer correspond to the addresses of the segment-base, but
extend below that address and things would become needlessly
complicated and error-prone.
> > 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.
>
> > 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.
>
> Structs and arrays have to have ascending addresses for their
> members/elements. This plus the operation of the > and < operators
> on pointers can make it more than a viewpoint issue.
Yes. But that's a compiler restraint and can be dealt with behind the
scenes at compile-time, for instance by mapping signed addresses to an
equivalent unsigned representation internally.
Nevertheless, unless i very much misunderstand your post (and please
tell me if i do), your argument amounts to saying "signed addresses
are just not practical".
> > But, given the practicalities of hardware design, they are usually
> > interpreted as being unsigned, simply because it's more convenient.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.donaz@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2011-06-06 04:36 -0500 |
| Message-ID | <IK6dnZkPrJoTAnHQnZ2dnUVZ_qOdnZ2d@posted.internetamerica> |
| In reply to | #5547 |
>> It's actually pretty hard to set up a C-standard-compatible test
>> to see whether addresses are really signed or unsigned.
>
> I'd say it's damn near impossible, since the _actua_ adressing may be
> hidden from view by the compilers implementations.
I'm referring here to the addresses that show up in pointers and
get compared with < and > operators. Those tests (probably on
virtual addresses) need to work correctly. If the compiler actually
goes to the trouble of translating virtual to physical addresses
and comparing those, fine, but that puts a lot of restriction on
remapping.
For example, the comparison of two pointers to the same object (done
by the compiler with physical addresses) is not allowed to change
during the run of the program. That means no reordering in physical
memory the pages containing parts of a single object. This is a
major pain for a virtual memory implementation. If the program
takes the address of something and hangs on to it, the virtual
memory system may not be allowed to load it anywhere in physical
memory besides where it was first loaded as long as the variable
containing that address (and any variables it was copied to) is
live.
>> I propose this as a test: if you can allocate a struct or array
>> that straddles the signed boundary (0x7fff.../0x8000... for 2's
>> complement) and the address of the last element is > the address
>> of the first element, then addresses are *NOT* signed. If the
>> address of the last element is < the address of the first element,
>> the implementation is broken.
>
> Hmmm... So you're saying either addresses are unsigned _or_ the
> implementation is broken?
No. Signed or Unsigned: *PICK ONE*, you can't have both. You
also can't have neither.
You can, however, set things up so it's impossible to rule out
either one. I'll claim that this is the case with most 32-bit
systems, and systems that have 50% or less of their maximum
memory actually installed.
If it's signed, you shouldn't be able to allocate an object that
straddles 0x7fff.../0x8000... . Incidentally, a good representation
for NULL with signed addresses is the bit pattern 0x8000... but it
still has to compare equal to the integer constant 0.
>> If you can allocate a struct or array that straddles the unsigned
>> boundary (0xffff.../0x0000... for 2's complement) and the address
>> of the last element is > the address of the first element, then
>> addresses are *NOT* unsigned. If the address of the last element
>> is < the address of the first element, the implementation is broken.
>>
>> If the addresses are not signed *AND* not unsigned (you can allocate
>> structs or arrays that straddle both boundaries), the implementation
>> is broken.
>>
>> Now, the problem is that many implementations, especially on the
>> large (e.g. an AMD 64 bit machine which has nowhere near a full
>> address space of memory actually populated) and tiny (e.g. TI
>> MSP430G2231, which has 128 bytes of RAM and 2k of program flash)
>> end of things, won't let you allocate structs or array that straddle
>> either boundary. This especially applies with physical addresses
>> to machines with less than a full address space of memory. So the
>> test result is inconclusive. I suspect a lot of 32-bit machines
>> fall in this category.
>>
>> Does anyone have a simpler test, or a test that generates answers
>> on more machines, that's doesn't rely on undefined or
>> implementation-defined behavior?
>
> Nope. Besides you're ignoring the fact that the compiler may clean up
> the mess for you and translate 'signed' addresses to a corresponding
> 'unsigned' internal representation rendering all tests in 'C'
> pointless. The CPU _and_ the compiler in this case are strictly
> hypothetical, though.
The operation of < and > on pointers needs to work correctly.
struct a {
int firstmember;
int secondmember;
}foo;
&foo.firstmember < &foo.secondmember had darn well better
be true, and it had better not change during the run of the program,
even if the struct gets split across pages, regardless of whether
the compiler is comparing virtual or physical addresses.
> True. However, imagine what happens to segment boundaries (on an intel
> processor) if you were to use a truly signed program counter. They
It's hard to imagine a "truly signed program counter" with segment
numbers in it. Are the segment numbers what is signed? Signed program
counter doesn't have to imply (nor forbid) that the *offset* is signed.
> would no longer correspond to the addresses of the segment-base, but
> extend below that address and things would become needlessly
> complicated and error-prone.
> Yes. But that's a compiler restraint and can be dealt with behind the
> scenes at compile-time, for instance by mapping signed addresses to an
> equivalent unsigned representation internally.
Using physical addresses (signed or unsigned) for comparison can
really kill your virtual memory performance.
> Nevertheless, unless i very much misunderstand your post (and please
> tell me if i do), your argument amounts to saying "signed addresses
> are just not practical".
No, my argument is that on many machines, you simply CANNOT TELL
whether the addresses are signed or not (and therefore caring or
worrying about it is not worthwhile), because you cannot get (virtual)
pointers to feed to the < or > operators of appropriate values to
even do the test. Often the reasons are things like "you don't
have that much memory (or swap space) installed", or "half the
address space is reserved for the kernel".
Incidentally, I think my first run-in with unsigned pointers involved
the loop:
struct reallybig table[MAX];
struct reallybig *p;
for (p = &table[MAX]; p >= &table[0]; p--) {
... do something with p ...;
}
and &table (data segment started at 0) turned out to be less than
sizeof(table). Gee, why does this loop never terminate?
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-06 09:02 -0700 |
| Message-ID | <57fb0d2e-3648-4cce-82cf-e10abf2944d4@d1g2000yqm.googlegroups.com> |
| In reply to | #5554 |
On Jun 6, 11:36 am, gordonb.do...@burditt.org (Gordon Burditt) wrote:
> >> It's actually pretty hard to set up a C-standard-compatible test
> >> to see whether addresses are really signed or unsigned.
>
> > I'd say it's damn near impossible, since the _actua_ adressing may be
> > hidden from view by the compilers implementations.
>
> I'm referring here to the addresses that show up in pointers and
> get compared with < and > operators. Those tests (probably on
> virtual addresses) need to work correctly. If the compiler actually
> goes to the trouble of translating virtual to physical addresses
> and comparing those, fine, but that puts a lot of restriction on
> remapping.
If addresses are translated from what you refer to as 'virtual', the
comparison needs to be done for _untranslated_ versions, and in
practice, i think they are.
> For example, the comparison of two pointers to the same object (done
> by the compiler with physical addresses) is not allowed to change
> during the run of the program. That means no reordering in physical
> memory the pages containing parts of a single object. This is a
> major pain for a virtual memory implementation. If the program
> takes the address of something and hangs on to it, the virtual
> memory system may not be allowed to load it anywhere in physical
> memory besides where it was first loaded as long as the variable
> containing that address (and any variables it was copied to) is
> live.
Yes. But only if you compare _physical_ addresses, which, in practice,
you would not do, since the only requirement is that the pointers as
seen from 'C', that is the _virtual_ ones, behave nicely. What happens
at the physical level is unimportant from a 'C' point of view.
For instance, if you are running your software on a x86, the addresses
as seen/generated by your compiler are 'logical adresses' (Intel
terminology), which get translated by the CPU to physical addresses
behind the scenes, but this is completely transparent to the 'C'
program and does not need to be taken into account.
> >> I propose this as a test: if you can allocate a struct or array
> >> that straddles the signed boundary (0x7fff.../0x8000... for 2's
> >> complement) and the address of the last element is > the address
> >> of the first element, then addresses are *NOT* signed. If the
> >> address of the last element is < the address of the first element,
> >> the implementation is broken.
>
> > Hmmm... So you're saying either addresses are unsigned _or_ the
> > implementation is broken?
>
> No. Signed or Unsigned: *PICK ONE*, you can't have both. You
> also can't have neither.
Hmmm... Not so long ago, you argued
<quote>
Virtual memory addresses may be represented with more complex
structure (e.g. permission bits, ring numbers, etc.) in which case
it's hard to tell what 'signed' or 'unsigned' even means as applied
to the address.
</quote>
Which i think was a pretty good point. Whence the change?
> You can, however, set things up so it's impossible to rule out
> either one. I'll claim that this is the case with most 32-bit
> systems, and systems that have 50% or less of their maximum
> memory actually installed.
In those cases it makes no difference, agreed. I don't comment on
wether of not your claim is true.
> If it's signed, you shouldn't be able to allocate an object that
> straddles 0x7fff.../0x8000... . Incidentally, a good representation
> for NULL with signed addresses is the bit pattern 0x8000... but it
> still has to compare equal to the integer constant 0.
<quote>
(However, I'll note that having NULL represented as all-bits-zero
makes a pretty good case for an unsigned PC (there are *LOTS* of
these machines), and having NULL represented the same as INT_MIN
or LONG_MIN makes a pretty good case for a signed PC (I know of
none of these). It doesn't really make sense for NULL to punch a
hole in the "middle" of the memory space, with "middle" determined
by the signedness of the PC).
</quote>
The above just seemed to fit here quite well.
<snip>
> > Nope. Besides you're ignoring the fact that the compiler may clean up
> > the mess for you and translate 'signed' addresses to a corresponding
> > 'unsigned' internal representation rendering all tests in 'C'
> > pointless. The CPU _and_ the compiler in this case are strictly
> > hypothetical, though.
>
> The operation of < and > on pointers needs to work correctly.
> struct a {
> int firstmember;
> int secondmember;
>
> }foo;
>
> &foo.firstmember < &foo.secondmember had darn well better
> be true, and it had better not change during the run of the program,
> even if the struct gets split across pages, regardless of whether
> the compiler is comparing virtual or physical addresses.
That's not _that_ hard to arrange, but again, it _only_ needs to be
valid for _logical_ addresses (Intel jargon, i think it corresponds,
loosely, to your 'virtual addresses', but i'm not quite sure), not
_physical_ ones.
> > True. However, imagine what happens to segment boundaries (on an intel
> > processor) if you were to use a truly signed program counter. They
>
> It's hard to imagine a "truly signed program counter" with segment
> numbers in it. Are the segment numbers what is signed? Signed program
> counter doesn't have to imply (nor forbid) that the *offset* is signed.
Ummm... Not quite sure what you mean with "a PC with segment numbers
in it" but i was referring to signed offsets.
> > would no longer correspond to the addresses of the segment-base, but
> > extend below that address and things would become needlessly
> > complicated and error-prone.
> > Yes. But that's a compiler restraint and can be dealt with behind the
> > scenes at compile-time, for instance by mapping signed addresses to an
> > equivalent unsigned representation internally.
>
> Using physical addresses (signed or unsigned) for comparison can
> really kill your virtual memory performance.
Using physical addresses (signed or unsigned) for comparison is
stoopid and no CPU and/or Compiler manufacturer would dream of doing
that.
> > Nevertheless, unless i very much misunderstand your post (and please
> > tell me if i do), your argument amounts to saying "signed addresses
> > are just not practical".
>
> No, my argument is that on many machines, you simply CANNOT TELL
> whether the addresses are signed or not (and therefore caring or
> worrying about it is not worthwhile), because you cannot get (virtual)
> pointers to feed to the < or > operators of appropriate values to
> even do the test.
And it's a good point, too.
> Often the reasons are things like "you don't
> have that much memory (or swap space) installed", or "half the
> address space is reserved for the kernel".
>
> Incidentally, I think my first run-in with unsigned pointers involved
> the loop:
> struct reallybig table[MAX];
> struct reallybig *p;
>
> for (p = &table[MAX]; p >= &table[0]; p--) {
> ... do something with p ...;
> }
>
> and &table (data segment started at 0) turned out to be less than
> sizeof(table). Gee, why does this loop never terminate?
:)
[toc] | [prev] | [next] | [standalone]
| From | gordonb.k6ruq@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2011-06-06 18:36 -0500 |
| Message-ID | <df6dnWBM9okS-XDQnZ2dnUVZ_tSdnZ2d@posted.internetamerica> |
| In reply to | #5568 |
>> >> It's actually pretty hard to set up a C-standard-compatible test
>> >> to see whether addresses are really signed or unsigned.
>>
>> > I'd say it's damn near impossible, since the _actua_ adressing may be
>> > hidden from view by the compilers implementations.
>>
>> I'm referring here to the addresses that show up in pointers and
>> get compared with < and > operators. Those tests (probably on
>> virtual addresses) need to work correctly. If the compiler actually
>> goes to the trouble of translating virtual to physical addresses
>> and comparing those, fine, but that puts a lot of restriction on
>> remapping.
>
> If addresses are translated from what you refer to as 'virtual', the
> comparison needs to be done for _untranslated_ versions, and in
> practice, i think they are.
I don't think it *has* to be done for untranslated versions. Doing
it for translated versions, however, may be equivalent to shooting
yourself in the foot in many situations, much like an implementation
where any undefined behavior launches missiles. There are a few
where it might not.
An example here: in x86 real-mode 16-bit huge model, pointers are
represented as abcd:efgh and point at physical address 16*(abcd) +
efgh. (This is a fixed translation with no "map" subject to getting
changed at runtime, but it is a translation). There are many
possible representations that point at the same place. In some of
the memory models (e.g. large), you can't get these different
representations because all objects are smaller than 64k and you
can't have carries into the segment register from pointer arithmetic
unless you've invoked undefined behavior. In huge model this isn't
the case (objects are allowed to be > 64k), and you need to "normalize"
a pointer to ijkl:000h or i000:jklh before comparing pointers.
Here, you're comparing physical addresses, not the untranslated
ones.
>> For example, the comparison of two pointers to the same object (done
>> by the compiler with physical addresses) is not allowed to change
>> during the run of the program. That means no reordering in physical
>> memory the pages containing parts of a single object. This is a
>> major pain for a virtual memory implementation. If the program
>> takes the address of something and hangs on to it, the virtual
>> memory system may not be allowed to load it anywhere in physical
>> memory besides where it was first loaded as long as the variable
>> containing that address (and any variables it was copied to) is
>> live.
>
> Yes. But only if you compare _physical_ addresses, which, in practice,
> you would not do, since the only requirement is that the pointers as
> seen from 'C', that is the _virtual_ ones, behave nicely. What happens
> at the physical level is unimportant from a 'C' point of view.
It has to work right one way or another, and if you are doing full
virtual memory with page-in/page-out, you wouldn't select comparing
physical addresses. In other (rare) situations, like the x86 16-bit
real-mode huge model with no swapping/paging, you would, because
the virtual ones don't behave nicely..
> For instance, if you are running your software on a x86, the addresses
> as seen/generated by your compiler are 'logical adresses' (Intel
> terminology), which get translated by the CPU to physical addresses
> behind the scenes, but this is completely transparent to the 'C'
> program and does not need to be taken into account.
In x86 16-bit huge model (which allows objects > 64k), the translation
is not fully transparent, since you can have lots of different bit
patterns that point to the same place and these can be derived from
normal pointer arithmetic, and pointer equality has to work correctly.
>> >> I propose this as a test: if you can allocate a struct or array
>> >> that straddles the signed boundary (0x7fff.../0x8000... for 2's
>> >> complement) and the address of the last element is > the address
>> >> of the first element, then addresses are *NOT* signed. If the
>> >> address of the last element is < the address of the first element,
>> >> the implementation is broken.
>>
>> > Hmmm... So you're saying either addresses are unsigned _or_ the
>> > implementation is broken?
>>
>> No. Signed or Unsigned: *PICK ONE*, you can't have both. You
>> also can't have neither.
>
> Hmmm... Not so long ago, you argued
>
> <quote>
> Virtual memory addresses may be represented with more complex
> structure (e.g. permission bits, ring numbers, etc.) in which case
> it's hard to tell what 'signed' or 'unsigned' even means as applied
> to the address.
> </quote>
>
> Which i think was a pretty good point. Whence the change?
Unfortunately, you have to implement pointer comparisons with > and <,
so either you pick one, or you disallow allocating objects that straddle
either boundary so you can't tell.
>> You can, however, set things up so it's impossible to rule out
>> either one. I'll claim that this is the case with most 32-bit
>> systems, and systems that have 50% or less of their maximum
>> memory actually installed.
>
> In those cases it makes no difference, agreed. I don't comment on
> wether of not your claim is true.
>
>> If it's signed, you shouldn't be able to allocate an object that
>> straddles 0x7fff.../0x8000... . Incidentally, a good representation
>> for NULL with signed addresses is the bit pattern 0x8000... but it
>> still has to compare equal to the integer constant 0.
>
> <quote>
> (However, I'll note that having NULL represented as all-bits-zero
> makes a pretty good case for an unsigned PC (there are *LOTS* of
> these machines), and having NULL represented the same as INT_MIN
> or LONG_MIN makes a pretty good case for a signed PC (I know of
> none of these). It doesn't really make sense for NULL to punch a
> hole in the "middle" of the memory space, with "middle" determined
> by the signedness of the PC).
> </quote>
>
> The above just seemed to fit here quite well.
>
> <snip>
>
>> > Nope. Besides you're ignoring the fact that the compiler may clean up
>> > the mess for you and translate 'signed' addresses to a corresponding
>> > 'unsigned' internal representation rendering all tests in 'C'
>> > pointless. The CPU _and_ the compiler in this case are strictly
>> > hypothetical, though.
Comparing translated addresses puts a lot of restrictions on the
translation, pretty much killing any possibility of modern virtual
memory implementation.
>> The operation of < and > on pointers needs to work correctly.
>> struct a {
>> int firstmember;
>> int secondmember;
>>
>> }foo;
>>
>> foo.firstmember < &foo.secondmember had darn well better
>> be true, and it had better not change during the run of the program,
>> even if the struct gets split across pages, regardless of whether
>> the compiler is comparing virtual or physical addresses.
>
> That's not _that_ hard to arrange, but again, it _only_ needs to be
> valid for _logical_ addresses (Intel jargon, i think it corresponds,
> loosely, to your 'virtual addresses', but i'm not quite sure), not
> _physical_ ones.
I use the term virtual address for what C handles (and what
printf("%p", p) shows you) and physical address for the translated
address the hardware actually uses. Nothing rules out the possibility
that the physical and virtual addresses are the same (no translation
or identity translation).
Making it only valid for "logical" (virtual) addresses rules out the
possibility that:
>> > Nope. Besides you're ignoring the fact that the compiler may clean up
>> > the mess for you and translate 'signed' addresses to a corresponding
>> > 'unsigned' internal representation rendering all tests in 'C'
>> > pointless.
Untranslated translated addresses don't exist.
>> > True. However, imagine what happens to segment boundaries (on an intel
>> > processor) if you were to use a truly signed program counter. They
>>
>> It's hard to imagine a "truly signed program counter" with segment
>> numbers in it. Are the segment numbers what is signed? Signed program
>> counter doesn't have to imply (nor forbid) that the *offset* is signed.
>
> Ummm... Not quite sure what you mean with "a PC with segment numbers
> in it" but i was referring to signed offsets.
I am referring to a PC that *contains* an offset but it is not an
offset alone. Consider x86 32-bit mode large-model segmented
pointers (48 bits wide). It contains an offset (32 bits), segment
number, ring number, and global/local bit. The "program counter",
regardless of Intel terminology, includes the CS register in large
model since that is an essential part of determining where the
program executes, and the CS part changes arbitrarily often. Function
and object pointers also include a segment portion.
>> > would no longer correspond to the addresses of the segment-base, but
>> > extend below that address and things would become needlessly
>> > complicated and error-prone.
>> > Yes. But that's a compiler restraint and can be dealt with behind the
>> > scenes at compile-time, for instance by mapping signed addresses to an
>> > equivalent unsigned representation internally.
Doing that mapping if you're comparing *unmapped* virtual addresses
has no effect.
>> Using physical addresses (signed or unsigned) for comparison can
>> really kill your virtual memory performance.
>
> Using physical addresses (signed or unsigned) for comparison is
> stoopid and no CPU and/or Compiler manufacturer would dream of doing
> that.
huge-model x86 16-bit real mode does exactly that. Of course, MSDOS
didn't have virtual memory or swapping, and "normalizing" pointers is
fairly cheap. And if you didn't need objects > 64k, use large model.
>> > Nevertheless, unless i very much misunderstand your post (and please
>> > tell me if i do), your argument amounts to saying "signed addresses
>> > are just not practical".
>>
>> No, my argument is that on many machines, you simply CANNOT TELL
>> whether the addresses are signed or not (and therefore caring or
>> worrying about it is not worthwhile), because you cannot get (virtual)
>> pointers to feed to the < or > operators of appropriate values to
>> even do the test.
>
> And it's a good point, too.
>
>> Often the reasons are things like "you don't
>> have that much memory (or swap space) installed", or "half the
>> address space is reserved for the kernel".
>>
>> Incidentally, I think my first run-in with unsigned pointers involved
>> the loop:
>> struct reallybig table[MAX];
>> struct reallybig *p;
>>
>> for (p = &table[MAX]; p >= &table[0]; p--) {
>> ... do something with p ...;
>> }
>>
>> and &table (data segment started at 0) turned out to be less than
>> sizeof(table). Gee, why does this loop never terminate?
>
> :)
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-06-07 10:14 -0700 |
| Message-ID | <6b6ad44b-5841-429c-bb9c-866af0d64e6a@g12g2000yqd.googlegroups.com> |
| In reply to | #5591 |
On Jun 7, 1:36 am, gordonb.k6...@burditt.org (Gordon Burditt) wrote: > >> >> It's actually pretty hard to set up a C-standard-compatible test > >> >> to see whether addresses are really signed or unsigned. > > >> > I'd say it's damn near impossible, since the _actua_ adressing may be > >> > hidden from view by the compilers implementations. > > >> I'm referring here to the addresses that show up in pointers and > >> get compared with < and > operators. Those tests (probably on > >> virtual addresses) need to work correctly. If the compiler actually > >> goes to the trouble of translating virtual to physical addresses > >> and comparing those, fine, but that puts a lot of restriction on > >> remapping. > > > If addresses are translated from what you refer to as 'virtual', the > > comparison needs to be done for _untranslated_ versions, and in > > practice, i think they are. > > I don't think it *has* to be done for untranslated versions. Doing > it for translated versions, however, may be equivalent to shooting > yourself in the foot in many situations, much like an implementation > where any undefined behavior launches missiles. There are a few > where it might not. > > An example here: in x86 real-mode 16-bit huge model, pointers are > represented as abcd:efgh and point at physical address 16*(abcd) + > efgh. (This is a fixed translation with no "map" subject to getting > changed at runtime, but it is a translation). There are many > possible representations that point at the same place. In some of > the memory models (e.g. large), you can't get these different > representations because all objects are smaller than 64k and you > can't have carries into the segment register from pointer arithmetic > unless you've invoked undefined behavior. In huge model this isn't > the case (objects are allowed to be > 64k), and you need to "normalize" > a pointer to ijkl:000h or i000:jklh before comparing pointers. > Here, you're comparing physical addresses, not the untranslated > ones. Ok. Two bits of well intended advice: a) Do not use Borland products b) Don't do that. and an observation: 'An abstract program language which obliges you to worry about the contents of registers is not worth using' <snip> > > Yes. But only if you compare _physical_ addresses, which, in practice, > > you would not do, since the only requirement is that the pointers as > > seen from 'C', that is the _virtual_ ones, behave nicely. What happens > > at the physical level is unimportant from a 'C' point of view. > > It has to work right one way or another, and if you are doing full > virtual memory with page-in/page-out, you wouldn't select comparing > physical addresses. In other (rare) situations, like the x86 16-bit > real-mode huge model with no swapping/paging, you would, because > the virtual ones don't behave nicely. Ummm.... That would be an excellent reason not to use such platforms, or reduce the size of your objects, since they are obviously not supported. <snip> <snip> > >> It's hard to imagine a "truly signed program counter" with segment > >> numbers in it. Are the segment numbers what is signed? Signed program > >> counter doesn't have to imply (nor forbid) that the *offset* is signed. > > > Ummm... Not quite sure what you mean with "a PC with segment numbers > > in it" but i was referring to signed offsets. > > I am referring to a PC that *contains* an offset but it is not an > offset alone. Consider x86 32-bit mode large-model segmented > pointers (48 bits wide). Ummm... The PC (Program Counter) a.k.a. EIP on Intel-land is a register and contains a 32-bit value. RTFM, if you don't believe me. <quote src="http://www.intel.com/products/processor/manuals/, Vol 1, section 3.5, misleadingly called 'instruction pointer'"> The instruction pointer (EIP) register contains the offset in the current code segment for the next instruction to be executed. </quote> > It contains an offset (32 bits), segment > number, ring number, and global/local bit. > The "program counter", > regardless of Intel terminology, includes the CS register in large > model since that is an essential part of determining where the > program executes, and the CS part changes arbitrarily often. Function > and object pointers also include a segment portion. Ah... What Intel has to say on the matter is of no consequence in the light of your wisdom. I see. This explains rather a lot. Sorry. I've had it with 'models'. If you want to discuss TurboC, i'm sure there's a venue for that.
[toc] | [prev] | [next] | [standalone]
| From | "J. J. Farrell" <jjf@bcs.org.uk> |
|---|---|
| Date | 2011-05-31 19:56 +0100 |
| Message-ID | <is3dkr$5bk$1@dont-email.me> |
| In reply to | #5112 |
Kleuskes & Moos wrote: > ... > 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. Why on earth should he? Who ever claimed such an environment exists, or isn't silly? It's legal in C for such an environment to exist, that's all. If someone is choosing to write code which is portable to all possible legal C implementations, they have to allow for it. If they only need to make their code portable to all environments which there is the slightest predictable possibility of ever coming across, they can ignore it.
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2011-06-01 14:54 +0200 |
| Message-ID | <is5cqr$lfm$1@speranza.aioe.org> |
| In reply to | #5138 |
J. J. Farrell wrote: > Kleuskes & Moos wrote: >> ... >> 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. > > Why on earth should he? Who ever claimed such an environment exists, or > isn't silly? It's legal in C for such an environment to exist, that's > all. If someone is choosing to write code which is portable to all > possible legal C implementations, they have to allow for it. If they > only need to make their code portable to all environments which there is > the slightest predictable possibility of ever coming across, they can > ignore it. Would this work (I'm uncertain about pre-processor arithmetic type promotion) #if UINT_MAX <= INT_MAX #error UNSUPPORTED PLATFORM !!! #endif
[toc] | [prev] | [next] | [standalone]
| From | Angel <angel+news@spamcop.net> |
|---|---|
| Date | 2011-06-01 13:07 +0000 |
| Message-ID | <slrniucebk.nno.angel+news@pearlgates.net> |
| In reply to | #5176 |
On 2011-06-01, Noob <root@127.0.0.1> wrote: > > Would this work (I'm uncertain about pre-processor arithmetic type promotion) > > #if UINT_MAX <= INT_MAX > #error UNSUPPORTED PLATFORM !!! > #endif Assuming that you include limits.h before this test, I don't see any reason why this shouldn't work. -- "C provides a programmer with more than enough rope to hang himself. C++ provides a firing squad, blindfold and last cigarette." - seen in comp.lang.c
[toc] | [prev] | [next] | [standalone]
| From | pete <pfiland@mindspring.com> |
|---|---|
| Date | 2011-06-01 14:10 -0400 |
| Message-ID | <4DE68098.44E1@mindspring.com> |
| In reply to | #5176 |
Noob wrote: > > J. J. Farrell wrote: > > If someone is choosing to write code which is portable to all > > possible legal C implementations, they have to allow for it. > Would this work > (I'm uncertain about pre-processor arithmetic type promotion) > > #if UINT_MAX <= INT_MAX > #error UNSUPPORTED PLATFORM !!! > #endif You could change that to #if UINT_MAX == INT_MAX If (UINT_MAX < INT_MAX) is true, then it's not C. -- pete
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-06-01 19:58 -0400 |
| Message-ID | <is6jn5$dcu$1@dont-email.me> |
| In reply to | #5218 |
On 06/01/2011 02:10 PM, pete wrote: > Noob wrote: ... >> Would this work >> (I'm uncertain about pre-processor arithmetic type promotion) >> >> #if UINT_MAX <= INT_MAX >> #error UNSUPPORTED PLATFORM !!! >> #endif > > You could change that to > > #if UINT_MAX == INT_MAX > > If (UINT_MAX < INT_MAX) is true, then it's not C. Which would also make it an unsupported platform, would it not? -- James Kuyper
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web