www.digitalmars.com         C & C++   DMDScript  

D - Rotation operator proposal

reply Ziemowit Zglinski <Ziemowit_member pathlink.com> writes:
While programming a lot of embedded application, I often miss a rotation
operator in almost all programming languages. This operation  is implemented in
all processor architectures and still difficult to achieve from a high level
language.

Taking opportunity of not yet fully defined language, I propose to add two
rotation operators to the language definition:
Rotate right -  >  or  >>
Rotate left  - <   or << 

The behaviour should be analogue to the logical shift operators, except the bit
shifted out would be shift in on the opposite side in place of 0. Number bits
rotated should correspond to the length of the actual data type.

Thank You,

--  Ziemowit

    ziemek tera.com.pl
Mar 13 2003
next sibling parent "Achillefs Margaritis" <axilmar b-online.gr> writes:
I would prefer the following operators:

rotate right = |>>
rotate left = <<|

since '>>' means shift and '|' means or, it makes more sense to shift bits
and then or them at the opposite end.


"Ziemowit Zglinski" <Ziemowit_member pathlink.com> wrote in message
news:b4pt22$gg1$1 digitaldaemon.com...

 While programming a lot of embedded application, I often miss a rotation
 operator in almost all programming languages. This operation  is


implemented in

 all processor architectures and still difficult to achieve from a high


level

 language.

 Taking opportunity of not yet fully defined language, I propose to add two
 rotation operators to the language definition:
 Rotate right -  >  or  >>
 Rotate left  - <   or << 

 The behaviour should be analogue to the logical shift operators, except


the bit

 shifted out would be shift in on the opposite side in place of 0. Number


bits

 rotated should correspond to the length of the actual data type.

 Thank You,

 --  Ziemowit

     ziemek tera.com.pl
Mar 13 2003
prev sibling next sibling parent reply Ilya Minkov <midiclub tiscali.de> writes:
I like the idea. It's like a simple small thing and useful which was 
missing from C. It goes into the same cthegory as BSF and BSR, which 
have been made standard already (as intrinsics or in library).

Nontheless, it might be against D's philosophy that algorithms should 
work independant of data width. Though i don't see much of a problem 
since there's a size property.

The tokens could just as well be  <|  and |> or something like that.

-i.

Ziemowit Zglinski wrote:

 While programming a lot of embedded application, I often miss a rotation
 operator in almost all programming languages. This operation  is implemented in
 all processor architectures and still difficult to achieve from a high level
 language.
 
 Taking opportunity of not yet fully defined language, I propose to add two
 rotation operators to the language definition:
 Rotate right -  >  or  >>
 Rotate left  - <   or << 
 
 The behaviour should be analogue to the logical shift operators, except the bit
 shifted out would be shift in on the opposite side in place of 0. Number bits
 rotated should correspond to the length of the actual data type.
 
 Thank You,
 
 --  Ziemowit
 
     ziemek tera.com.pl
Mar 13 2003
parent reply Ziemowit Zglinski <Ziemowit_member pathlink.com> writes:
The operators  > and <  for rotation I saw in a script language,
so perhaps it would be wise to reuse them. 

Another plus is, that you can SEE the rotation :-)

But really important is the availability of the operator and not the look...

--  Ziemowit

ziemek tera.com.pl

In article <b4puq9$hfu$1 digitaldaemon.com>, Ilya Minkov says...

I like the idea. It's like a simple small thing and useful which was 
missing from C. It goes into the same cthegory as BSF and BSR, which 
have been made standard already (as intrinsics or in library).

Nontheless, it might be against D's philosophy that algorithms should 
work independant of data width. Though i don't see much of a problem 
since there's a size property.

The tokens could just as well be  <|  and |> or something like that.

-i.

Ziemowit Zglinski wrote:

 While programming a lot of embedded application, I often miss a rotation
 operator in almost all programming languages. This operation  is implemented in
 all processor architectures and still difficult to achieve from a high level
 language.
 
 Taking opportunity of not yet fully defined language, I propose to add two
 rotation operators to the language definition:
 Rotate right -  >  or  >>
 Rotate left  - <   or << 
 
 The behaviour should be analogue to the logical shift operators, except the bit
 shifted out would be shift in on the opposite side in place of 0. Number bits
 rotated should correspond to the length of the actual data type.
 
 Thank You,
 
 --  Ziemowit
 
     ziemek tera.com.pl
Mar 13 2003
parent reply Bill Cox <bill viasic.com> writes:
I'm not opposed to the idea, since it can lead to more efficient code. 
If D adds rotation operations, I'd also like access to the carry flag.

Bill

Ziemowit Zglinski wrote:

 The operators  > and <  for rotation I saw in a script language,
 so perhaps it would be wise to reuse them. 
 
 Another plus is, that you can SEE the rotation :-)
 
 But really important is the availability of the operator and not the look...
 
 --  Ziemowit
 
 ziemek tera.com.pl
 
 In article <b4puq9$hfu$1 digitaldaemon.com>, Ilya Minkov says...
 

I like the idea. It's like a simple small thing and useful which was 
missing from C. It goes into the same cthegory as BSF and BSR, which 
have been made standard already (as intrinsics or in library).

Nontheless, it might be against D's philosophy that algorithms should 
work independant of data width. Though i don't see much of a problem 
since there's a size property.

The tokens could just as well be  <|  and |> or something like that.

-i.

Ziemowit Zglinski wrote:


While programming a lot of embedded application, I often miss a rotation
operator in almost all programming languages. This operation  is implemented in
all processor architectures and still difficult to achieve from a high level
language.

Taking opportunity of not yet fully defined language, I propose to add two
rotation operators to the language definition:
Rotate right -  >  or  >>
Rotate left  - <   or << 

The behaviour should be analogue to the logical shift operators, except the bit
shifted out would be shift in on the opposite side in place of 0. Number bits
rotated should correspond to the length of the actual data type.

Thank You,

--  Ziemowit

    ziemek tera.com.pl
Mar 13 2003
parent reply "Sean L. Palmer" <seanpalmer directvinternet.com> writes:
The carry flag is not nearly as portable.  Some architectures might not need
one.  I don't know of any such processors, but maybe some embedded system?

But I can't count the number of times I had to write my own rotate operator
in C:

#ifdef _MSC_VER

#include <whatever.h>
uint rotateleft(uint x, int bits) { return __lrotl(x,bits); }

#elif defined(_MIPS_R3000X)

