Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #17117 > unrolled thread

return -1 using size_t???

Back to article view | Back to comp.lang.c

Contents

  return -1 using size_t??? Robert Hayes <rhyes80@gmail.com> - 2012-02-11 11:21 -0800
    Re: return -1 using size_t??? Shao Miller <sha0.miller@gmail.com> - 2012-02-11 15:00 -0500
      Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-11 23:24 +0000
    Re: return -1 using size_t??? Jeffrey R <joeff@nospam.com> - 2012-02-11 19:58 +0000
      Re: return -1 using size_t??? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-11 15:11 -0500
    Re: return -1 using size_t??? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-11 15:07 -0500
      Re: return -1 using size_t??? Robert Hayes <rhyes80@gmail.com> - 2012-02-11 12:42 -0800
        Re: return -1 using size_t??? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-11 13:19 -0800
          Re: return -1 using size_t??? Keith Thompson <kst-u@mib.org> - 2012-02-11 17:10 -0800
            Re: return -1 using size_t??? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-12 03:48 -0800
              Re: return -1 using size_t??? Keith Thompson <kst-u@mib.org> - 2012-02-12 04:04 -0800
        Re: return -1 using size_t??? Jeffrey R <joeff@nospam.com> - 2012-02-11 22:25 +0000
          Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-11 14:36 -0800
            Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-11 23:17 +0000
          Re: return -1 using size_t??? Jeroen Mostert <jmostert@xs4all.nl> - 2012-02-11 23:46 +0100
            Re: return -1 using size_t??? pete <pfiland@mindspring.com> - 2012-02-11 19:18 -0500
          Re: return -1 using size_t??? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-12 08:38 -0500
        Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-11 23:32 +0000
        Re: return -1 using size_t??? pete <pfiland@mindspring.com> - 2012-02-11 19:15 -0500
      Re: return -1 using size_t??? Ralph Spitzner <rasp@spitzner.org> - 2012-02-13 13:51 +0100
    Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-11 12:40 -0800
      Re: return -1 using size_t??? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-11 17:02 -0500
        Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-11 14:11 -0800
          Re: return -1 using size_t??? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-11 17:21 -0500
            Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-11 14:31 -0800
              Re: return -1 using size_t??? Willem <willem@toad.stack.nl> - 2012-02-11 22:52 +0000
              Re: return -1 using size_t??? Jens Gustedt <jens.gustedt@loria.fr> - 2012-02-12 00:20 +0100
                Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-12 09:21 -0800
                  Re: return -1 using size_t??? Keith Thompson <kst-u@mib.org> - 2012-02-12 12:27 -0800
                    Re: return -1 using size_t??? Jeroen Mostert <jmostert@xs4all.nl> - 2012-02-12 22:17 +0100
                      Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-12 15:10 -0800
                        Re: return -1 using size_t??? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-13 03:11 -0800
                    Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-12 23:25 +0000
                      Re: return -1 using size_t??? Jeroen Mostert <jmostert@xs4all.nl> - 2012-02-13 07:46 +0100
                      Re: return -1 using size_t??? Ike Naar <ike@sverige.freeshell.org> - 2012-02-13 10:27 +0000
                        Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-13 12:36 +0000
                          Re: return -1 using size_t??? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-02-13 10:26 -0700
                          Re: return -1 using size_t??? Ike Naar <ike@iceland.freeshell.org> - 2012-02-14 00:18 +0000
                            Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-14 00:29 +0000
                            Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-13 16:37 -0800
                      Re: return -1 using size_t??? Angel <angel+news@spamcop.net> - 2012-02-13 11:47 +0000
                        Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-13 12:54 +0000
                          Re: return -1 using size_t??? Angel <angel+news@spamcop.net> - 2012-02-13 14:30 +0000
                            Re: return -1 using size_t??? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 01:53 +0200
                          Re: return -1 using size_t??? James Kuyper <jameskuyper@verizon.net> - 2012-02-13 12:11 -0500
                            Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-13 17:28 +0000
                              Re: return -1 using size_t??? James Kuyper <jameskuyper@verizon.net> - 2012-02-13 13:08 -0500
                                Re: return -1 using size_t??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-13 23:06 +0000
                          Re: return -1 using size_t??? William Ahern <william@wilbur.25thandClement.com> - 2012-02-13 14:39 -0800
                            Re: return -1 using size_t??? Keith Thompson <kst-u@mib.org> - 2012-02-13 14:59 -0800
                  Re: return -1 using size_t??? Jens Gustedt <jens.gustedt@loria.fr> - 2012-02-12 22:17 +0100
                    Re: return -1 using size_t??? Devil with the China Blue Dress <chine.bleu@yahoo.com> - 2012-02-12 15:06 -0800
                      Re: return -1 using size_t??? Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-12 18:12 -0500
                      Re: return -1 using size_t??? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 02:15 +0200
    Re: return -1 using size_t??? Barry Schwarz <schwarzb@dqel.com> - 2012-02-11 14:27 -0800
      Re: return -1 using size_t??? Keith Thompson <kst-u@mib.org> - 2012-02-11 17:34 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#17125

