🚀 go-pugleaf

Peter Curran (pcurran@inforamp.net) wrote:
: On 9 Jan 1996 18:09:46 GMT in article <4cub1a$jbl@alterdial.UU.NET>
:     rex@aussie.com (rex@aussie.com) wrote:

: >There was considerable debate about whether or not integers could be stored 
: >as BCD, Grey code, or some such, but in the end, we decided that they had to 
: >be stored as binary numbers. And, of course, 2's comp, 1's comp, and signed 
: >magnitude all use all-bits-zero for zero. The only thing that could cause a 
: >problem is for machines/compilers with signed zeros; I think that negative 
: >zero might have some other bit pattern.

: I don't think this is the full story.  The *used* bits have to be zero.
: However, there has been agreement that the integers can have "holes" (unused
: bits), and those bits could be required to be non-zero in some architectures, I
: would think. 

Also (under as-if) the bits one sees probably only have to look like binary
to operations such as & and <<. For example I think it is possible to
do something like invert the bits as you read/write memory. Consider this
perverse implementation:
    char - normal binary encoding
    int - binary encoding except that bits are inverted when reading/writing
        memory.

Thus binary 0000 written as char will look like binary 1111 when read as int.
So 'memset( &i, 0, sizeof(int) )' will not set int 'i' to 0.
However ints can be copied safely by copying them as an array of char.
Provided normal conversion between int and char works to give the expected
arithmetic results I think that this implementation should meet the standard.


P.S. Was there ever a final ruling over whether UINT_MAX had to be of the
form 2^n-1 ?

--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom