char type is unsigned with PPC gcc?

Gabriel Paubert paubert at iram.es
Fri Apr 21 07:58:46 EST 2000


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/





More information about the Linuxppc-embedded mailing list