C++ Logo

std-discussion

Advanced search

Re: Setting wording for bit manipulation for non-binary hardware

From: Lénárd Szolnoki <cpp_at_[hidden]>
Date: Sun, 7 Mar 2021 17:09:06 +0000
On Sun, 07 Mar 2021 18:52:26 +0300
Andrey Semashev via Std-Discussion <std-discussion_at_[hidden]>
wrote:

> On March 7, 2021 6:26:41 PM Jason McKesson via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
>
> > On Sun, Mar 7, 2021 at 4:14 AM Andrey Semashev via Std-Discussion
> > <std-discussion_at_[hidden]> wrote:
> >>
> >> 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.
> >
> > Bitwise operations on signed integers, pre-twos complement, were
> > defined so long as the source integers were positive and the
> > resulting value could be stored in a signed integer of that type.
> >
> > Also, don't forget that a specification describes behavior, not
> > implementation.
>
> Sure, my point is that the specification describes behavior in terms
> of bit representation. The effect on the value is the consequence.
>
> You could rewrite the spec to define behavior in terms of integer
> values, but that would be useless for the binary world, and it's not
> clear how useful that would be for platforms of different bases.
>

The standard already describes behavior in terms of values, not bit
representation. Value representation of integers are not even specified
outside of intN_t/uintN_t, so it can't be specified based on that.

http://eel.is/c++draft/expr.shift#2

http://eel.is/c++draft/expr.shift#3

Cheers,
Lénárd Szolnoki

Received on 2021-03-07 11:09:13