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

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

zero up memory

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

Contents

  zero up memory "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2012-01-23 10:51 -0500
    Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-23 16:30 +0000
    Re: zero up memory Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-01-23 17:57 +0100
      Re: zero up memory Kenneth Brody <kenbrody@spamcop.net> - 2012-01-23 12:07 -0500
      Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-23 09:08 -0800
        Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-23 09:22 -0800
          Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-23 10:13 -0800
            Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-23 12:00 -0800
          Re: zero up memory Kaz Kylheku <kaz@kylheku.com> - 2012-01-23 20:14 +0000
            Re: zero up memory "Joel C. Salomon" <joelcsalomon@gmail.com> - 2012-01-23 16:46 -0500
            Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-23 14:05 -0800
              Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-23 23:21 +0000
                Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-24 09:35 -0800
                  Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-24 20:56 +0000
                    Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-24 14:07 -0800
                      Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-25 17:38 +0000
                  Re: zero up memory Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-01-24 23:15 +0100
                    Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-24 14:31 -0800
                      Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-25 15:39 +0000
                        Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-25 15:49 +0000
                          Re: zero up memory Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:09 -0800
                        Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-25 13:05 -0800
                          Re: zero up memory Sjouke Burry <s@b> - 2012-01-25 23:25 +0000
                          Re: zero up memory Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:11 -0800
                            Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-26 11:48 -0800
                            Re: zero up memory gordonb.p79fg@burditt.org (Gordon Burditt) - 2012-03-12 17:55 -0500
                              Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-03-12 22:10 -0400
                                Re: zero up memory Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-03-12 23:24 -0400
                                  Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-03-12 23:53 -0400
                                Re: zero up memory gordonb.pu5nu@burditt.org (Gordon Burditt) - 2012-03-13 00:58 -0500
                                  Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-03-14 11:17 -0400
                          Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-26 11:19 -0800
                            Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-27 08:13 +0000
                          Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-26 14:42 +0000
                        Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-25 12:33 -0800
                          Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-26 14:12 +0000
                  Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-01-24 17:43 -0500
                    Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-24 16:29 -0800
                      Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-01-24 21:43 -0500
                        Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-24 23:58 -0800
                          Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-25 17:52 +0000
                        Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-25 17:48 +0000
                          Re: zero up memory Robert Wessel <robertwessel2@yahoo.com> - 2012-01-25 12:15 -0600
                            Re: zero up memory blp@cs.stanford.edu (Ben Pfaff) - 2012-01-25 10:35 -0800
                              Re: zero up memory Robert Wessel <robertwessel2@yahoo.com> - 2012-01-25 17:15 -0600
                                Re: zero up memory Robert Wessel <robertwessel2@yahoo.com> - 2012-01-25 17:23 -0600
                                Re: zero up memory "BartC" <bc@freeuk.com> - 2012-01-25 23:51 +0000
                                  Re: zero up memory Robert Wessel <robertwessel2@yahoo.com> - 2012-01-26 18:35 -0600
                          Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-01-25 13:17 -0500
            Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-23 22:55 +0000
        Re: zero up memory jgk@panix.com (Joe keane) - 2012-01-24 20:45 +0000
          Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-24 14:13 -0800

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

#16203

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Jan 25, 2:43 am, James Kuyper <jameskuy...@verizon.net> wrote:
>>
>> Am I right in assuming that you concede the feasibility of efficiently
>> implemented equality comparisons involving IEEE 754 sub-normals?
>
> I'm answering this:
>
> Ben Bacarisse
>
> In systems where the mantissa is not normalised (i.e. there is no
> implicit leading 1) then zero is specified quite naturally with a zero
> mantissa.  A zero sign bit and exponent (even it biased) makes no
> difference.  Systems like this are common: IEEE decimal floating point
> and IBM's hexadecimal floating point come to mind.

s/is not normalised/has no hidden bit/

I should not have conflated this with normalisation though my excuse is
that such formats can have leading zero bits in the mantissa so the
"look" un-normalised.

It does not alter the issue that there are then a very large number of
representations of zero.

-- 
Ben.

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

#16202

James Kuyper <jameskuyper@verizon.net> writes:
<snip>
>                               When you read Ben's first message about
> "unnormalized numbers" it's quite clear that he was talking about what
> IEEE calls sub-normals, for which the exponent must be 0; and not about
> anything resembling the architecture you describe.

Actually I wasn't.  I was referring to representation with no "hidden
bit".  It's linked to normalisation because, when the base is > 2 there
can be leading zeros in the mantissa even when the number is
"normalised" (mantissa shifted as far left as possible).

IBM machine use/used such a format.  The result is that there are lots
of zeros: a zero mantissa does not mean 0.1xxx... but 0 so the exponent
has no effect on the value.

-- 
Ben.

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

#16204

