bits, representations in integers

**Eric Sosman** · Oct 9 '08, 05:25 PM

Re: bits, representations in integers

vippstar@gmail. com wrote:

Hello
>
Let's assume CHAR_BIT == 8, sizeof (int) == 4 and INT_MAX == 32767
(that'd mean int has 32 bits, of which only the 15 are value bits)
>
Now, my question is, are the value bits required to be contiguous in
the representation?

No. 6.2.6.1: "The representations of all types are unspecified
except as stated in this subclause," and the subclause says nothing
about how the bits are arranged.

Is the position of the signed bit fixed (ie, the last bit, the first
bit)

No.

Or even the craziest representation such as: (p = padding bits, v =
value bits, s = sign bit)
>
pvpvpvpv pvspvpvp pvpvpvpv pvpvpvpv
>
is allowed?

Sure. Note that you cannot "see" the individual bits of a byte
in isolation from the value that they represent. You might be able
to determine by experiment which byte a specified value bit occupies
(though even this much is chancy in the presence of padding bits
whose settings you do not control), but that's about all.

--
Eric.Sosman@sun .com

**vippstar@gmail.com** · Oct 9 '08, 05:35 PM

Re: bits, representations in integers

On Oct 9, 8:20 pm, Eric Sosman <Eric.Sos...@su n.comwrote:
Message-ID: <1223572818.225 547@news1nwk>

Thanks.

**Nate Eldredge** · Oct 9 '08, 06:15 PM

Re: bits, representations in integers

Eric Sosman <Eric.Sosman@su n.comwrites:

vippstar@gmail. com wrote:

>Hello
>>
>Let's assume CHAR_BIT == 8, sizeof (int) == 4 and INT_MAX == 32767
>(that'd mean int has 32 bits, of which only the 15 are value bits)
>>
>Now, my question is, are the value bits required to be contiguous in
>the representation?

>
No. 6.2.6.1: "The representations of all types are unspecified
except as stated in this subclause," and the subclause says nothing
about how the bits are arranged.

However, in some ways the compiler has to behave as if they are
contiguous. For instance, in

int a,b;
a=1;
b = a << 1;

b must be given the value 2, according to 6.5.7.

>Is the position of the signed bit fixed (ie, the last bit, the first
>bit)

>
No.
>

>Or even the craziest representation such as: (p = padding bits, v =
>value bits, s = sign bit)
>>
>pvpvpvpv pvspvpvp pvpvpvpv pvpvpvpv
>>
>is allowed?

>
Sure. Note that you cannot "see" the individual bits of a byte
in isolation from the value that they represent. You might be able
to determine by experiment which byte a specified value bit occupies
(though even this much is chancy in the presence of padding bits
whose settings you do not control), but that's about all.

Note in this case the compiler would have to implement the << and >>
operators in a rather complicated manner.

**Nate Eldredge** · Oct 9 '08, 07:35 PM

Re: bits, representations in integers

Eric Sosman <Eric.Sosman@su n.comwrites:

Nate Eldredge wrote:

>Eric Sosman <Eric.Sosman@su n.comwrites:
>>

>>vippstar@gmail. com wrote:
>>>Hello
>>>>
>>>Let's assume CHAR_BIT == 8, sizeof (int) == 4 and INT_MAX == 32767
>>>(that'd mean int has 32 bits, of which only the 15 are value bits)
>>>>
>>>Now, my question is, are the value bits required to be contiguous in
>>>the representation?
>> No. 6.2.6.1: "The representations of all types are unspecified
>>except as stated in this subclause," and the subclause says nothing
>>about how the bits are arranged.

>>
>However, in some ways the compiler has to behave as if they are
>contiguous. For instance, in
>>
>int a,b;
>a=1;
>b = a << 1;
>>
>b must be given the value 2, according to 6.5.7.

>
Yes, b is set to 2. But that's the *value* of b, a quantity
that is deduced from the representation. The representation is
described only by 6.2.6.1, which describes the meanings of various
bits of b but says nothing about how they are arranged. For example,
the 1-bit might be in the lowest-addressed byte of a while the 2-bit
is in the highest-addressed byte of b (that would be perverse, but
not forbidden).
>

>>>Or even the craziest representation such as: (p = padding bits, v =
>>>value bits, s = sign bit)
>>>>
>>>pvpvpvpv pvspvpvp pvpvpvpv pvpvpvpv
>>>>
>>>is allowed?
>> Sure. [...]

>>
>Note in this case the compiler would have to implement the << and >>
>operators in a rather complicated manner.

>
The << and >operators work with the values of their operands,
not with their representations . Yes, the Standard describes the
result values in terms of left and right shifts, but these are
conveniences: the Standard also describes the outcome in terms of
multiplication and division by powers of two.

Yes, we're in agreement. I just thought your post might leave the
reader with a mistaken impression. Someone could think that << and >>
actually shifted the bits of the representation (since in the common
case this is equivalent); in the crazy representation above, that would
mean 1 << 1 == 0. I wanted to clarify that this isn't the case. But
your new post is a better explanation than mine. :)

**CBFalconer** · Oct 10 '08, 12:25 AM

Re: bits, representations in integers

Eric Sosman wrote:

>

.... snip ...

>
Whether this notion is well-supported by the underlying machine
instructions is an issue for the machine designer and the compiler
implementor to wrangle with. The Standard does not forbid
perversity, but requires that the implementation shield the
programmer from much of it. That's good, because it gets the
Standard out of the business of trying to dictate the future of
computer design. When somebody invents the four-state memory
device and encodes two bit values in each "quit," a requirement
that each bit have its own observable existence apart from its
fellows would be an obstacle to adoption.

More interesting will be the revolution that occurs when a good
solution to implementing trinary logic is discovered. Powers of
three forever. I don't think anyone will discover a means of using
2.718281828.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

**Eric Sosman** · Oct 10 '08, 01:25 AM

[OT] Re: bits, representations in integers

CBFalconer wrote:

>
More interesting will be the revolution that occurs when a good
solution to implementing trinary logic is discovered. Powers of
three forever. I don't think anyone will discover a means of using
2.718281828.

C'mon, that's eeeeeeeeasy.

--
Eric Sosman
esosman@ieee-dot-org.invalid

**Dik T. Winter** · Oct 10 '08, 01:45 PM

Re: bits, representations in integers

In article <86bpxtab5p.fsf @vulcan.lanNate Eldredge <nate@vulcan.la nwrites:

Eric Sosman <Eric.Sosman@su n.comwrites:

....

No. 6.2.6.1: "The representations of all types are unspecified
except as stated in this subclause," and the subclause says nothing
about how the bits are arranged.

>
However, in some ways the compiler has to behave as if they are
contiguous. For instance, in
>
int a,b;
a=1;
b = a << 1;
>
b must be given the value 2, according to 6.5.7.

Yes, because the "shift" operator is not defined using shifts but using
values.

pvpvpvpv pvspvpvp pvpvpvpv pvpvpvpv
>
is allowed?

Sure. Note that you cannot "see" the individual bits of a byte
in isolation from the value that they represent. You might be able
to determine by experiment which byte a specified value bit occupies
(though even this much is chancy in the presence of padding bits
whose settings you do not control), but that's about all.

>
Note in this case the compiler would have to implement the << and >>
operators in a rather complicated manner.

Depends. If the hardware represents integers that way, why would it
not provide instructions that provide the "shift" operators?

LHS: definition: shifts the value bits of a word the number of positions.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

**Dik T. Winter** · Oct 10 '08, 01:55 PM

Re: bits, representations in integers

In article <48EEA04D.32BAC FFE@yahoo.comcbfalconer@main eline.net writes:
....

More interesting will be the revolution that occurs when a good
solution to implementing trinary logic is discovered.

I doubt whether a good solution can be found, that is better than the
solution that actually has been used on ternary computers.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

**James Dow Allen** · Oct 11 '08, 05:25 AM

Re: bits, representations in integers

On Oct 10, 7:22 am, CBFalconer <cbfalco...@yah oo.comwrote:

More interesting will be the revolution that occurs when a good
solution to implementing trinary logic is discovered. Powers of
three forever. I don't think anyone will discover a means of using
2.718281828.

Obpuzzle: Describe the simple integer encoding that can
fairly be described as implementing base phi = 1.618...

James Hussein Allen

**Walter Banks** · Oct 11 '08, 12:25 PM

Re: bits, representations in integers

vippstar@gmail. com wrote:

Hello
>
Let's assume CHAR_BIT == 8, sizeof (int) == 4 and INT_MAX == 32767
(that'd mean int has 32 bits, of which only the 15 are value bits)
>
Now, my question is, are the value bits required to be contiguous in
the representation?
Is the position of the signed bit fixed (ie, the last bit, the first
bit)
>
Or even the craziest representation such as: (p = padding bits, v =
value bits, s = sign bit)
>
pvpvpvpv pvspvpvp pvpvpvpv pvpvpvpv
>
is allowed?

We have created some application specific number systems
for our tools that were supported in our C compilers. Almost
all of these schemes traded dynamic range for resolution.
For example 8bit float formats with 4bits mantissa and 4 bits
exponent. 16 bit unsigned float with 5 bits exponent used in
some application.

As others pointed out most of the current hardware
is designed to process binary numbers. Non binary representations
generally have at least one group of math operators that some
implementation difficulties.

Regards,

--
Walter Banks
Byte Craft Limited

http://www.bytecraft.com

**David Given** · Oct 11 '08, 07:55 PM

Re: bits, representations in integers

James Dow Allen wrote:
[...]

Obpuzzle: Describe the simple integer encoding that can
fairly be described as implementing base phi = 1.618...

Do you by any chance mean the A and B paper size series?

ObC: I have an experimental C compiler that, sort of, stores all values
as doubles. sizeof(char) == sizeof(int) == sizeof(double) == 1, and
sizeof(void*) == 2. And it's *completely ANSI C compatible*, subject to
bugs. There's a lot more subtlety to the location of all those pesky
'undefined behaviour' clauses in the standard than one might think at
first glance.

<plugThe compiler, Clue, at http://cluecc.sf.net, compiles C into
Javascript, Lua and Perl. I also have a C and CLisp backend in the
works... </plug>

--
â”Œâ”€â”€â”€ ï½„ï½‡ï¼ ï½ƒï½ï½—ï½Œï½ ï½’ï½‹ï¼Žï½ƒï½ ï½ â”€â”€â”€â”€â”€ http://www.cowlark.com â”€â”€â”€â”€â”€
â”‚
â”‚ âŽ'âŽ•',âˆŠNâ ´âŠ‚Sâ†'â†âŽ• â†(3=T)â‹ŽMâ‹ 2=Tâ†âŠƒ+/(VâŒ½"âŠ‚M),(Vâ Š"M),(V,âŒ½V)â Œ½"(V,Vâ†1âŽº1 )âŠ"âŠ‚M)'
â”‚ --- Conway's Game Of Life, in one line of APL

bits, representations in integers

bits, representations in integers

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment