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

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))) ]

"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.

"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).