Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > zero up memory

Reply
Thread Tools

zero up memory

 
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-23-2012
Kaz Kylheku <(E-Mail Removed)> writes:

> On 2012-01-23, Keith Thompson <(E-Mail Removed)> wrote:
>> Malcolm McLean <(E-Mail Removed)> writes:
>>> On Jan 23, 4:57*pm, Johann Klammer <(E-Mail Removed)1.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.
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-23-2012
Malcolm McLean <(E-Mail Removed)> writes:

> On Jan 23, 8:14*pm, Kaz Kylheku <(E-Mail Removed)> wrote:
>>
>> An architecture where zero bits don't make a 0.0 floating point value
>> is plain stupid (and not IEEE 754 compatible).
>>

> Zero cannot be represented in floating point, because the exponent is
> minus infinity.


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.

> If you have a signed exponent, zero would represent unity, or number
> within the range 1 - 2. You might reserve high bit set for special
> numbers, and zero could be one of those special numbers.
> Most existing floating point formats use an offset to represent
> exponents, so zero exponent represents the lowest representable value,
> and all bits zero can be used for zero. However this isn't
> particularly logical, and there might be low-level circuit reasons for
> preferring a two's complement exponent.


In IEEE binary floating point formats, a zero exponent is special. It
is not simply the lowest exponent, but flags up a set of special values:
+0 and -0 when the mantissa is 0 and denormalised numbers when it
is not zero (and the actual exponent used is 1 not zero i.e. the lowest
"real" exponent).

--
Ben.
 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      01-24-2012
On Jan 23, 11:21*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
>
> 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.
>

So how does the processor do equality comparisons, efficiently?

If the mantissa is not normalized then there are many possible
representations for each number, including zero.

--
MPI tutorial - learn parallel programming in C
http://www.malcolmmclean.site11.com/www
 
Reply With Quote
 
Joe keane
Guest
Posts: n/a
 
      01-24-2012
In article <(E-Mail Removed)>,
Malcolm McLean <(E-Mail Removed)> 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.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-24-2012
Malcolm McLean <(E-Mail Removed)> writes:

> On Jan 23, 11:21*pm, Ben Bacarisse <(E-Mail Removed)> wrote:
>>
>> 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.
>>

> So how does the processor do equality comparisons, efficiently?
>
> If the mantissa is not normalized then there are many possible
> representations for each number, including zero.


I am not 100% sure I have the terminology right. The mantissa may be
normalised in the sense of having no redundant leading zero digits but
in the systems I am describing (ones that don't use binary) there can't
be an implicit leading digit. A normalised binary mantissa always
starts 0.1... so such system don't bother to store the leading 1. As a
result, zero can't be represented with a zero mantissa. On systems with
non binary digits, the leading digit can't be omitted so a zero
mantissa represents zero no matter what the exponent is.

I can't answer your question about efficient equality testing -- you'd
have to ask a hardware designer. However, the fact that there are
redundant representations should not be a surprise. I don't know any FP
format that does not have multiple representations that must compare
equal (+0 and -1 being the most common example).

--
Ben.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-24-2012
Ben Bacarisse <(E-Mail Removed)> writes:
[...]
> I can't answer your question about efficient equality testing -- you'd
> have to ask a hardware designer. However, the fact that there are
> redundant representations should not be a surprise. I don't know any FP
> format that does not have multiple representations that must compare
> equal (+0 and -1 being the most common example).


I think you mean +0 and -0.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-24-2012
(E-Mail Removed) (Joe keane) writes:
> In article <(E-Mail Removed)>,
> Malcolm McLean <(E-Mail Removed)> 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) (E-Mail Removed) <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"
 
Reply With Quote
 
Johann Klammer
Guest
Posts: n/a
 
      01-24-2012
Malcolm McLean wrote:
> So how does the processor do equality comparisons, efficiently?
>
> If the mantissa is not normalized then there are many possible
> representations for each number, including zero.
>
> --
> MPI tutorial - learn parallel programming in C
> http://www.malcolmmclean.site11.com/www


Usually one does an epsilon test.
with epsilon rather small

if(((a+epsilon)<b)&&((a-epsilon)>b))
{

}

The following will most likely evaluate to false on intel machines
The compiler just does a (bitwise)equality test.

a=+0.0;
b=-0.0;

if(a==b)
{

}
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-24-2012
Johann Klammer <(E-Mail Removed)1.net> writes:
> Malcolm McLean wrote:
>> So how does the processor do equality comparisons, efficiently?
>>
>> If the mantissa is not normalized then there are many possible
>> representations for each number, including zero.

>
> Usually one does an epsilon test.
> with epsilon rather small
>
> if(((a+epsilon)<b)&&((a-epsilon)>b))
> {
>
> }


That doesn't address the question, which is how the processor performs a
floating-point equality test, the one specified by C's "==" operator.

> The following will most likely evaluate to false on intel machines
> The compiler just does a (bitwise)equality test.
>
> a=+0.0;
> b=-0.0;
>
> if(a==b)
> {
>
> }


Only if the compiler is broken. "a==b" yields 1 if a and b are
*numerically* equal, 0 if they're not. If two bit patterns represent
the same value, bitwise comparison will not work.

Oh, and "b=-0.0" won't set b to a floating-point negative zero.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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"
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      01-24-2012
On 01/24/2012 12:35 PM, Malcolm McLean wrote:
> On Jan 23, 11:21 pm, Ben Bacarisse <(E-Mail Removed)> wrote:
>>
>> 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.
>>

> So how does the processor do equality comparisons, efficiently?
>
> If the mantissa is not normalized then there are many possible
> representations for each number, including zero.


The case that I'm most familiar with, IEEE 754 double precision,
sub-normal numbers have an exponent of 0, a sign bit, and 52 bits of
mantissa, and represent the values (-1)^sign * mantissa* 2^(-1022-52).
The smallest positive value that can be represented is 2^(-1074), the
largest is 2^(-1022) - 2^(-1074).

For normal numbers, 0<exponent && exponent < 0x7FF. The value
represented is (-1)^sign*(1.mantissa)*2^(exponent - 1023). The smallest
positive value represented by this mechanism occurs when mantissa is 0
and exponent is 1, which represents 2^(-1022). That is exactly 2^-1074
bigger than the biggest subnormal value.

The exponent value 0x7FF is reserved for infinities and NaNs.

There doesn't seem to be any overlap in the ranges of normal and
subnormal values, and within each category, all of the non-zero values
that can be represented have a unique representation. A value of exactly
0 must have it's mantissa and exponent both zero, but can have it's sign
bit either set or cleared. As a result, equality comparisons can be
replaced by memcmp(), except for the special handling required by IEEE
754 for +0, -0, infinities and NaNs.
Within this scheme, could you provide an example of the "many possible
representations for each number" that you're referring to?


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
zero memory Christopher Pisz C++ 25 04-09-2007 04:11 AM
Can you set a class instance's attributes to zero by setting the instance to zero? Gerard Flanagan Python 3 11-19-2005 06:58 PM
Wireless Zero Configuration Memory Leak?? =?Utf-8?B?Umlja3NjaHVsdHox?= Wireless Networking 3 01-19-2005 11:26 PM
Doubles and zero/negative zero Christopher Benson-Manica C Programming 4 07-01-2004 05:44 PM
memset all bits to zero will let float/double to zero? Zhiqiang Ye C Programming 53 06-28-2004 01:23 PM



Advertisments