Date: Sun, 7 Mar 2021 12:13:54 +0300

On 3/6/21 10:34 PM, Jason McKesson via Std-Discussion wrote:

> On Sat, Mar 6, 2021 at 12:55 PM Vishal Oza via Std-Discussion

> <std-discussion_at_[hidden]> wrote:

>>

>> I was thinking of making the bit and bitset libraries as well bit manipulation operators with the exception of endian and possibly left and right bitshift to undefined behavior if the base is not 2 in hardware.

>

> Um, what exactly does that mean?

>

> Here's what I mean. If you have the number 15, and you do a

> binary-left-shift it by 2, the number you get is 30. It *does not

> matter* how the hardware implements this. So long as `30 == 15 << 2`

> is true, the implementation is doing its job.

>

> Similarly, if you have the number 15, and you do a bitwise-and with 2,

> you get the number 13. Again, how the hardware does this is

> irrelevant; the implementation's job is to make the math work out.

Bit manipulation operators affect bit representation of a number, the

resulting value is a consequence of that. In that sense, before we

mandated two's complement representation, applying bit operators to

signed integers would yield implementation-dependent numbers, although

the effect on bit representation (with some restrictions) was well defined.

When the "bit" is not binary, the translation from "bit" representation

to number is, again, different. Arguably, bit manipulation would have to

operate on those non-binary "bits" still, or become unapplicable and

removed (e.g. bitwise AND/OR/XOR/NOT operators), but their result would

translate to different numbers than on a binary machine.

IMHO, too much of the standard C/C++ will have to be thrown out by this.

Todays software at all levels relies heavily on binary representations,

including standards like POSIX (think of various flags in any API). Most

communication protocols, including IP, are also built around binary

representation. My suggestion to the OP is, unless this is a purely

academic interest, think of designing a co-processor or accelerator that

runs alongside the traditional binary CPU. That way you would be able to

develop your own language (which could be a cut down and adapted version

of C++) for the programs for the co-processor while still benefitting

from the existing infrastructure running on the traditional CPU.

> On Sat, Mar 6, 2021 at 12:55 PM Vishal Oza via Std-Discussion

> <std-discussion_at_[hidden]> wrote:

>>

>> I was thinking of making the bit and bitset libraries as well bit manipulation operators with the exception of endian and possibly left and right bitshift to undefined behavior if the base is not 2 in hardware.

>

> Um, what exactly does that mean?

>

> Here's what I mean. If you have the number 15, and you do a

> binary-left-shift it by 2, the number you get is 30. It *does not

> matter* how the hardware implements this. So long as `30 == 15 << 2`

> is true, the implementation is doing its job.

>

> Similarly, if you have the number 15, and you do a bitwise-and with 2,

> you get the number 13. Again, how the hardware does this is

> irrelevant; the implementation's job is to make the math work out.

Bit manipulation operators affect bit representation of a number, the

resulting value is a consequence of that. In that sense, before we

mandated two's complement representation, applying bit operators to

signed integers would yield implementation-dependent numbers, although

the effect on bit representation (with some restrictions) was well defined.

When the "bit" is not binary, the translation from "bit" representation

to number is, again, different. Arguably, bit manipulation would have to

operate on those non-binary "bits" still, or become unapplicable and

removed (e.g. bitwise AND/OR/XOR/NOT operators), but their result would

translate to different numbers than on a binary machine.

IMHO, too much of the standard C/C++ will have to be thrown out by this.

Todays software at all levels relies heavily on binary representations,

including standards like POSIX (think of various flags in any API). Most

communication protocols, including IP, are also built around binary

representation. My suggestion to the OP is, unless this is a purely

academic interest, think of designing a co-processor or accelerator that

runs alongside the traditional binary CPU. That way you would be able to

develop your own language (which could be a cut down and adapted version

of C++) for the programs for the co-processor while still benefitting

from the existing infrastructure running on the traditional CPU.

Received on 2021-03-07 03:13:59