On 22.11.2014, at 17:12, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Bert,

On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <bert@freudenbergs.de> wrote:
 
On 21.11.2014, at 23:01, Eliot Miranda uploaded VMMaker.oscog-eem.950.mcz
>
> Introduce >>> as an explicitly signed shift.

Ugh, can we pick something else, please? It's really confusing. In various languages (notably Java and JavaScript), >> is signed and >>> unsigned. I don't know any language that has both operators and the meaning reversed.

This is confused because of history. 

I know :)

What I'd like is to use >> as a signed shift (because that's what it is) and >>> as an unsigned shift.  And I'd like to change bitShift: to generate signed shifts and introduce unsignedBitShift: and ditch signedBitShift:.  But that means changing all uses of >> in VMMaker.  This would be my preferred solution but I think its *really* important that if we go this route we change VMMaker.oscog, VMMaker and VMMakerJS at the same time.  Can we synchronise this?

We might, but this would still break plugins that are not in the VMMaker repo. That was one of my thoughts with leaving >> alone and defining two new ones for explicit signed/unsigned shift.

I don't think you're right about >> being context dependent.  At least in VMMaker.oscog >> is always unsigned.  The change I made to generation was to not coerce a 64-bit receiver to 32-bits, but I didn't change the signedness.

That would be great, and I didn’t check thoroughly - maybe I’m mixing it up with bitShift:, which certainly depends on the types?

If we pick two new operators, I quite like Ben’s idea (>>> and >>-).

And if you’re sure that >> is unsigned in oscog then it should be trivial to replace with (the proposed unsigned) >>>. Which we then could also implement in Smalltalk to do an unsigned shift if the receiver happens to be negative (it just needs to figure out the word length - I can think of some hacks to do that).

- Bert -