uint rotateleft(uint x, int bits) { asm { "rol blah2,blah1,bits" : "=r
blah2" (x) : "r blah1" (x), "r bits" (bits) }; }

#else

uint rotateleft(uint x, int bits) { return (x << bits) | (x >>
(sizeof(x)*8-bits)); }

#endif

Gets even crazier if you're dealing with signed types.  I hate having to
bend over backward to get at some low level basic functionality that almost
all machines have.

Isn't this what high level languages were supposed to be for, to make
programs more portable, to keep us from having to worry about piddly machine
architecture differences? No, we still have to know about them but now we
can't do anything about it directly.

BSF/BSR sound mighty useful for doing bit array work or figuring out which
power of two to use for textures.

Any of this can be emulated if the target processor doesn't have it.  It's a
question of whether the functionality is useful enough to warrant inclusion.

Chances are that if there is a machine instruction on some chip somewhere,
that the functionality the instruction has IS considered useful to a fairly
large and intelligent group of people.  If enough processors have it, I
can't see why it can't be part of the language or at very least the RTL.

Sean

"Bill Cox" <bill viasic.com> wrote in message
news:3E709A01.8070804 viasic.com...

 I'm not opposed to the idea, since it can lead to more efficient code.
 If D adds rotation operations, I'd also like access to the carry flag.

 Bill
Mar 13 2003
next sibling parent Bill Cox <bill viasic.com> writes:
Sean L. Palmer wrote:

 The carry flag is not nearly as portable.  Some architectures might not need
 one.  I don't know of any such processors, but maybe some embedded system?


I'm not familiar with any CPUs or MCUs without a carry.  Also, the 
compiler could easily emulate it.  I think a bigger problem is how to 
cleanly integrate it into the langauge.  Perl would probably do it with 
a system-wide global variable.  Yuk.  Certainly the rotation operators 
integrate smoothly.

Bill
Mar 13 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b4qk0p$12c6$1 digitaldaemon.com...

 BSF/BSR sound mighty useful for doing bit array work or figuring out which
 power of two to use for textures.


bsf and bsr are implemented as compiler intrisics, see phobos\intrinsic.d
Mar 31 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Excellent!  Thank you, Walter.

Can I add a few instrinsics to the wish list?

rol
ror
fsincos

You obviously know about rol and ror.  C has non-ansi-standard __lrotl and
__lrotr (Microsoft libraries) but hopefully D will have standard intrinsics
for this basic op.  The only drag is that for it to be useful you need to
know the size of the int type exactly.

fsincos is apparently a x87-only feature (haven't seen it on any other
processor yet) but it seems to be the nature of math that if you need either
sin or cos, you will likely need the other as well, for the same angle.  It
makes sense for a coprocessor to compute them both at once much as it makes
sense to do integer div and mod at the same time.  There is considerable
work that doesn't need to be done twice.

Speaking of which, ldiv is a C library function which would be better off
being an intrinsic.  Maybe you already do this for DMC.

A throwback to the old fixed point days:  muldiv  (do an integer multiply
followed by an integer divide, without risk of overflow in the intermediate
result, though the final result may well still overflow).

I'm presuming that min, max, and swap will be templatized library functions,
not intrinsics, but I consider those to be basic requirements.  Currently
swap seems tied up in the TypeInfo's, and min and max (thank heavens!) are
there in Phobos, but only defined for a few types.  Very nice are the
inclusion of min and max for arrays!!  Extremely nice is the inclusion of
sum() for arrays! With that and the upcoming support for componentwise
multiplication of arrays, I can express dot product very tidily, if not
necessarily efficiently for fixed-size vectors:  sum(a[] * b[]) which would
obviously be able to be far more efficient if the size of a and b are known
at compile time.

I wonder if the compiler will be able to optimize this initialization to
zero away in real sum(real n[])?

 real result = 0;
 for (uint i = 0; i < n.length; i++)
      result += n[i];
 return result;

could be transformed into:

real result;
if (!n.length)
    result = 0;
else
{
    result = n[0];
    for (uint i = 1; i < n.length; ++i)
        result += n[i];
}
return result;

Doesn't look faster, but if you know at compile time that your array is not
zero-length, it does become faster.

Don't ya just love the basics?

Pssst... you keep putting off array component operations.  We could provide
them ourselves with templates and free operator overloading, though we'd
never be able to make it SIMD'able.  If you see SIMD support in D's future,
language support for array ops is the way to go.  If not, free operators
would get us part way there today.

I seem to have wandered off-topic.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:b6b2an$1j2a$1 digitaldaemon.com...

 "Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
 news:b4qk0p$12c6$1 digitaldaemon.com...

 BSF/BSR sound mighty useful for doing bit array work or figuring out




which

 power of two to use for textures.


 bsf and bsr are implemented as compiler intrisics, see phobos\intrinsic.d
Apr 01 2003
next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Sean L. Palmer wrote:

 Pssst... you keep putting off array component operations.  We could provide
 them ourselves with templates and free operator overloading, though we'd
 never be able to make it SIMD'able.  If you see SIMD support in D's future,
 language support for array ops is the way to go.  If not, free operators
 would get us part way there today.


I sent Walter code for doing array arithmetic two months ago that 
supported MMX and 3DNow!.  I'm using an Athlon so I don't have SSE2. 
MMX in 8-bit was 106% faster on average.  MMX in 16-bit was 56% faster 
on average.  The 3DNow! code for 32-bit float was 54% faster on average.
Apr 01 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Send me the interface, I'll code up SSE for it pronto!  Walter, Burton, what
assembler do you want to use?  Or are you emitting binary opcodes directly?

Crap I don't have Linux installed, so it may be hard to test.  I'll port any
straight asm or C you give me to SSE though.

I haven't done any SSE2 yet but it's pretty much the same thing.  There's
some nicer convenience ops in SSE2, otherwise it's mostly just the same
thing but with doubles.  I have a P4 so I could try that too.

MMX is kinda PITA because you have to kick the cpu into that mode, which
shadows MMX registers atop the normal FPU registers;  thus you can't easily
combine MMX and FPU ops.  Oh well.  Should be using MMX with SSE instead,
most of the time.

I thought the Athlon had basic support for SSE emulation?

Sean

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:b6c4t1$29od$1 digitaldaemon.com...

 Sean L. Palmer wrote:

 Pssst... you keep putting off array component operations.  We could




provide

 them ourselves with templates and free operator overloading, though we'd
 never be able to make it SIMD'able.  If you see SIMD support in D's




future,

 language support for array ops is the way to go.  If not, free operators
 would get us part way there today.


 I sent Walter code for doing array arithmetic two months ago that
 supported MMX and 3DNow!.  I'm using an Athlon so I don't have SSE2.
 MMX in 8-bit was 106% faster on average.  MMX in 16-bit was 56% faster
 on average.  The 3DNow! code for 32-bit float was 54% faster on average.
Apr 01 2003
next sibling parent Charles Banas <greywolf greyfade.net> writes:
On Tue, 1 Apr 2003 10:12:06 -0800, Sean L. Palmer <palmer.sean verizon.net> 
wrote:


 I haven't done any SSE2 yet but it's pretty much the same thing.  There's
 some nicer convenience ops in SSE2, otherwise it's mostly just the same
 thing but with doubles.  I have a P4 so I could try that too.


just out of curiosity, what do you know about the 13 new instructions?  i 
read some of the documentation, but it seemed like so much uselss fluff.


 MMX is kinda PITA because you have to kick the cpu into that mode, which
 shadows MMX registers atop the normal FPU registers;  thus you can't 
 easily
 combine MMX and FPU ops.  Oh well.  Should be using MMX with SSE instead,
 most of the time.


it's a shame Intel didn't spemd more time on it, eh?


 I thought the Athlon had basic support for SSE emulation?


the Athlon XP does.  i'm assuming Mr. Radons has an old Thunderbird core or 
similar.  anything before the Athlon XP doesn't have SSE.  the most recent 
XP and MP cores, OTOH, have full SSE2 support (not including the new 13 
instructions, of course).


 Sean


-- 
Charles "grey wolf" Banas
Apr 01 2003
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Sean L. Palmer wrote:

 Send me the interface, I'll code up SSE for it pronto!  Walter, Burton, what
 assembler do you want to use?  Or are you emitting binary opcodes directly?


Err, I used templating and DMD's inline assembler.  I'll send it to you 
in a minute.
Apr 02 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Sounds good.

DMD inline asm wouldn't by any chance support the P4 opcodes would it?  I
can do it the hard way if I have to.

Hopefully I won't have to do this sort of coding much in the future;  this
is definitely stuff that belongs inside the compiler.

Sean

"Burton Radons" <loth users.sourceforge.net> wrote in message
news:b6g2en$28jo$1 digitaldaemon.com...

 Sean L. Palmer wrote:

 Send me the interface, I'll code up SSE for it pronto!  Walter, Burton,




what

 assembler do you want to use?  Or are you emitting binary opcodes




directly?

 Err, I used templating and DMD's inline assembler.  I'll send it to you
 in a minute.
Apr 02 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:b6gfj1$2h9u$1 digitaldaemon.com...

 DMD inline asm wouldn't by any chance support the P4 opcodes would it?  I
 can do it the hard way if I have to.


The DMD inline assembler supports *all* the x86 opcodes, including the AMD
3d!now ones.
Apr 24 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
I recently found this out firsthand.  Sweet!

Sean

"Walter" <walter digitalmars.com> wrote in message
news:b8aeqr$2s7b$2 digitaldaemon.com...

 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:b6gfj1$2h9u$1 digitaldaemon.com...

 DMD inline asm wouldn't by any chance support the P4 opcodes would it?




I

 can do it the hard way if I have to.


 The DMD inline assembler supports *all* the x86 opcodes, including the AMD
 3d!now ones.
Apr 25 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:b6bhbj$1tf2$1 digitaldaemon.com...

 Excellent!  Thank you, Walter.

 Can I add a few instrinsics to the wish list?

 rol
 ror
 fsincos

 You obviously know about rol and ror.  C has non-ansi-standard __lrotl and
 __lrotr (Microsoft libraries) but hopefully D will have standard


intrinsics

 for this basic op.  The only drag is that for it to be useful you need to
 know the size of the int type exactly.


I haven't because I never know what to do with rcl and rcr <g>.



 fsincos is apparently a x87-only feature (haven't seen it on any other
 processor yet) but it seems to be the nature of math that if you need


either

 sin or cos, you will likely need the other as well, for the same angle.


It

 makes sense for a coprocessor to compute them both at once much as it


makes

 sense to do integer div and mod at the same time.  There is considerable
 work that doesn't need to be done twice.


I think a better approach is for the compiler to recognize that both sin()
and cos() are being done on the same argument, and internally convert it to
fsincos.



 Speaking of which, ldiv is a C library function which would be better off
 being an intrinsic.  Maybe you already do this for DMC.


No, I haven't.


 Don't ya just love the basics?


Doing the basics well pays endless dividends.


 Pssst... you keep putting off array component operations.  We could


provide

 them ourselves with templates and free operator overloading, though we'd
 never be able to make it SIMD'able.  If you see SIMD support in D's


future,

 language support for array ops is the way to go.  If not, free operators
 would get us part way there today.


Right now, getting the basic system working on linux is my priority. I'm
currently studying the pthreads manual.
Apr 24 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:b8aeqr$2s7b$1 digitaldaemon.com...

 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:b6bhbj$1tf2$1 digitaldaemon.com...

 You obviously know about rol and ror.  C has non-ansi-standard __lrotl




and

 __lrotr (Microsoft libraries) but hopefully D will have standard


 intrinsics

 for this basic op.  The only drag is that for it to be useful you need




to

 know the size of the int type exactly.


 I haven't because I never know what to do with rcl and rcr <g>.


D has no concept of carry, so obviously those two aren't going to fit well.
I don't think the carry bit is appropriate domain for a high-level language
to deal with.  Not terribly portable.


 fsincos is apparently a x87-only feature (haven't seen it on any other
 processor yet) but it seems to be the nature of math that if you need


 either

 sin or cos, you will likely need the other as well, for the same angle.


 It

 makes sense for a coprocessor to compute them both at once much as it


 makes

 sense to do integer div and mod at the same time.  There is considerable
 work that doesn't need to be done twice.


 I think a better approach is for the compiler to recognize that both sin()
 and cos() are being done on the same argument, and internally convert it


to

 fsincos.


That'd be a fine solution.


 Don't ya just love the basics?


 Doing the basics well pays endless dividends.


Agreed.  We sure appreciate it.


 Right now, getting the basic system working on linux is my priority. I'm
 currently studying the pthreads manual.


Ahhh... pthreads.  I wrapped that once and never had occasion to use it.

Linux seems to be a big issue.  It's definitely worth doing, because it will
bring in some talented Unix people who may be willing to contribute time
and/or code to the D effort.

Sean
Apr 25 2003
parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:b8as8s$3nh$1 digitaldaemon.com...

 Linux seems to be a big issue.  It's definitely worth doing, because it


will

 bring in some talented Unix people who may be willing to contribute time
 and/or code to the D effort.


I suspect it may double or triple the D user base, as linux seems to have
attracted the people who write code for fun and the early adopters.
Apr 25 2003
prev sibling parent reply "Ben Woodhead" <zander echotech.ca> writes:
I hate to ask, but what is a rotation operator, or what is it for..

Thanks Ben
"Ziemowit Zglinski" <Ziemowit_member pathlink.com> wrote in message
news:b4pt22$gg1$1 digitaldaemon.com...

 While programming a lot of embedded application, I often miss a rotation
 operator in almost all programming languages. This operation  is


implemented in

 all processor architectures and still difficult to achieve from a high


level

 language.

 Taking opportunity of not yet fully defined language, I propose to add two
 rotation operators to the language definition:
 Rotate right -  >  or  >>
 Rotate left  - <   or << 

 The behaviour should be analogue to the logical shift operators, except


the bit

 shifted out would be shift in on the opposite side in place of 0. Number


bits

 rotated should correspond to the length of the actual data type.

 Thank You,

 --  Ziemowit

     ziemek tera.com.pl
Mar 13 2003
next sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Ben Woodhead" <zander echotech.ca> wrote in message
news:b4qoiq$16b5$1 digitaldaemon.com...

 I hate to ask, but what is a rotation operator, or what is it for..


a = (b<<c)|(b>>>-c);

:)

it rotates the bits as if they where on a cylinder, rather than shifting
them
its use in almost all symetric cipher code (I know idea does not)
64 bit rotate of 2 32 bit values along with 32 x32 => 64 bit multiply are
also useful when doing fixed point maths.
be I think they should be intrinsics. no more operators, >> and >>> are o.k.
but !<> and all those float comparisons confuse the hell out of me, I
understand why but why !!
Mar 13 2003
prev sibling parent reply Jonathan Andrew <Jonathan_member pathlink.com> writes:
The rotation operator (at least as I've used it) shifts bits around in a 
value, so if you had a value

11110000, 

and rotated it left two positions, you would have

11000011, the bits just get shifted over left two positions, with the 
ones on the left coming back around to the right. As far as I know, its
mostly used for encryption, and multiplication and division within processors
use rotation (shifts, anyway) for faster operation.

Even small microcontrollers like the HC11 have this capability built in
to the machine code, so I don't see why there shouldn't be a special
operator for it in D.

-Jon
In article <b4qoiq$16b5$1 digitaldaemon.com>, Ben Woodhead says...

I hate to ask, but what is a rotation operator, or what is it for..

Thanks Ben
"Ziemowit Zglinski" <Ziemowit_member pathlink.com> wrote in message
news:b4pt22$gg1$1 digitaldaemon.com...

 While programming a lot of embedded application, I often miss a rotation
 operator in almost all programming languages. This operation  is


implemented in

 all processor architectures and still difficult to achieve from a high


level

 language.

 Taking opportunity of not yet fully defined language, I propose to add two
 rotation operators to the language definition:
 Rotate right -  >  or  >>
 Rotate left  - <   or << 

 The behaviour should be analogue to the logical shift operators, except


the bit

 shifted out would be shift in on the opposite side in place of 0. Number


bits

 rotated should correspond to the length of the actual data type.

 Thank You,

 --  Ziemowit

     ziemek tera.com.pl
Mar 13 2003
parent "Ben Woodhead" <zander echotech.ca> writes:
Thanks guys.. I know what you mean now..

Ben

"Jonathan Andrew" <Jonathan_member pathlink.com> wrote in message
news:b4r20u$1do2$1 digitaldaemon.com...

 The rotation operator (at least as I've used it) shifts bits around in a
 value, so if you had a value

 11110000,

 and rotated it left two positions, you would have

 11000011, the bits just get shifted over left two positions, with the
 ones on the left coming back around to the right. As far as I know, its
 mostly used for encryption, and multiplication and division within


processors

 use rotation (shifts, anyway) for faster operation.

 Even small microcontrollers like the HC11 have this capability built in
 to the machine code, so I don't see why there shouldn't be a special
 operator for it in D.

 -Jon
 In article <b4qoiq$16b5$1 digitaldaemon.com>, Ben Woodhead says...

I hate to ask, but what is a rotation operator, or what is it for..

Thanks Ben
"Ziemowit Zglinski" <Ziemowit_member pathlink.com> wrote in message
news:b4pt22$gg1$1 digitaldaemon.com...

 While programming a lot of embedded application, I often miss a






rotation

 operator in almost all programming languages. This operation  is


implemented in

 all processor architectures and still difficult to achieve from a high


level

 language.

 Taking opportunity of not yet fully defined language, I propose to add






two

 rotation operators to the language definition:
 Rotate right -  >  or  >>
 Rotate left  - <   or << 

 The behaviour should be analogue to the logical shift operators, except


the bit

 shifted out would be shift in on the opposite side in place of 0.






Number

bits

 rotated should correspond to the length of the actual data type.

 Thank You,

 --  Ziemowit

     ziemek tera.com.pl
Mar 13 2003