Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bit shifts on low-level types

10 views
Skip to first unread message

Geoffrey Broadwell

unread,
Feb 27, 2007, 9:01:32 AM2/27/07
to p6l
How are the bitwise shifts defined on low level types? In particular,
for right shift, does high bit extension or zero fill occur? Does the
answer depend on whether the low level type is signed or not?

On the flip side, it seems more useful if we have both operators
available for either signed or unsigned types, to avoid having to do
pointless casting just to change the meaning of +>. Perhaps having both
+> and ?> operators? Since "coerce to boolean and then right shift" is
meaningless, this seems ripe to DWIM. (For me, DWIM here means "+> does
high bit extension, ?> does zero fill".)


-'f


Smylers

unread,
Feb 27, 2007, 1:31:31 PM2/27/07
to perl6-l...@perl.org
Geoffrey Broadwell writes:

> How are the bitwise shifts defined on low level types? In particular,
> for right shift, does high bit extension or zero fill occur? Does the
> answer depend on whether the low level type is signed or not?
>
> On the flip side, it seems more useful if we have both operators

> available ...

Deal with anything as low-level as bits seems to be very rare in Perl 5
programming.

Introducing more operators to the core language, especially terse
punctuationy ones, for something rarely used strikes me as a way of
making the documentation fatter and raising the barrier to entry for
little benefit.

> Perhaps having both +> and ?> operators? Since "coerce to boolean and

> then right shift" is meaningless, ...

It's useless, rather than meaningless; you've neatly defined what the
meaning of that (useless) operator would be.

That is, at the moment there are consistent rules for being able to
correctly guess the meaning of an operator based on knowledge of other
operators. Your suggestion would break that; just because some
combination of symbols doesn't currently have a use doesn't mean that it
makes sense to appropriate them for something else.

> this seems ripe to DWIM.

But "DWIM" is the meaning you previously defined, surely?

> (For me, DWIM here means "+> does high bit extension, ?> does zero
> fill".)

Why? You think that somebody not knowing about this operator would
correctly infer its existence from other operators? Even if somebody
guessed that both operators exist it looks pretty arbitrary which is
which.

For this esoteric sort of stuff can't we have named operators (short
names if you like, perhaps taken from assembly language), in a module
that can be loaded by those who need them?

Smylers

Nicholas Clark

unread,
Feb 27, 2007, 2:08:22 PM2/27/07
to perl6-l...@perl.org
On Tue, Feb 27, 2007 at 06:31:31PM +0000, Smylers wrote:
> Geoffrey Broadwell writes:
>
> > How are the bitwise shifts defined on low level types? In particular,
> > for right shift, does high bit extension or zero fill occur? Does the
> > answer depend on whether the low level type is signed or not?
> >
> > On the flip side, it seems more useful if we have both operators
> > available ...
>
> Deal with anything as low-level as bits seems to be very rare in Perl 5
> programming.

It's one of the things that Perl 5 is bad at. Not beacuse it can't do it,
but because it's terribly terribly slow (compared with C)

You don't want to write a linker in Perl.

> For this esoteric sort of stuff can't we have named operators (short
> names if you like, perhaps taken from assembly language), in a module
> that can be loaded by those who need them?

I think that we can learn from PHP here. :-)

Nicholas Clark

John Macdonald

unread,
Feb 27, 2007, 4:09:27 PM2/27/07
to Smylers, perl6-l...@perl.org
On Tue, Feb 27, 2007 at 06:31:31PM +0000, Smylers wrote:
> Geoffrey Broadwell writes:
>
> > Perhaps having both +> and ?> operators? Since "coerce to boolean and
> > then right shift" is meaningless, ...
>
> It's useless, rather than meaningless; you've neatly defined what the
> meaning of that (useless) operator would be.
>
[ ... ]

>
> > this seems ripe to DWIM.
>
> But "DWIM" is the meaning you previously defined, surely?
>
> > (For me, DWIM here means "+> does high bit extension, ?> does zero
> > fill".)
>
> Why? You think that somebody not knowing about this operator would
> correctly infer its existence from other operators? Even if somebody
> guessed that both operators exist it looks pretty arbitrary which is
> which.

While I tend somewhat to agree that this level of bit
manipulation is not common enough to justify warping the
language; I disagree that the choice of meaning between +>
and ?> is arbitrary and not subject to inference. The normal
assembler opcodes for the two forms of right shift are LRS
(logical right shift) and ARS (arithmetic right shift) with some
variation in spelling for different hardware architectures.
The arithmetic variant propagates the sign bit; the boolean
variant inserts zeros. A "sign bit" is an integer property
that has no meaning in boolean context. It would be hard to
find any rationale for reversing the meaning of the two.

--

0 new messages