> Rotates on bools are meaningless (nothing happens), ints rotate at 32
> or 64 bits depending on the native word size
First: we don't have any rotate vtables or opcodes. Shall these be
considered as a TODO?
> ... (and yeah, I know this
> is going to be an issue), and bignums rotate assuming they're binary
> numbers some multiple of 8 bits (minimum 64 bits).
And that as well as the above int rotate seems to make these operations
rather arbitrary. What about:
rotl Pdest, Psrc, 32 # rotate left by 1 32-bitwise
rotr Pdest, Psrc, 64 # rotate right by 1 64-bitwise, expand if needed
or/and:
rotl Pdest, Psrc, n, 32 # rotate left by n 32-bitwise
rotl Pdest, n, 32 # rotate left in place by n 32-bitwise
leo
Yes. It's been floating around but never did get formally added.
> > ... (and yeah, I know this
>> is going to be an issue), and bignums rotate assuming they're binary
>> numbers some multiple of 8 bits (minimum 64 bits).
>
>And that as well as the above int rotate seems to make these operations
>rather arbitrary.
Yep. That got hashed out later in the thread, for the most part. But...
> What about:
>
> rotl Pdest, Psrc, 32 # rotate left by 1 32-bitwise
> rotr Pdest, Psrc, 64 # rotate right by 1 64-bitwise, expand if needed
>
>or/and:
>
> rotl Pdest, Psrc, n, 32 # rotate left by n 32-bitwise
> rotl Pdest, n, 32 # rotate left in place by n 32-bitwise
These have merit. The only question then is what happens with the
rest of the bits. (If one rotates a 64 bit quantity with a 32-bit
rotate)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
>>First: we don't have any rotate vtables or opcodes. Shall these be
>>considered as a TODO?
> Yes. It's been floating around but never did get formally added.
Ok. Takers wanted.
>> rotl Pdest, n, 32 # rotate left in place by n 32-bitwise
> These have merit. The only question then is what happens with the
> rest of the bits. (If one rotates a 64 bit quantity with a 32-bit
> rotate)
First, we should probably ask HLL designers. I can imagine two options:
1) rotate whatever is there - don't care about higher bits
2) if higher bits are non-zero, throw an exception
context->errors can hold a bit to turn on/off 2)
leo
> fixed sizes of integer, so I'd aim some ops at low-level types of
> known size and leave it at that.
Quite a while back, I did add a few opcodes for fixed size integer operations
for Parrot .. But they were added for a totally different HLL :)
> matter what you do with the high bits. I suppose another way to
> look at it is that they'll just want ops that'll JIT well, which
> usually means to make the ops work on the natural datatype sizes
> of the machine. But that fights against the fact that most crypto
> algorithms do their commutations based on a known number of bits.
Maybe the dotgnu.ops needs to be renamed as fixedsize.ops and add
a few more fixed size int operations ?. int , uint, long and ulong should
suffice for most crypto folks , but those ops are not JIT'd AFAIK.
Gopal
Leopold Toetsch wrote:
> Dan Sugalski <d...@sidhe.org> wrote:
>>> rotl Pdest, n, 32 # rotate left in place by n 32-bitwise
>
>>These have merit. The only question then is what happens with the
>>rest of the bits. (If one rotates a 64 bit quantity with a 32-bit
>>rotate)
>
>
> First, we should probably ask HLL designers. I can imagine two options:
> 1) rotate whatever is there - don't care about higher bits
> 2) if higher bits are non-zero, throw an exception
>
> context->errors can hold a bit to turn on/off 2)
How about a context->freakish that would allow
rotl Pdest, n, 5 # rotate 5 lowest ordered bits leaving
# the others untouched
rotl Pdest, n, 5, 6 # skip 6 lowest order bits, rotating
# next 5 lowest ordered bits, leaving
# the others untouched
I'd offer a practical justification, but I have none. It just feels
cool and still allows for optimizing the real world cases.
Dan
> How about a context->freakish that would allow
> rotl Pdest, n, 5 # rotate 5 lowest ordered bits leaving
overkill probably. By 8, 16, 32, 64 ought do it. And that looks too
much.
leo
Yeah. Larry's note about the limited utility of this is a point well taken too.
I think a simple:
rot[lr] dest, num_rotates, bits_to_rotate
with 0 in bits_to_rotate meaning "all of them", and unrotated bits
getting masked to 0 is fine.