Re: char type is unsigned with PPC gcc?

Re: char type is unsigned with PPC gcc?

[Ron Flory]

Hi-

 Despite the strongly worded exchanges, this isn't really a big deal.
We all have opinions, which is good.  So long as the compiler lets us
config it the way we think it should be, then I'm happy.

 There are some problems with chars having different signed'ness, such
as many of the GNU tools not compiling correctly on some platforms
though-

Gabriel Paubert wrote:
>
> No, God meant bit 0 to be the MSB ;-) There is no other way around.
> Personnally I always think in big endian with bits numbered from MSB to
> LSB.

 Ummm, endianness has nothing to do with bit ordering from MSB->LSB, it
refers to the order BYTES (or the minimum quanta of assessable data) are
ordered in memory when accessing multi-byte values.  On big-endian
machines the 2-bytes value 0x1234 is stored sequentially as 0x12, 0x34,
whereas little-endian machines store it at 0x34, 0x12.  Notice the bits
in these bytes are not 'mirrored' as you suggest.

 All CPUs I'm aware of (even the PPC) correctly refer to the LSB as
being the rightmost bit, being consistent with the conventions of number
theory and representation, however the PPC is (almost) unique, and
incorrect in labeling the LSB as D31 instead of D0.

> Brain damage is believing that the fact that bit n represents 2 to the
> n has any advantage or mathematical weight.

 Actually not.  The association of data bits Dn as representing 2^n is a
fundamental identity in computer science, electrical engineering, and
mathematics.  A binary numerical value is defined as a polynomial of the
form 2^n-1 + 2^n-2 + n^n-3 + .... 2^0.  The fact that IBM chose to
ignore Mr. Boole's work is an unfortunate historical oversight that we
are stuck with.

> Ok, I have very strong and definitive opinions about these questions, so
> let us agree to disagree. I don't expect to convince you anyway...

 That's OK, I wish you well.  I've got this out of my system now...  ;)

ron

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: char type is unsigned with PPC gcc?

[Gabriel Paubert]

On Thu, 20 Apr 2000, Ron Flory wrote:

> Hi-
>
>  Despite the strongly worded exchanges, this isn't really a big deal.
> We all have opinions, which is good.  So long as the compiler lets us
> config it the way we think it should be, then I'm happy.

Well,

>  There are some problems with chars having different signed'ness, such
> as many of the GNU tools not compiling correctly on some platforms
> though-

Indeed, I know this but there are cases where setting -fsigned-char
actually was a way to hide a bug:

http://lists.linuxppc.org/listarcs/linuxppc-dev/200003/msg00528.html

I don't know how frquent this case is, but I strongly suspect that is is
not an isolated one.

>  Ummm, endianness has nothing to do with bit ordering from MSB->LSB, it
> refers to the order BYTES (or the minimum quanta of assessable data) are
> ordered in memory when accessing multi-byte values.  On big-endian
> machines the 2-bytes value 0x1234 is stored sequentially as 0x12, 0x34,
> whereas little-endian machines store it at 0x34, 0x12.  Notice the bits
> in these bytes are not 'mirrored' as you suggest.

No, bit and byte ordering have to be consistent. Otherwise you end up with
the 68020+ mess, where a bit field one bit wide is not the same as a
single bit. I've not suggested anything about any kind of mirroring or so,
but perhaps did I not express myself clearly.

>  All CPUs I'm aware of (even the PPC) correctly refer to the LSB as
> being the rightmost bit, being consistent with the conventions of number
> theory and representation, however the PPC is (almost) unique, and
> incorrect in labeling the LSB as D31 instead of D0.

You've never seen a NS32000 documentation from the mid-eighties then:
all instructions encodings were show in binary starting from the LSB on
the left side. So 01101001 was 0x96 !

And claiming that the PPC is unique in this respect is simply grossly
incorrect...

> > Brain damage is believing that the fact that bit n represents 2 to the
> > n has any advantage or mathematical weight.
>
>  Actually not.  The association of data bits Dn as representing 2^n is a
> fundamental identity in computer science, electrical engineering, and
> mathematics.  A binary numerical value is defined as a polynomial of the
> form 2^n-1 + 2^n-2 + n^n-3 + .... 2^0.  The fact that IBM chose to
> ignore Mr. Boole's work is an unfortunate historical oversight that we
> are stuck with.

It is is not fundamental by any stretch of the imagination, and this
relationship is a mere superficial convenience as Dan Malek explained much
better than I would.

>  That's OK, I wish you well.  I've got this out of my system now...  ;)

Actually, I believed in all what you claim about polynomials and so on a
long time ago, then I thought deeply and now I've seen the light...

	Regards,
	Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

char type is unsigned with PPC gcc?

[Stephane Laroche]

I just finished debugging the ASH shell, which wasn't running properly
on my 860, and found out that it assumes (correctly if you ask me) that
the type 'char' is signed.

GCC 2.95.2 is configured to have chars unsigned by default on the
PowerPC platforms.  The x86 GCC configures char to be signed... (looking
at gcc/config/rs6000/rs6000.h for the ppc)

Anyone knows why the PowerPC is different in this regard?

Surely I'm not the first one to come across this problem.  Should I fix
ASH or should I reconfigured gcc to default to signed char?  I think the
latter is a better idea since, if I remember correctly, ANSI C says that
char should be signed.

-Stephane


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: char type is unsigned with PPC gcc?

[Gabriel Paubert]

On Wed, 19 Apr 2000, Stephane Laroche wrote:

>
> I just finished debugging the ASH shell, which wasn't running properly
> on my 860, and found out that it assumes (correctly if you ask me) that
> the type 'char' is signed.

No, signed char lead to bugs, I've already been vocal enough about it so I
won't repeat myself. I personnally consider that the only good char is the
unsigned char (signed char also lead to code bloat on many architecture
which have load byte with zero extension but not with sign extension).

> GCC 2.95.2 is configured to have chars unsigned by default on the
> PowerPC platforms.  The x86 GCC configures char to be signed... (looking
> at gcc/config/rs6000/rs6000.h for the ppc)
>
> Anyone knows why the PowerPC is different in this regard?

Because it's an ABI/Platform issue, not a compiler issue. Correctly
written programs should never assume that a char is signed or unsigned.
Any program which depends on this is buggy. This said, there are so many
programs that are buggy that gcc gives you the option with -fsigned-char
and -funsigned-char.

>
> Surely I'm not the first one to come across this problem.  Should I fix
> ASH or should I reconfigured gcc to default to signed char?  I think the
> latter is a better idea since, if I remember correctly, ANSI C says that
> char should be signed.

No, ANSI C leaves it to the implementation. Besides, did I already mention
that signed char leads to bugs ?

	Gabriel.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: char type is unsigned with PPC gcc?

[Stephane Laroche]

Ok, message understood.  Thanks for the info.

For the record, ASH 0.2 must then be modified to run properly on the PowerPC:

    Change line 428 of expand.c to "signed char name;"

-Stephane


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: char type is unsigned with PPC gcc?

[Gabriel Paubert]

On Wed, 19 Apr 2000, Stephane Laroche wrote:

> Ok, message understood.  Thanks for the info.
>
> For the record, ASH 0.2 must then be modified to run properly on the PowerPC:
>
>     Change line 428 of expand.c to "signed char name;"


I don't have the source offhand, so without any context it's not very
useful. It is actually possible that you are covering a bug with this
change (given the typical case in which the problem shows, it's far from
unlikely).

	Gabriel


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/