On Wed, 25 Jan 2012 17:48:44 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>James Kuyper <jameskuyper@verizon.net> writes:
><snip>
>>                               When you read Ben's first message about
>> "unnormalized numbers" it's quite clear that he was talking about what
>> IEEE calls sub-normals, for which the exponent must be 0; and not about
>> anything resembling the architecture you describe.
>
>Actually I wasn't.  I was referring to representation with no "hidden
>bit".  It's linked to normalisation because, when the base is > 2 there
>can be leading zeros in the mantissa even when the number is
>"normalised" (mantissa shifted as far left as possible).
>
>IBM machine use/used such a format.  The result is that there are lots
>of zeros: a zero mantissa does not mean 0.1xxx... but 0 so the exponent
>has no effect on the value.


FWIW, a slightly closer to common example is the 80-bit real format on
x87.  While still binary, it does not have the implicit (hidden) one
bit of the 32 and 64 bit formats (IOW, the leading one bit is actually
stored), and thus has a bunch of "pseudo-zeros" (Intel terminology)
where the mantissa is zero but the exponent is not.  Early versions of
the x87 treated those mostly as true zeros, but since the 387 (I
think), pseudo-zeros have been disallowed.

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

#16205

Robert Wessel <robertwessel2@yahoo.com> writes:

> FWIW, a slightly closer to common example is the 80-bit real format on
> x87.  While still binary, it does not have the implicit (hidden) one
> bit of the 32 and 64 bit formats (IOW, the leading one bit is actually
> stored), and thus has a bunch of "pseudo-zeros" (Intel terminology)
> where the mantissa is zero but the exponent is not.  Early versions of
> the x87 treated those mostly as true zeros, but since the 387 (I
> think), pseudo-zeros have been disallowed.

I've never understood why the 80-bit format differs from the 32-
and 64-bit formats in this respect.
-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

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

#16207

On Wed, 25 Jan 2012 10:35:15 -0800, blp@cs.stanford.edu (Ben Pfaff)
wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> FWIW, a slightly closer to common example is the 80-bit real format on
>> x87.  While still binary, it does not have the implicit (hidden) one
>> bit of the 32 and 64 bit formats (IOW, the leading one bit is actually
>> stored), and thus has a bunch of "pseudo-zeros" (Intel terminology)
>> where the mantissa is zero but the exponent is not.  Early versions of
>> the x87 treated those mostly as true zeros, but since the 387 (I
>> think), pseudo-zeros have been disallowed.
>
>I've never understood why the 80-bit format differs from the 32-
>and 64-bit formats in this respect.


It is odd.  The standard actually allows that for the extended
formats.  My theory has always been that this was a more convenient
internal representation for the 8087 (IOW, with an explicit one bit),
and they just ended up exposing that as an enhancement along the way.
Since they would have needed to save that format anyway for state
changes, going to an 81 bit internal/80 bit external (with an implied
one bit) format, might have lead to other oddities (not to mention
that the 8087 was quite an ambitious chip for its time anyway).

But what's one more oddity in x86 and x87?

Sun and IBM, which have both architected 128 bit IEEE floats in SPARC
and zArch (Sun never actually did them in hardware, but IBM has), keep
the same (with an implied one bit) format as for the 32 and 64 bit
formats.

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

#16208

On Wed, 25 Jan 2012 17:15:55 -0600, Robert Wessel
<robertwessel2@yahoo.com> wrote:

>On Wed, 25 Jan 2012 10:35:15 -0800, blp@cs.stanford.edu (Ben Pfaff)
>wrote:
>
>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>> FWIW, a slightly closer to common example is the 80-bit real format on
>>> x87.  While still binary, it does not have the implicit (hidden) one
>>> bit of the 32 and 64 bit formats (IOW, the leading one bit is actually
>>> stored), and thus has a bunch of "pseudo-zeros" (Intel terminology)
>>> where the mantissa is zero but the exponent is not.  Early versions of
>>> the x87 treated those mostly as true zeros, but since the 387 (I
>>> think), pseudo-zeros have been disallowed.
>>
>>I've never understood why the 80-bit format differs from the 32-
>>and 64-bit formats in this respect.
>
>
>It is odd.  The standard actually allows that for the extended
>formats.  My theory has always been that this was a more convenient
>internal representation for the 8087 (IOW, with an explicit one bit),
>and they just ended up exposing that as an enhancement along the way.
>Since they would have needed to save that format anyway for state
>changes, going to an 81 bit internal/80 bit external (with an implied
>one bit) format, might have lead to other oddities (not to mention
>that the 8087 was quite an ambitious chip for its time anyway).
>
>But what's one more oddity in x86 and x87?
>
>Sun and IBM, which have both architected 128 bit IEEE floats in SPARC
>and zArch (Sun never actually did them in hardware, but IBM has), keep
>the same (with an implied one bit) format as for the 32 and 64 bit
>formats.


