"Elegant" C into PB?

[Tom Brodhead]

Some of the more "elegant" statements in C seem to have no equally elegant translation in PB. Take for example the C statement:

x += x >> 17;

Am I right that the simplest translation of this into PB syntax would be something along these lines:

OldX = x
SHIFT RIGHT OldX, 17
x = x + OldX

???

Or is there something I've overlooked?

Many thanks,
--Tom


------------------
Tom Brodhead

[David Roberts]

elegant
1 graceful in appearance or manner.
2 tasteful, refined.
3 (of a mode of life etc.) of refined luxury.
4 ingeniously simple and pleasing.
5 US excellent.

Antonym: x += x >> 17;


------------------

[Guest]

Originally posted by David Roberts:

Antonym: x += x >> 17;

You're in denial! If PB had SHIFT functions (not macros that eventually accomplish this) this would
add considerable flexibility and power. The present SHIFT subroutines are too limiting.

This has been suggested in the past.

[Chris Holbrook]

x = x + (x \ (2^17)) ' wonder what the compiler makes of this?

------------------

[Ron Dunn]

C is my fallback language - the language to which I return after
I give up on each look at something new - and I *hate* this type
of coding for its non-obviousness.

(PS: So far I like PB very much. It has its annoyances, but still
has enough benefits in simple user interface capabilities that I
have survived longer here than any other deviation from the one-
true-language that is C)

------------------

[David Roberts]

You're in denial!

Nope. I first saw a 'dig' when reading, some time ago:

' PB really should have BUILT-IN function for shift instead of SHIFT LEFT|RIGHT semantics....

by Florent Heyworth, 8 Aug 2000.

My point was that 'x += x >> 17;' is <U>not</U> elegant.

------------------

[Chris Holbrook]

My point was that 'x += x >> 17;' is <U>not</U> elegant.

Tom Brodhead's original point was not that it is elegant, but that it is "elegant".
I don't think that it is elegant, perhaps "succinct" would be nearer the mark.



------------------

[David Roberts]

The quotation marks were not used in the second instance.

------------------

[Richard Angell]

And nobody answered Tom's original question?
"OldX = x
SHIFT RIGHT OldX, 17
x = x + OldX"

Or is it ...

SHIFT RIGHT x, 17
INCR x

???




------------------
Rick Angell

[Chris Holbrook]

I thought he was trying to add x to x shifted right 17.

------------------

[David Roberts]

Tom got it right.

x += x >> 17; 'translates' to x = x + x >> 17;

------------------


[This message has been edited by David Roberts (edited January 17, 2006).]

[Richard Angell]

Strange, not being a C++ user, it seems strange that += would be published as a right to left associativity described as increment and assign. http://www.cppreference.com/operator_precedence.html
Added: However MS's Assignment Operators chart which I hunted down, does say Addition assignment. with the example
int nNumber = 1;
nNumber += 3; //nNumbere now is 4

Learn something new to forget each day

[This message has been edited by Richard Angell (edited January 17, 2006).]

[Tom Brodhead]

Yes, I was being slightly tongue-in-cheek when I used the word "elegant". Yes, succinct would be a better word.

I'm just curious if there's a way to do this without saving the value of the original variable.

(And yes, x += 1 does mean x = x + 1 in C code.)

Thus x += x >> 17 means "add to x the value of x right-shifted by 17."

If PB supported an inline shift operator, then this could be translated like:

x = x + (x RIGHTSHIFT 17)



------------------
Tom Brodhead

[Richard Angell]

Actually, if SHIFT was also available as a function, SHIFT (dir,var,bitcount) would that not do it too?

------------------
Rick Angell

[Paul Dixon]

Tom,
<<I'm just curious if there's a way to do this without saving the value of the original variable.>>

I'm sure there'll be a few ways to do it, one possibilty was posted earlier in this thread by Chris.

Other possibilities include:

c##=1+1/2^17
..
x=fix(x*c##)


or
!mov eax,x
!shr eax,17
!add x,eax

..OK, that last one uses EAX as an itermediate store but that's what the original C++ would do anyway as the intermediate variable is needed even if it isn't explicitly declared by the programmer and you'll not get it any faster.


or
x=x*131073
shift right x,17

..that assumes x is a defined as a variable with enough spare bits so as not to overflow.

x=x*131073\131072
..but it includes a slow divide.

Paul.


------------------

[Richard Angell]

Maybe encapsulating the in-line just suggested ???

#COMPILER PBWIN 8
#COMPILE EXE
#DIM ALL
MACRO ADDSHIFTR(var,bitcount)
    !mov eax,var
    !shr eax,bitcount
    !add var,eax
END MACRO
MACRO ADDSHIFTL(var,bitcount)
    !mov eax,var
    !shl eax,bitcount
    !add var,eax
END MACRO
MACRO SUBSHIFTR(var,bitcount)
    !mov eax,var
    !shr eax,bitcount
    !sub var,eax
END MACRO
MACRO SUBSHIFTL(var,bitcount)
    !mov eax,var
    !shl eax,bitcount
    !sub var,eax
END MACRO

FUNCTION PBMAIN () AS LONG
    LOCAL x AS DWORD
    x = 4
    ADDSHIFTR(x,2)
    ? FORMAT$(x)
    ADDSHIFTL(x,2)
    ? FORMAT$(x)
    SUBSHIFTR(x,2)
    ? FORMAT$(x)
    SUBSHIFTL(x,2)
    ? FORMAT$(x)
    
END FUNCTION

Although maybe the macro name could be better. One could also just making a macro function that returns the variable as a shifted quantity might be better.

------------------
Rick Angell

[Bryan Flick]

If PB supported an inline shift operator, then this could be translated like:

x = x + (x RIGHTSHIFT 17)

I agree with you, but I don't know if I like the keyword RIGHTSHIFT. I always liked the idea of a SHL (shift left) and SHR (shift right) operator. So your code would look something like

x = x + (x SHR 17)

which I think is readable enough. Also, having it as an operator in the compiler rather than calling a function ensures the correct operator precedence is maintained (which is useful when converting very complex expressions).

But to answer your question PB does not have these type of operators. Probably the easiest work around to accomplish this would be to write your own SHL and SHR macro or function:

MACRO FUNCTION SHL(xxx, yyy)
  MACROTEMP nWork
  DIM nWork AS LONG
  nWork = xxx
  SHIFT SIGNED LEFT nWork, yyy
END MACRO = nWork

EDIT: I see Richard beat me to it with his own set of functions.

Thanks,
Flick


[This message has been edited by Bryan Flick (edited January 17, 2006).]

[Richard Angell]

Bryan,

I was also working on the idea of the MACRO function, somthing like this:

MACRO FUNCTION SHIFTR(var,bitcount)
    MACROTEMP x
    LOCAL x AS DWORD
    !mov eax,var
    !shr eax,bitcount
    !mov x, eax
END MACRO  =  x

And of course a corresponding SHIFTL. The beauty of using it as a function is really readability later. That said, you also tackled the issue of the signed integer. So if one wanted to preserve signs, then a companion set of macros maybe, like SHIFTSR, SHIFTSL. Bottom line though is that it would be great if this came from PB in the first place.

------------------
Rick Angell



[This message has been edited by Richard Angell (edited January 17, 2006).]