I'm not sure what the solution to this is...
If you're shifting left, there's no confusion.
If you're shifting right, do you sign extend?
Perl actually gives you two options - the default uses unsigned integers in C:
$ perl -we '$a = 0xDEADBEEF; $b = $a >> 4; printf "%08X\n%08X\n", $a, $b'
DEADBEEF
0DEADBEE
but in the scope of use integer signed integers are used:
$ perl -we '$a = 0xDEADBEEF; {use integer; $b = $a >> 4} printf "%08X\n%08X\n", $a, $b'
DEADBEEF
FDEADBEE
[Actually, IIRC it's up to the C implementation what it does, but for both
platforms I've just tried one gets the above result]
Clearly, there are times when sign extension is useful (for doing cheap
integer divide by a power of two) and times when it is not (for building
rotate operators from two shifts)
However, currently parrot only has 1 right shift operator:
########################################
=item B<shr>(out INT, in INT, in INT)
=item B<shr>(out PMC, in PMC, in PMC)
Set $1 to the value of $2 shifted right by $3 bits.
=cut
inline op shr(out INT, in INT, in INT) {
$1 = $2 >> $3;
goto NEXT();
}
inline op shr(out PMC, in PMC, in PMC) {
$2->vtable->bitwise_shr(interpreter, $2, $3, $1);
goto NEXT();
}
it's not stated whether it tries to be sign extending, or zero fill, which is
a bad start. However, it would be useful at the INT level to have the choice
of two, because interpreters and code generators will know which would be more
appropriate. Which would mean two ops. But do we really want to add another
entry to the vtable? Or should we add another parameter to the bitwise_shr
entry to say which sort of shift we want?
Or should we just do zero fill, and leave sign extension to the div
operator?
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/