I meant to mention that Intel kept the explicit one bit format for the
internal representation on IPF.  In fact there they actually extended
the exponent field, so the registers are actually 82(!) bits wide
(sign, 17 bit exponent, 64 bit mantissa - with an explicit one bit).

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

#16241

"Robert Wessel" <robertwessel2@yahoo.com> wrote in message 
news:qq21i7l77mc2gurh9l4kotbvvfjvbiv02b@4ax.com...
> On Wed, 25 Jan 2012 10:35:15 -0800, blp@cs.stanford.edu (Ben Pfaff)
> wrote:
>
>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>> FWIW, a slightly closer to common example is the 80-bit real format on
>>> x87.  While still binary, it does not have the implicit (hidden) one
>>> bit of the 32 and 64 bit formats (IOW, the leading one bit is actually
>>> stored), and thus has a bunch of "pseudo-zeros" (Intel terminology)
>>> where the mantissa is zero but the exponent is not.  Early versions of
>>> the x87 treated those mostly as true zeros, but since the 387 (I
>>> think), pseudo-zeros have been disallowed.
>>
>>I've never understood why the 80-bit format differs from the 32-
>>and 64-bit formats in this respect.
>
>
> It is odd.  The standard actually allows that for the extended
> formats.  My theory has always been that this was a more convenient
> internal representation for the 8087 (IOW, with an explicit one bit),
> and they just ended up exposing that as an enhancement along the way.

The 32/64-bit formats are designed to be stored in memory, so there could be 
millions of such numbers, and it was useful to have an extra bit of 
precision in all those stored numbers by not storing that '1' bit. (Using 
33/65-bits would be a trifle inconvenient.)

With the internal 80-bit format, that was not important, as there are only 8 
or so such numbers. The ability to store that format externally was probably 
just a bonus as you say.

And in the 80-bit format, I believe 64-bits of that is mantissa, with an 
explicit '1' bit. Presumably the internal circuits were 64-bits wide. There 
would have been little benefit to storing only 63-bits in the user register; 
you'd get an slightly better exponent range perhaps, but it's already wide 
enough for most purposes. Or you'd only need to have 79-bit wide registers!

-- 
Bartc

 

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

#16276

On Wed, 25 Jan 2012 23:51:50 -0000, "BartC" <bc@freeuk.com> wrote:

>
>
>"Robert Wessel" <robertwessel2@yahoo.com> wrote in message 
>news:qq21i7l77mc2gurh9l4kotbvvfjvbiv02b@4ax.com...
>> On Wed, 25 Jan 2012 10:35:15 -0800, blp@cs.stanford.edu (Ben Pfaff)
>> wrote:
>>
>>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>>
>>>> FWIW, a slightly closer to common example is the 80-bit real format on
>>>> x87.  While still binary, it does not have the implicit (hidden) one
>>>> bit of the 32 and 64 bit formats (IOW, the leading one bit is actually
>>>> stored), and thus has a bunch of "pseudo-zeros" (Intel terminology)
>>>> where the mantissa is zero but the exponent is not.  Early versions of
>>>> the x87 treated those mostly as true zeros, but since the 387 (I
>>>> think), pseudo-zeros have been disallowed.
>>>
>>>I've never understood why the 80-bit format differs from the 32-
>>>and 64-bit formats in this respect.
>>
>>
>> It is odd.  The standard actually allows that for the extended
>> formats.  My theory has always been that this was a more convenient
>> internal representation for the 8087 (IOW, with an explicit one bit),
>> and they just ended up exposing that as an enhancement along the way.
>
>The 32/64-bit formats are designed to be stored in memory, so there could be 
>millions of such numbers, and it was useful to have an extra bit of 
>precision in all those stored numbers by not storing that '1' bit. (Using 
>33/65-bits would be a trifle inconvenient.)
>
>With the internal 80-bit format, that was not important, as there are only 8 
>or so such numbers. The ability to store that format externally was probably 
>just a bonus as you say.
>
>And in the 80-bit format, I believe 64-bits of that is mantissa, with an 
>explicit '1' bit. Presumably the internal circuits were 64-bits wide. There 
>would have been little benefit to storing only 63-bits in the user register; 
>you'd get an slightly better exponent range perhaps, but it's already wide 
>enough for most purposes. Or you'd only need to have 79-bit wide registers!


Most of the circuits would need to be wider than 64 bits anyway, you
need some additional bits so you can handle rounding correctly.

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

#16218