In article <8c1eef8c-2ba4-441e-aa86-36486b56a261@n12g2000yqb.googlegroups.com>,
 Robert Hayes <rhyes80@gmail.com> wrote:

> While I realize using an unsigned int to store a negative number is
> not proper, why does it sort of work?  By sort of work I mean the

On a twos complement CPU, an n-bit integer can be regarded as the nonnegative 
numbers 0..(2^n)-1 or negative and nonnegative numbers -(2^(n-1))..(2^(n-1))-1. 
Addition and subtraction will yield the same bit patterns with either 
interpretation. If the most significant bits are equal, comparison will be the 
same. This doesn't work for multiplication and division and shifting; it also 
doesn't work for ones complement.

For example if n=2

    +   00  01  10  11      +   0   1   -2  -1      +   0   1   2   3
    00  00  01  10  11      0   0   1   -2  -1      0   0   1   2   3
    01  01  10  11  00      1   1   2   -1  0       1   1   2   3   0*
    10  10  11  00  01      -2  -2  -1  0*  1*      2   2   3   0*  1*
    11  11  00  01  10      -1  -1  0   1*  -2      3   3   0*  1*  2*

* overflow

-- 
My name Indigo Montoya.      |         It's Coraline, not Caroline.
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#17135

On 2/11/2012 3:40 PM, Devil with the China Blue Dress wrote:
> In article<8c1eef8c-2ba4-441e-aa86-36486b56a261@n12g2000yqb.googlegroups.com>,
>   Robert Hayes<rhyes80@gmail.com>  wrote:
>
>> While I realize using an unsigned int to store a negative number is
>> not proper, why does it sort of work?  By sort of work I mean the
>
> On a twos complement CPU, [...]

     On no C implementation anywhere does size_t use two's complement.
Nor ones' complement, nor signed magnitude.

> Addition and subtraction will yield the same bit patterns with either
> interpretation. If the most significant bits are equal, comparison will be the
> same.

     C's comparison and equality operators use values, not bit patterns.
Here's (slightly non-portable) proof:

	#include <string.h>
	#include <math.h>
	#include <assert.h>
	...
	float f = NAN;
	float g = NAN;
	assert(memcmp(&f, &g, sizeof f) == 0);  // identical bits
	assert(f != g);                         // unequal values

Here's another proof (I think this one's portable):

	struct {
	    unsigned int p : 1;
	    unsigned int q : 15;
	} s;
	s.p = 1;
	s.q = 1;
	assert(s.p == s.q);  // different bits, equal values

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#17137

In article <jh6oh8$i77$1@dont-email.me>,
 Eric Sosman <esosman@ieee-dot-org.invalid> wrote:

> On 2/11/2012 3:40 PM, Devil with the China Blue Dress wrote:
> > In 
> > article<8c1eef8c-2ba4-441e-aa86-36486b56a261@n12g2000yqb.googlegroups.com>,
> >   Robert Hayes<rhyes80@gmail.com>  wrote:
> >
> >> While I realize using an unsigned int to store a negative number is
> >> not proper, why does it sort of work?  By sort of work I mean the
> >
> > On a twos complement CPU, [...]

