• Mac Reiter (34/34) Aug 19 2002 I was wondering if anyone else thought a rotate operator would be worth ...
• Russ Lewis (11/45) Aug 19 2002 Seems to me that this would be a good function for a standard library. ...
• Walter (8/13) Aug 19 2002 The
• Walter (13/24) Aug 19 2002 the

Mac Reiter <Mac_member pathlink.com> writes:

I was wondering if anyone else thought a rotate operator would be worth the
effort of adding to D.  You don't need them very often, usually only for
hashing, random number generation, encryption, or similar things, but generally
when you do need them you need to be able to do them very quickly.  Speed of
working with encryption code can directly impact connection and communication
times.  Speed of random number generation can directly influence things like
game performance ("random", but consistent, landscapes based on hashes of world
coordinates).  This leads many programmers to resort to inline assembly.

People like me, who tend to avoid assembly as long as possible, resort to taking
the mod of the rotation distance, making a copy of the original variable,
shifting one variable up, one variable down, masking off the irrelevant bits (if
masking is needed), and or'ing the two variables back together.  While logically
correct, I assume that it is considerably slower than a built-in rotate opcode
would be.  The modulus division alone can consume a fair chunk of time.

I also realize that not all CPUs have a rotate instruction, which would add to
the complexity of the D compiler when it is ported to other architectures.
However, I don't think the extra set of code is horribly difficult to get right
(please correct me if I am mistaken in this belief), and the capability is not
easy to add from user land.  An inline assembly solution is not portable at all,
and since the desired operation is logical rather than hardware oriented, it
would be very nice if it was as portable as possible.  The compiler would be
able to generate the optimal code to accomplish the task for whichever
architecture it was written on.

I'm not sure what you would use for the operator...  Maybe <|< and >|> ?  I
don't really know how to suggest the "rolls around to the other end" nature of
the rotate operation...

On an unrelated note, I wanted to say that I really like the ability to treat
arrays as first class variables (int[] a, b; ...; a += b;).  By letting the
programmer specify operations at this higher level of abstraction, the compiler
can eventually (and may already) turn such operations into MMX, 3Dnow!, or SSE2
instructions.  Fortran is easier to parallelize than C/C++ because of this
higher level of representation, and Walter has wisely given it to those of us
who love our C syntax...  Thanks!

Mac

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

Seems to me that this would be a good function for a standard library.  The
implementation would be inline assembly, but you wouldn't have to see that. 
(Yes,
it's not portable...but many functions in a standard library won't be, anyway,
since
they have to make system calls...)

IMHO, rotate isn't a common enough instruction to require its own operator.

Mac Reiter wrote:

 I was wondering if anyone else thought a rotate operator would be worth the
 effort of adding to D.  You don't need them very often, usually only for
 hashing, random number generation, encryption, or similar things, but generally
 when you do need them you need to be able to do them very quickly.  Speed of
 working with encryption code can directly impact connection and communication
 times.  Speed of random number generation can directly influence things like
 game performance ("random", but consistent, landscapes based on hashes of world
 coordinates).  This leads many programmers to resort to inline assembly.

 People like me, who tend to avoid assembly as long as possible, resort to
taking
 the mod of the rotation distance, making a copy of the original variable,
 shifting one variable up, one variable down, masking off the irrelevant bits
(if
 masking is needed), and or'ing the two variables back together.  While
logically
 correct, I assume that it is considerably slower than a built-in rotate opcode
 would be.  The modulus division alone can consume a fair chunk of time.

 I also realize that not all CPUs have a rotate instruction, which would add to
 the complexity of the D compiler when it is ported to other architectures.
 However, I don't think the extra set of code is horribly difficult to get right
 (please correct me if I am mistaken in this belief), and the capability is not
 easy to add from user land.  An inline assembly solution is not portable at
all,
 and since the desired operation is logical rather than hardware oriented, it
 would be very nice if it was as portable as possible.  The compiler would be
 able to generate the optimal code to accomplish the task for whichever
 architecture it was written on.

 I'm not sure what you would use for the operator...  Maybe <|< and >|> ?  I
 don't really know how to suggest the "rolls around to the other end" nature of
 the rotate operation...

 On an unrelated note, I wanted to say that I really like the ability to treat
 arrays as first class variables (int[] a, b; ...; a += b;).  By letting the
 programmer specify operations at this higher level of abstraction, the compiler
 can eventually (and may already) turn such operations into MMX, 3Dnow!, or SSE2
 instructions.  Fortran is easier to parallelize than C/C++ because of this
 higher level of representation, and Walter has wisely given it to those of us
 who love our C syntax...  Thanks!

 Mac

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Walter" <walter digitalmars.com> writes:

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D6112AB.C6FF2603 deming-os.org...
 Seems to me that this would be a good function for a standard library.

The
 implementation would be inline assembly, but you wouldn't have to see

that.  (Yes,
 it's not portable...but many functions in a standard library won't be,

anyway, since
 they have to make system calls...)

 IMHO, rotate isn't a common enough instruction to require its own

operator.

Right, that's why an intrinsic function fits the bill perfectly (just like
math.sin() is intrinsic).

"Walter" <walter digitalmars.com> writes:

"Mac Reiter" <Mac_member pathlink.com> wrote in message
news:ajr3c5$140n$1 digitaldaemon.com...
 I was wondering if anyone else thought a rotate operator would be worth

the
 effort of adding to D.  You don't need them very often, usually only for
 hashing, random number generation, encryption, or similar things, but

generally
 when you do need them you need to be able to do them very quickly.

I agree. I intend to add them in as "intrinsic" functions, not as an
operator.

 On an unrelated note, I wanted to say that I really like the ability to

treat
 arrays as first class variables (int[] a, b; ...; a += b;).  By letting

the
 programmer specify operations at this higher level of abstraction, the

compiler
 can eventually (and may already) turn such operations into MMX, 3Dnow!, or

SSE2
 instructions.  Fortran is easier to parallelize than C/C++ because of this
 higher level of representation, and Walter has wisely given it to those of

us
 who love our C syntax...  Thanks!

Yes, a good D implementation should be able to provide even better array
handling than FORTRAN with far less effort.