NASM does support the << and >> unsigned shift
operators. SF RFE #785327 suggests to add <<<
and >>> for signed shifts.
In addition, <|< and >|> could be added -- to
perform rotates a la ROL and ROR.
Attached find changes and testcases, which may
be helpful.
changes
testcases
Logged In: NO
<<< and >>> are much more frequently used for rotates.
However, there is a major issue with rotates in a language that doesn't have a concept of type sizes.
Logged In: NO
> <<< and >>> are much more frequently used for rotates.
When I researched the matter I noticed that there were
various choices of syntax; however, none of them were
prevalent enough to "suggest a particular preference".
As pointed out when I filed this item, <<< and >>> had
already been picked for unsigned shifts. (I picked them
because NASM's signed shifts have traditionally used <<
and >> -- I like the <</>> versus <<</>>> similarity.)
I ended up with <|< and >|> for the rotates because (a)
it was unlikely that existing code contained those two
sequences in an expression, (b) of all the choices that
I could think of they looked the most pleasing, and (c)
they are easy to type (on the US/English keyboard, you
don't need to let go of the [Shift] key in the process).
In essence, imagine writing down the operand's value on
a strip of paper, and then taping both ends together, to
form a ring, to do the rotate. At that point the | marks
the point where the two ends are taped together... ;-)
> However, there is a major issue with rotates in a language
> that doesn't have a concept of type sizes.
The evaluator of a 32-bit NASM (i.e. pre-0.99) operates
on 32-bit integers, while the evaluator of a 64-bit NASM
(i.e. post-0.98.xx) operates on 64-bit integers. (It may
be wise to explicitly document that, going forward, the
user should not rely on those widths... but then, I don't
see 128-bit integers (and thus expressions) happen soon.
My personal "benchmark" for this is ANSI C -- whenever it
gains support for 128-bit integers types, NASM should.)
Logged In: YES
user_id=58697
Originator: NO
Rotations suck, because they inherently assume a specific number width.
It's better to require the user to use macros with << and >>, that way they have to define the width.
I'm going to close this request as I believe it is undesirable, at least as an operator.
Logged In: YES
user_id=804543
Originator: YES
> Rotations suck, because they inherently
> assume a specific number width.
...which means that they are no different
than the other NASM operators. In fact the
manual says that expressions are evaluated
as 64-bit integers (section 3.5). (In the
past the manual explicitly warned the user
to not assume 32 or 64 bits -- IMO that's
great... in theory... but in practice most
code ends up making assumptions.)
Btw, the attached testcases file provides
macros; however, since NASM lacks the %^
functionality (SF #950642), nesting won't
work.