And you snipped that all references were to integers

> 	float f = NAN;

to bring up real numbers.


> Here's another proof (I think this one's portable):
> 
> 	struct {
> 	    unsigned int p : 1;
> 	    unsigned int q : 15;
> 	} s;
> 	s.p = 1;
> 	s.q = 1;
> 	assert(s.p == s.q);  // different bits, equal values

The bit pattern of s.p would be 0...1 and s.q would be 0...000000000000001 
widenned to the number of bits in an unsigned int.

-- 
My name Indigo Montoya.      |         It's Coraline, not Caroline.
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#17139

On 2/11/2012 5:11 PM, Devil with the China Blue Dress wrote:
> In article<jh6oh8$i77$1@dont-email.me>,
>   Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
>
>> On 2/11/2012 3:40 PM, Devil with the China Blue Dress wrote:
>>> In
>>> article<8c1eef8c-2ba4-441e-aa86-36486b56a261@n12g2000yqb.googlegroups.com>,
>>>    Robert Hayes<rhyes80@gmail.com>   wrote:
>>>
>>>> While I realize using an unsigned int to store a negative number is
>>>> not proper, why does it sort of work?  By sort of work I mean the
>>>
>>> On a twos complement CPU, [...]
>
> And you snipped that all references were to integers

     The question was about *unsigned* integers.  *Unsigned* integers
in C never use complement represention.

>> Here's another proof (I think this one's portable):
>>
>> 	struct {
>> 	    unsigned int p : 1;
>> 	    unsigned int q : 15;
>> 	} s;
>> 	s.p = 1;
>> 	s.q = 1;
>> 	assert(s.p == s.q);  // different bits, equal values
>
> The bit pattern of s.p would be 0...1 and s.q would be 0...000000000000001
> widenned to the number of bits in an unsigned int.

     The bit pattern of s.p is `1', period.  The bit pattern of
s.q is `000000000000001', period.  These bit patterns necessarily
disagree, since they're not even the same size.

     I've made two points about your post: First, talking about