On 01/25/2012 12:48 PM, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> <snip>
>>                               When you read Ben's first message about
>> "unnormalized numbers" it's quite clear that he was talking about what
>> IEEE calls sub-normals, for which the exponent must be 0; and not about
>> anything resembling the architecture you describe.
> 
> Actually I wasn't.  I was referring to representation with no "hidden
> bit".  It's linked to normalisation because, when the base is > 2 there
> can be leading zeros in the mantissa even when the number is
> "normalised" (mantissa shifted as far left as possible).
> 
> IBM machine use/used such a format.  The result is that there are lots
> of zeros: a zero mantissa does not mean 0.1xxx... but 0 so the exponent
> has no effect on the value.

I read "unnormalized", and didn't pay close enough attention to realize
that you were talking about something more exotic than ordinary IEEE 754
sub-normals. After Malcolm's last message I looked up "decimal floating
point" and learned that it has precisely the feature he was talking
about. I apologize for my confusion, and any confusion I may have caused.

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

#16080

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2012-01-23, Keith Thompson <kst-u@mib.org> wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>> On Jan 23, 4:57 pm, Johann Klammer <klamm...@NOSPAM.a1.net> wrote:
>>>>
>>>> calloc implicitly zeroes the allocated memory(all the struct fields).
>>>>
>>> Yes. Calloc() was specified before the C standard was worked out.
>>>
>>> All bits zero isn't necessarily a floating point zero, and it isn't
>>> necessarily a null pointer. Which makes calloc() pretty useless.
>>
>> It's useful if the allocated memory doesn't contain any floating-point
>> or pointer subobjects.
>
> It's useful even if it isn't, just no portable.

Which is what Keith said immediately after the remark you quote.  Why
cut it?  You could have left it in and still make the point you want to
make (the insanity and scarcity of these odd architectures) without
suggesting that Keith was excluding the use of calloc in non-portable
code.

<snip>
-- 
Ben.

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

#16119

In article <7edb6549-55af-4c5a-91b7-5633b6215246@n6g2000vbz.googlegroups.com>,
Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
>All bits zero isn't necessarily a floating point zero, and it isn't
>necessarily a null pointer. Which makes calloc() pretty useless.

To be honest, i don't think it's a big problem.  I have code where i
simply 'memset' the whole struct, and i'm sure it's been ported to
twenty machines.  No one ever comes back and says 'i ran into that
thing where you memset the struct, it didn't work'.

So there's practical portable versus paranoid portable.

It's something i just don't care about and i think is not worth spending
your time on.  My employer doesn't care i don't care because, while
customers may have pretty diverse platforms, they're not geting stuff
from bizarro world.

Architectures can be different, but there really isn't much variation
these days in how basic data types [integer, floating-point number,
pointer] are stored [and how VM basically works].

This is something that people were unsure about 40 years ago; now we
'have the answer'.  Such things seem sufficient obvious that you don't
think about it much.

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

#16134

jgk@panix.com (Joe keane) writes:
> In article <7edb6549-55af-4c5a-91b7-5633b6215246@n6g2000vbz.googlegroups.com>,
> Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
>>All bits zero isn't necessarily a floating point zero, and it isn't
>>necessarily a null pointer. Which makes calloc() pretty useless.
>
> To be honest, i don't think it's a big problem.  I have code where i
> simply 'memset' the whole struct, and i'm sure it's been ported to
> twenty machines.  No one ever comes back and says 'i ran into that
> thing where you memset the struct, it didn't work'.
>
> So there's practical portable versus paranoid portable.
>
> It's something i just don't care about and i think is not worth spending
> your time on.  My employer doesn't care i don't care because, while
> customers may have pretty diverse platforms, they're not geting stuff
> from bizarro world.
>
> Architectures can be different, but there really isn't much variation
> these days in how basic data types [integer, floating-point number,
> pointer] are stored [and how VM basically works].
>
> This is something that people were unsure about 40 years ago; now we
> 'have the answer'.  Such things seem sufficient obvious that you don't
> think about it much.

There was a very similar attitude that assumed that dereferencing a null
pointer would give you zero:

    int *ptr = NULL;
    int *result = *ptr; /* undefined behavior */
    assert(result == 0);

because a very popular system happened to guarantee it.  A whole lot of
code broke when it was ported to a new system.

There were similar assumptions expressed as "All the world's a VAX"; the
more modern equivalent woudl be "All the world's an x86".

Admittedly there's a more widespread basis for assuming that
floating-point 0.0 and null pointers are represented as all-bits-zero --
but they're still assumptions that are not supported by the standard.

If it turns out that all existing implementatations happen to satisfy
those assumptions, I wouldn't object to adding them as requirements in a
future edition of the C standard.  That's exactly what happened with the
assumption that all-bits-zero is a representation of 0 for all integer
types; standards up to and including C99 didn't make that guarantee, but
it was added in one of the Technical Corrigenda and appears in the C11
standard.

Until and unless that happens, I'm not going to count on it -- or if I
do, I'll add a prominent comment documention my assumptions, so future
maintainers will know where to look if things break.

-- 
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] | [standalone]

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

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

csiph-web