Subject: devel-digest V2 #206
From: [email-masked] (devel-digest)
To: [email-masked]

devel-digest          Thursday, June 24 1999          Volume 02 : Number 206

In this issue:

    Re: Bit length of double on ARM
    Re: Bit length of double on ARM
    Re: Bit length of double on ARM

See the end of this digest for information about devel-digest.

----------------------------------------------------------------------

Date: Wed, 23 Jun 1999 11:09:34 +0200
From: Jan Rinze <[email-masked]>
Subject: Re: Bit length of double on ARM

Eric \"The Borg\" LaForest wrote:

>
> Ahh....thus bypassing the obscure rule (I presume) which makes double
> foo = foo<<32
> illegal.  (The compiler doesn't like it.)
> (Eric needs a C language lawyer book to cover these bit-level oddities.)
>
> --
> "We're only in it for the volume."
>             -- Black Sabbath

just out of curiosity , is this a Netwinder related problem or a common gcc issue
?

If not, what needs to be changed in the compiler ?

( I am planning to take a very good look at the sources of gcc.
 Oh my, what did I just say ?? ;-)

Jan Rinze.

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Wed, 23 Jun 1999 12:34:39 -0400
From: Scott Bambrough <[email-masked]>
Subject: Re: Bit length of double on ARM

This is a multi-part message in MIME format.
- --------------BA345B4868B84B1F136AA576
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jan Rinze wrote:
> 
> Eric \"The Borg\" LaForest wrote:
> 
> >
> > Ahh....thus bypassing the obscure rule (I presume) which makes double
> > foo = foo<<32  illegal.  (The compiler doesn't like it.)
> > (Eric needs a C language lawyer book to cover these bit-level oddities.)
> >
> 
> just out of curiosity , is this a Netwinder related problem or a 
> common gcc issue?
> 

It is a common issue.  And nothing needs to be changed in the compiler, as far
as I can see there is nothing wrong here.  The bit twiddling code was just
carelessly written (sorry Eric :( ).  If you stop to think about <<32, you have
asked the compiler to shift one bit farther than is possible to an int.  To
expect silent promotion of an integer type (char) to anything else but another
integer type (int) is silly.  long long is not a standard C type sto I wouldn't
expect that to happen as well.

Scott
- --------------BA345B4868B84B1F136AA576
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Scott Bambrough
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Scott Bambrough
n:              Bambrough;Scott
org:            Rebel.com
adr:            150 Isabella St.;;;Ottawa;Ontario;K1S 1V7;Canada
email;internet: [email-masked]
title:          Software Engineer
tel;work:       (613) 788-6000 x6116
tel;fax:        (613) 230-8300
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard

- --------------BA345B4868B84B1F136AA576--

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

Date: Wed, 23 Jun 1999 17:48:49 +0100
From: Philip Blundell <[email-masked]>
Subject: Re: Bit length of double on ARM

Jan Rinze wrote:

> Eric \"The Borg\" LaForest wrote:
>
> > Ahh....thus bypassing the obscure rule (I presume) which makes double
> > foo = foo<<32
> > illegal.  (The compiler doesn't like it.)
> > (Eric needs a C language lawyer book to cover these bit-level oddities.)
>
> just out of curiosity , is this a Netwinder related problem or a common gcc issue?

No.  Again, it is just the way the C language works.  I am not a language lawyer so
take this explanation with a truckload of salt, but...

Remember that integers are represented as straight two's complement binary, and
floating point numbers are represented in IEEE 754 notation.  If you cast (either
explicitly or implicitly) between an integer and a floating point variable, the
compiler will generate instructions to convert between these two formats to preserve
the value, truncating or extending as appropriate.  So you can write:

    int i = 1;
    double d = i;
    printf("%f", d);

and the output will be "1.0".   If you write the last line as

    printf("%d", d);

the conversion is not performed, and you get the wrong result.  You can restore this
to workingsville by inserting an explicit cast:

    printf("%d", (int)d);

What all this means is that the language is concealing the internal storage format
from you in almost all cases.  This makes it a lot easier to write programs that
behave as you would expect in simple cases, but the flip-side is that bitwise
operations on floating point numbers are basically outlawed.

In code like this:

    double foo(int a, int b)
    {
        return (double)(a | (b << 8));
    }

the result of the shift and OR is calculated as an integer and then the result is
promoted to "double".  This is not at all the same thing as returning the 64-bit
integer value you would get by concatenating "a" and "b" in that way.  If you try to
shift and OR two "double" variables you will get a compile-time error.

In the example Eric gave where you have "double foo = foo << 32", this is illegal
because (as Andrew pointed out) the shift takes place on an "int" which then
overflows.  Shifting a "double" would work even less well because this is not
allowed at all.  If "foo" had type "long long" then this construct would be valid
but it would not buy you a great deal.

The only ISO-sanctioned way to do the sort of dubious type-punning that has been
suggested here (ie to construct and dismantle "double" quantities on a bit-by-bit
basis) is to use a union.  Under some compilers you can also get away with this sort
of game:

    double d;
    char *c = (char *)&d;

but this results in undefined behaviour and you will get bitten sooner or later.

BTW, I think the C9x standard will make the 64-bit "long long" integral type
mandatory, and I would expect to see it supported in the majority of compilers
before very long.  So using it may not be all that much of an evil after all.

p.

- ---
This message processed by the Netwinder.Org news2mail gateway.

- --
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel" as the body of your message.

------------------------------

End of devel-digest V2 #206
***************************

--
This list is run automagically by Majordomo 1.94.4
Please send email questions to [email-masked]
To UNSUBSCRIBE: email [email-masked] with
"unsubscribe devel-digest" as the body of your message.