representation schemes for negative numbers is silly when the
type in question is unsigned.  Second, suggesting that comparison
relies on bit patterns without regard to types is not merely
silly, but wrong.  (I could also have taken issue with the
misstatement about "most significant bits," but enough's enough.)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#17143

In article <jh6pkt$ob8$1@dont-email.me>,
 Eric Sosman <esosman@ieee-dot-org.invalid> wrote:

> On 2/11/2012 5:11 PM, Devil with the China Blue Dress wrote:
> > In article<jh6oh8$i77$1@dont-email.me>,
> >   Eric Sosman<esosman@ieee-dot-org.invalid>  wrote:
> >
> >> On 2/11/2012 3:40 PM, Devil with the China Blue Dress wrote:
> >>> In
> >>> article<8c1eef8c-2ba4-441e-aa86-36486b56a261@n12g2000yqb.googlegroups.com>
> >>> ,
> >>>    Robert Hayes<rhyes80@gmail.com>   wrote:
> >>>
> >>>> While I realize using an unsigned int to store a negative number is
> >>>> not proper, why does it sort of work?  By sort of work I mean the
> >>>
> >>> On a twos complement CPU, [...]
> >
> > And you snipped that all references were to integers
> 
>      The question was about *unsigned* integers.  *Unsigned* integers
> in C never use complement represention.

No, the question was about casting an signed number (-1) to an unsigned type. 
That this can be done and is closed under addition is a property of twos 
complement integers.

> >> 	assert(s.p == s.q);  // different bits, equal values
> >
> > The bit pattern of s.p would be 0...1 and s.q would be 0...000000000000001
> > widenned to the number of bits in an unsigned int.
> 
>      The bit pattern of s.p is `1', period.  The bit pattern of

No, it isn't. Operands of '==' have to be balanced rvalues. That involves 
loading and promoting the lvalues s.p and s.q into a wider naturals of the same 
size.

>      I've made two points about your post: First, talking about

No, you've had a public brain fart. Congratulations.

-- 
My name Indigo Montoya.      |         It's Coraline, not Caroline.
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#17150

Devil with the China Blue Dress wrote:
) No, the question was about casting an signed number (-1) to an unsigned type. 
) That this can be done and is closed under addition is a property of twos 
) complement integers.

No, that this can be done is a result of the wording of the C standard.
Case in point: it also works on ones complement machines.
Twos complement is just a red herring in this case.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#17153

Am 02/11/2012 11:31 PM, schrieb Devil with the China Blue Dress:
> No, the question was about casting an signed number (-1) to an unsigned type. 
> That this can be done and is closed under addition is a property of twos 
> complement integers.

No, the representation of the -1 has nothing do with the result of
converting it into any unsigned integer type. As has been already been
repeated several times upthread, C strictly defines what has to be done
when converting a negative *value* to an unsigned integer type. And in
particular it uses the value and not the representation.

For all conforming C implementations the result of converting -1 to
size_t is SIZE_MAX.

Jens

[toc] | [prev] | [next] | [standalone]

#17176

In article <4F36F7C4.5060103@loria.fr>, Jens Gustedt <jens.gustedt@loria.fr> 
wrote:

> Am 02/11/2012 11:31 PM, schrieb Devil with the China Blue Dress:
> > No, the question was about casting an signed number (-1) to an unsigned 
> > type. 
> > That this can be done and is closed under addition is a property of twos 
> > complement integers.
> 
> No, the representation of the -1 has nothing do with the result of
> converting it into any unsigned integer type. As has been already been
> repeated several times upthread, C strictly defines what has to be done
> when converting a negative *value* to an unsigned integer type. And in
> particular it uses the value and not the representation.
> 
> For all conforming C implementations the result of converting -1 to
> size_t is SIZE_MAX.

In 4-bit ones complement, -1 is 1110, but the maximum natural number is 1111; 
signed magnitude are 1001 and 1111; twos complement are 1111 and 1111.

Which came first? Twos complement DEC, Honeywell, and IBM machines or the C 
standard which emulated C implementations on twos complement CPUs?  Or did the 
committee just magically pluck that requirement out of the air?

-- 
My name Indigo Montoya.      |         It's Coraline, not Caroline.
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#17180

Devil with the China Blue Dress <chine.bleu@yahoo.com> writes:
> In article <4F36F7C4.5060103@loria.fr>, Jens Gustedt <jens.gustedt@loria.fr> 
> wrote:
[...]
>> For all conforming C implementations the result of converting -1 to
>> size_t is SIZE_MAX.
>
> In 4-bit ones complement, -1 is 1110, but the maximum natural number
> is 1111; signed magnitude are 1001 and 1111; twos complement are 1111
> and 1111.

Yes, in 4-bit ones'-complement -1 is represented by the bit pattern 1110,
but 1111 would be the representation for negative zero.

> Which came first? Twos complement DEC, Honeywell, and IBM machines or
> the C standard which emulated C implementations on twos complement
> CPUs?  Or did the committee just magically pluck that requirement out
> of the air?

Clearly those machines that use[d] a two's-complement
representation for signed types predate the C standard.  C's rules
for signed-to-unsigned conversion are easiest to implement on a
system that uses two's-complement, and require some extra work on
ones'-complement and sign-and-magnitude systems (which are rare
these days).

It seems clear that two's-complement semantics inspired standard C
semantics.  Nevertheless, C's conversion semantics are now *defined*
without reference to the underlying representation.

Which raises a perhaps interesting question.  Are there any current C
implementations for ones'-complement or sign-and-magnitude systems?
If so, what standard, if any, do they conform to, and how much
extra work do the compilers actually do to conform to the required
semantics for signed-to-unsigned conversion?  For that matter,
are there non-conforming C implementations for such systems that
implement such conversions just by reinterpreting the bits?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#17181

On 2012-02-12 21:27, Keith Thompson wrote:
> It seems clear that two's-complement semantics inspired standard C
> semantics.  Nevertheless, C's conversion semantics are now *defined*
> without reference to the underlying representation.
>
> Which raises a perhaps interesting question.  Are there any current C
> implementations for ones'-complement or sign-and-magnitude systems?

Let's not stop there -- I'd be interested in a list of C implementations, 
current *and* historical, for architectures that use one's complement or 
sign-and-magnitude. Both of them were already in the minority by the time C 
rolled around.

The only platform I've been able to find is Univac 1100, which was ones' 
complement and presumably had a C compiler (since it had a Unix port). Of 
course, all of this predates the ANSI standard by a good deal and it may 
have well predated K&R C. Pre-K&R C didn't even have "unsigned", so 
presumably the representation and interpretation of integers was all up for 
grabs.

-- 
J.

[toc] | [prev] | [next] | [standalone]

#17185

In article <4f382c58$0$6922$e4fe514c@news2.news.xs4all.nl>,
 Jeroen Mostert <jmostert@xs4all.nl> wrote:

> On 2012-02-12 21:27, Keith Thompson wrote:
> > It seems clear that two's-complement semantics inspired standard C
> > semantics.  Nevertheless, C's conversion semantics are now *defined*
> > without reference to the underlying representation.
> >
> > Which raises a perhaps interesting question.  Are there any current C
> > implementations for ones'-complement or sign-and-magnitude systems?
> 
> Let's not stop there -- I'd be interested in a list of C implementations, 
> current *and* historical, for architectures that use one's complement or 
> sign-and-magnitude. Both of them were already in the minority by the time C 
> rolled around.
> 
> The only platform I've been able to find is Univac 1100, which was ones' 
> complement and presumably had a C compiler (since it had a Unix port). Of 
> course, all of this predates the ANSI standard by a good deal and it may 
> have well predated K&R C. Pre-K&R C didn't even have "unsigned", so 
> presumably the representation and interpretation of integers was all up for 
> grabs.

CDC were all ones complements until Cyber 180 and 200, but C is one of the few 
languages not ported. There was SYMPL based on Jovial based on Algol 58 and had 
some similarities to B.

-- 
My name Indigo Montoya.      |         It's Coraline, not Caroline.
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#17198

On Feb 12, 11:10 pm, Devil with the China Blue Dress
<chine.b...@yahoo.com> wrote:
> In article <4f382c58$0$6922$e4fe5...@news2.news.xs4all.nl>,
>  Jeroen Mostert <jmost...@xs4all.nl> wrote:
>
>
>
>
>
> > On 2012-02-12 21:27, Keith Thompson wrote:
> > > It seems clear that two's-complement semantics inspired standard C
> > > semantics.  Nevertheless, C's conversion semantics are now *defined*
> > > without reference to the underlying representation.
>
> > > Which raises a perhaps interesting question.  Are there any current C
> > > implementations for ones'-complement or sign-and-magnitude systems?
>
> > Let's not stop there -- I'd be interested in a list of C implementations,
> > current *and* historical, for architectures that use one's complement or
> > sign-and-magnitude. Both of them were already in the minority by the time C
> > rolled around.
>
> > The only platform I've been able to find is Univac 1100, which was ones'
> > complement and presumably had a C compiler (since it had a Unix port). Of
> > course, all of this predates the ANSI standard by a good deal and it may
> > have well predated K&R C. Pre-K&R C didn't even have "unsigned", so
> > presumably the representation and interpretation of integers was all up for
> > grabs.
>
> CDC were all ones complements until Cyber 180 and 200, but C is one of the few
> languages not ported. There was SYMPL based on Jovial based on Algol 58 and had
> some similarities to B.

ICL 1900 series were 1s complment. But I can find no sign that tehre
was a C compiler for them.

[toc] | [prev] | [next] | [standalone]

#17188

Keith Thompson <kst-u@mib.org> writes:
<sni>
> Which raises a perhaps interesting question.  Are there any current C
> implementations for ones'-complement or sign-and-magnitude systems?
> If so, what standard, if any, do they conform to, and how much
> extra work do the compilers actually do to conform to the required
> semantics for signed-to-unsigned conversion?  For that matter,
> are there non-conforming C implementations for such systems that
> implement such conversions just by reinterpreting the bits?

There is one that does both (selectable as an option).  I just happened
to be reading a Unisys C manual[1] recently.  It's part of MCP: Unisys's
OS that runs on big machines derived from a Burroughs architecture.  It
has 48-bit words and 8-bit bytes.

 sizeof char/unsigned char/signed char is 1
 sizeof long double is 12
 sizeof everything else is 6

Despite having 48 bits, all integer types have 39 value bits.  Signed
types have, in addition, a sign bit (presumably the 40th).  The
remaining bits are presumably related to the tagged architecture that
Burroughs machines have always had and, as far as C goes, will be
padding bits.  These machine will definitely have trap-representations,
since some sets of these tag bits are designed to cause traps in certain
situations.

The C implementation has INT_MAX == UINT_MAX and INT_MIN = -INT_MAX and
uses sign-magnitude representation.  It supports ANSI C and it documents
the standard conversion from signed to unsigned types but, later on, in
a section on porting software it says:

  Operations on unsigned integer types are more expensive than on signed
  types. The $RESET PORT (UNSIGNED) option makes unsigned equivalent to
  signed types and should be used on programs that do not depend upon
  the wraparound or bit operation properties of unsigned types.

The document for this options says:

  The UNSIGNED option controls the semantics of the sign attribute for
  integer types. If this option is disabled, unsigned integers are
  treated as signed integers; that is, normal signed-magnitude
  arithmetic is performed. If the option is enabled, unsigned integers
  are emulated as two’s- complement quantities. Enabling this option
  could slow down performance and should be used only when absolutely
  necessary.

For those who wonder about all the oddities in the standard, here is a
system that (a) uses EBCDIC[2]; (b) has unusual sizes and limits; (c) is
not two's complement; (d) has padding bits in all integer types except
the char types; (e) has trap representations in these types; and (f) has
multiple pointer representations (so pointer casts often generate code).
What's more it's *current*: there was recently an MCP 13.0 release with
support into 2013.

Given that the C standard has usually avoided mandating behaviour that
is expensive on some hardware, the behaviour of unsigned is an anomaly.
There was, however, little option since K&R mandated that behaviour long
before ANSI C.

[1] http://public.support.unisys.com/aseries/docs/clearpath-mcp-13.0/pdf/86002268-204.pdf

[2] Though I think you can switch to ASCII if your program needs it.
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#17190

On 2012-02-13 00:25, Ben Bacarisse wrote:
> Keith Thompson<kst-u@mib.org>  writes:
> <sni>
>> Which raises a perhaps interesting question.  Are there any current C
>> implementations for ones'-complement or sign-and-magnitude systems?
>> If so, what standard, if any, do they conform to, and how much
>> extra work do the compilers actually do to conform to the required
>> semantics for signed-to-unsigned conversion?  For that matter,
>> are there non-conforming C implementations for such systems that
>> implement such conversions just by reinterpreting the bits?
>
> There is one that does both (selectable as an option).  I just happened
> to be reading a Unisys C manual[1] recently.  It's part of MCP: Unisys's
> OS that runs on big machines derived from a Burroughs architecture.  It
> has 48-bit words and 8-bit bytes.
>
<snip>
> For those who wonder about all the oddities in the standard, here is a
> system that (a) uses EBCDIC[2]; (b) has unusual sizes and limits; (c) is
> not two's complement; (d) has padding bits in all integer types except
> the char types; (e) has trap representations in these types; and (f) has
> multiple pointer representations (so pointer casts often generate code).
> What's more it's *current*: there was recently an MCP 13.0 release with
> support into 2013.
>
It's like discovering the coelacanth in your bathtub. For Christmas, I'm 
totally buying one of these instead of a second DeathStation 9000 (I may try 
networking it with my original DS9K).

The most interesting thing is that recent generations of the hardware are 
based on Intel processors, meaning that all this hoopla is emulated and kept 
around for legacy software. The companies who use these systems must be at 
least as suitable for historical studies as the system itself.

-- 
J.

[toc] | [prev] | [next] | [standalone]

#17196

On 2012-02-12, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Keith Thompson <kst-u@mib.org> writes:
> There is one that does both (selectable as an option).  I just happened
> to be reading a Unisys C manual[1] recently.  It's part of MCP: Unisys's
> OS that runs on big machines derived from a Burroughs architecture.  It
> has 48-bit words and 8-bit bytes.
>
>  sizeof char/unsigned char/signed char is 1
>  sizeof long double is 12
>  sizeof everything else is 6
>
> Despite having 48 bits, all integer types have 39 value bits.  Signed
> types have, in addition, a sign bit (presumably the 40th).  The
> remaining bits are presumably related to the tagged architecture that
> Burroughs machines have always had and, as far as C goes, will be
> padding bits.  These machine will definitely have trap-representations,
> since some sets of these tag bits are designed to cause traps in certain
> situations.

Having worked with these systems in the early 1980's, I remember
that integers are just floating point numbers where the 8-bit exponent
contains all zeroes, and the (1+39)-bit mantissa holds the value.
The four tag bits (3-bit tag plus 1-bit parity) are not visible to the
programmer. So the hardware actually uses 52-bit words.

[toc] | [prev] | [next] | [standalone]

#17206

Ike Naar <ike@sverige.freeshell.org> writes:

> On 2012-02-12, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>> There is one that does both (selectable as an option).  I just happened
>> to be reading a Unisys C manual[1] recently.  It's part of MCP: Unisys's
>> OS that runs on big machines derived from a Burroughs architecture.  It
>> has 48-bit words and 8-bit bytes.
>>
>>  sizeof char/unsigned char/signed char is 1
>>  sizeof long double is 12
>>  sizeof everything else is 6
>>
>> Despite having 48 bits, all integer types have 39 value bits.  Signed
>> types have, in addition, a sign bit (presumably the 40th).  The
>> remaining bits are presumably related to the tagged architecture that
>> Burroughs machines have always had and, as far as C goes, will be
>> padding bits.  These machine will definitely have trap-representations,
>> since some sets of these tag bits are designed to cause traps in certain
>> situations.
>
> Having worked with these systems in the early 1980's, I remember
> that integers are just floating point numbers where the 8-bit exponent
> contains all zeroes, and the (1+39)-bit mantissa holds the value.

Ah, that makes sense.  There were, I think, CDC machines that did that
too.  Do you know what happened when exponent bits got set (and indeed
if they could get set) by operations like ~?

> The four tag bits (3-bit tag plus 1-bit parity) are not visible to the
> programmer. So the hardware actually uses 52-bit words.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#17228

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Ike Naar <ike@sverige.freeshell.org> writes:
>
>> On 2012-02-12, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> Keith Thompson <kst-u@mib.org> writes:
>>> There is one that does both (selectable as an option).  I just happened
>>> to be reading a Unisys C manual[1] recently.  It's part of MCP: Unisys's
>>> OS that runs on big machines derived from a Burroughs architecture.  It
>>> has 48-bit words and 8-bit bytes.
>>>
>>>  sizeof char/unsigned char/signed char is 1
>>>  sizeof long double is 12
>>>  sizeof everything else is 6
>>>
>>> Despite having 48 bits, all integer types have 39 value bits.  Signed
>>> types have, in addition, a sign bit (presumably the 40th).  The
>>> remaining bits are presumably related to the tagged architecture that
>>> Burroughs machines have always had and, as far as C goes, will be
>>> padding bits.  These machine will definitely have trap-representations,
>>> since some sets of these tag bits are designed to cause traps in certain
>>> situations.
>>
>> Having worked with these systems in the early 1980's, I remember
>> that integers are just floating point numbers where the 8-bit exponent
>> contains all zeroes, and the (1+39)-bit mantissa holds the value.
>
> Ah, that makes sense.  There were, I think, CDC machines that did that
> too.  Do you know what happened when exponent bits got set (and indeed
> if they could get set) by operations like ~?

Well, sort-of.  They did use a representation in which having the sign
and exponent bits all 0 or all 1 would give the same result as an
integer, but they had separate integer and floating point instructions
so an integer add (for instance) could use all 60 bits for value.

The one exception to that rule was multiplication:  there were only
floating point multiplication instructions, but the "double precision"
multiply would correctly multiply two integers, provided the result fit
in 48 (iirc) bits.

I've come across the claim many times that this was in fact an accident
that wasn't noticed until the machine was in production, but haven't
come across any substantiation of it.  I don't think Thornton's book
mentions that you can do this (but could easily be mis-remembering).

[toc] | [prev] | [next] | [standalone]

#17266

On 2012-02-13, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Do you know what happened when exponent bits got set (and indeed
> if they could get set) by operations like ~?

Setting exponent bits was not a problem in itself.
The trouble came when the result was to be interpreted as an integer.
The compiler would then insert normalize-to-integer (NTGR) instructions
in strategic places.
This instruction trapped if normalization was not possible.

Of course, in some cases, even after setting exponent bits, the
resulting value could still be normalizable to a valid integer;
e.g. starting with integer value 77 (mantissa=77, exponent=0), setting
exponent bits so that the exponent becomes 3 yields the new value
77*8**3 = 39424, which is normalized to (mantissa=39424, exponent=0).

The system's main programming language was an extended dialect of Algol.
In that language, it was more convenient to use REAL or BOOLEAN
variables (both 48 bits wide) for bit operations, as these types were
not subject to integer normalization.

I'm not sure if there even was a C compiler available at the time.

[toc] | [prev] | [next] | [standalone]

#17268

Ike Naar <ike@iceland.freeshell.org> writes:

> On 2012-02-13, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Do you know what happened when exponent bits got set (and indeed
>> if they could get set) by operations like ~?
>
> Setting exponent bits was not a problem in itself.
> The trouble came when the result was to be interpreted as an integer.

That's what I meant.

> The compiler would then insert normalize-to-integer (NTGR) instructions
> in strategic places.
> This instruction trapped if normalization was not possible.
>
> Of course, in some cases, even after setting exponent bits, the
> resulting value could still be normalizable to a valid integer;
> e.g. starting with integer value 77 (mantissa=77, exponent=0), setting
> exponent bits so that the exponent becomes 3 yields the new value
> 77*8**3 = 39424, which is normalized to (mantissa=39424, exponent=0).

Ah, thanks.  So this architecture does have trap representations.  The
way the C standard is written, once you access a trap representation,
all bets are off.  So even when there is no hardware trap (like a
signal) any value could result from the access.

> The system's main programming language was an extended dialect of Algol.
> In that language, it was more convenient to use REAL or BOOLEAN
> variables (both 48 bits wide) for bit operations, as these types were
> not subject to integer normalization.
>
> I'm not sure if there even was a C compiler available at the time.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#17269

In article <slrn3vfsjjja2t.q36.ike@iceland.freeshell.org>,
 Ike Naar <ike@iceland.freeshell.org> wrote:

> On 2012-02-13, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> > Do you know what happened when exponent bits got set (and indeed
> > if they could get set) by operations like ~?
> 
> Setting exponent bits was not a problem in itself.
> The trouble came when the result was to be interpreted as an integer.
> The compiler would then insert normalize-to-integer (NTGR) instructions
> in strategic places.
> This instruction trapped if normalization was not possible.
> 
> Of course, in some cases, even after setting exponent bits, the
> resulting value could still be normalizable to a valid integer;
> e.g. starting with integer value 77 (mantissa=77, exponent=0), setting
> exponent bits so that the exponent becomes 3 yields the new value
> 77*8**3 = 39424, which is normalized to (mantissa=39424, exponent=0).
> 
> The system's main programming language was an extended dialect of Algol.
> In that language, it was more convenient to use REAL or BOOLEAN
> variables (both 48 bits wide) for bit operations, as these types were
> not subject to integer normalization.
> 
> I'm not sure if there even was a C compiler available at the time.

The system programming languages were COMPASS (assembly) and SYMPL (Jovial 
derived). The Algol 60 compiler implemented integers as reals; entier was then 
just a possible chopping off of some bits.

-- 
My name Indigo Montoya.      |         It's Coraline, not Caroline.
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web