Signed/unsigned shifting (was: VMMaker.oscog-eem.950.mcz)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Signed/unsigned shifting (was: VMMaker.oscog-eem.950.mcz)

Bert Freudenberg
 
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.

And >> still means signed or unsigned depending on context. Not nice at all.

How about ...

        >> signed/unsigned depending on type (what we have now)
        >>+ force unsigned shift
        >>- force signed shift

- Bert -


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Signed/unsigned shifting (was: VMMaker.oscog-eem.950.mcz)

Tobias Pape
 

On 22.11.2014, at 14:12, Bert Freudenberg <[hidden email]> 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.
>
> And >> still means signed or unsigned depending on context. Not nice at all.
>
> How about ...
>
> >> signed/unsigned depending on type (what we have now)
> >>+ force unsigned shift
> >>- force signed shift
This is nice!
Best
        -Tobias

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Signed/unsigned shifting (was: VMMaker.oscog-eem.950.mcz)

Eliot Miranda-2
In reply to this post by Bert Freudenberg
 
Hi Bert,

On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <[hidden email]> 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.  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?

 

And >> still means signed or unsigned depending on context. Not nice at all.

Right.  And there's the signedBitShift: bogosity too.
 

How about ...

        >> signed/unsigned depending on type (what we have now)
        >>+ force unsigned shift
        >>- force signed shift

That's funny.  For me the + screams signed.  So I would accept

        >> signed/unsigned depending on type (what we have now)
        >>+ force signed shift
        >>- force unsigned shift

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

--
best,
Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Signed/unsigned shifting (was: VMMaker.oscog-eem.950.mcz)

Chris Muller-3

On Sat, Nov 22, 2014 at 10:12 AM, Eliot Miranda <[hidden email]> wrote:

>
> Hi Bert,
>
> On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <[hidden email]> 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.  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?
>
>
>>
>>
>> And >> still means signed or unsigned depending on context. Not nice at all.
>
>
> Right.  And there's the signedBitShift: bogosity too.
>
>>
>>
>> How about ...
>>
>>         >> signed/unsigned depending on type (what we have now)
>>         >>+ force unsigned shift
>>         >>- force signed shift
>
>
> That's funny.  For me the + screams signed.

Berts made more sense to me simply because signed support
negatives(-), where unsigned only support positive(+)..
Reply | Threaded
Open this post in threaded view
|

Re: Signed/unsigned shifting

Ben Coman
In reply to this post by Eliot Miranda-2
 
Eliot Miranda wrote:

>  
>
>
> ------------------------------------------------------------------------
>
> Hi Bert,
>
> On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <[hidden email]
> <mailto:[hidden email]>> 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.  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?
>
>  
>
>
>     And >> still means signed or unsigned depending on context. Not nice
>     at all.
>
>
> Right.  And there's the signedBitShift: bogosity too.
>  
>
>
>     How about ...
>
>             >> signed/unsigned depending on type (what we have now)
>             >>+ force unsigned shift
>             >>- force signed shift
>
>
> That's funny.  For me the + screams signed.  So I would accept
>
>         >> signed/unsigned depending on type (what we have now)
>         >>+ force signed shift
>         >>- force unsigned shift
>
> But 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.
>
> --
> best,
> Eliot

The use of both + and - still leaves room for ambiguity.  How about...
 >>> force unsigned
 >>+ force signed

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: Signed/unsigned shifting

Ben Coman
In reply to this post by Chris Muller-3
 
Chris Muller wrote:

>  
> On Sat, Nov 22, 2014 at 10:12 AM, Eliot Miranda <[hidden email]> wrote:
>> Hi Bert,
>>
>> On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <[hidden email]> 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.  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?
>>
>>
>>>
>>> And >> still means signed or unsigned depending on context. Not nice at all.
>>
>> Right.  And there's the signedBitShift: bogosity too.
>>
>>>
>>> How about ...
>>>
>>>         >> signed/unsigned depending on type (what we have now)
>>>         >>+ force unsigned shift
>>>         >>- force signed shift
>>
>> That's funny.  For me the + screams signed.
>
> Berts made more sense to me simply because signed support
> negatives(-), where unsigned only support positive(+)..
>

Revising my previous suggestion...
 >>> force unsigned
 >>- force signed

cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: Signed/unsigned shifting (was: VMMaker.oscog-eem.950.mcz)

Bert Freudenberg
In reply to this post by Eliot Miranda-2
 

On 22.11.2014, at 17:12, Eliot Miranda <[hidden email]> wrote:

Hi Bert,

On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <[hidden email]> 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 -




smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Signed/unsigned shifting

Nicolas Cellier
In reply to this post by Ben Coman
 


2014-11-23 0:56 GMT+01:00 Ben Coman <[hidden email]>:

Chris Muller wrote:
 On Sat, Nov 22, 2014 at 10:12 AM, Eliot Miranda <[hidden email]> wrote:
Hi Bert,

On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg <[hidden email]> 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.  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?



And >> still means signed or unsigned depending on context. Not nice at all.

Right.  And there's the signedBitShift: bogosity too.


How about ...

        >> signed/unsigned depending on type (what we have now)
        >>+ force unsigned shift
        >>- force signed shift

That's funny.  For me the + screams signed.

Berts made more sense to me simply because signed support
negatives(-), where unsigned only support positive(+)..


Revising my previous suggestion...
>>> force unsigned
>>- force signed

cheers -ben


As a latin, writing the most significant bit to least significant from left to right, and the sign leftmost, I would suggest ->> to suggest how we propagate the minus sign bit...

Nicolas
Reply | Threaded
Open this post in threaded view
|

Re: Signed/unsigned shifting

Ben Coman
 
Nicolas Cellier wrote:

>  
>
>
> ------------------------------------------------------------------------
>
>
>
> 2014-11-23 0:56 GMT+01:00 Ben Coman <[hidden email]
> <mailto:[hidden email]>>:
>
>
>     Chris Muller wrote:
>
>          On Sat, Nov 22, 2014 at 10:12 AM, Eliot Miranda
>         <[hidden email] <mailto:[hidden email]>> wrote:
>
>             Hi Bert,
>
>             On Sat, Nov 22, 2014 at 5:12 AM, Bert Freudenberg
>             <[hidden email] <mailto:[hidden email]>> 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.  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?
>
>
>
>                 And >> still means signed or unsigned depending on
>                 context. Not nice at all.
>
>
>             Right.  And there's the signedBitShift: bogosity too.
>
>
>                 How about ...
>
>                         >> signed/unsigned depending on type (what we
>                 have now)
>                         >>+ force unsigned shift
>                         >>- force signed shift
>
>
>             That's funny.  For me the + screams signed.
>
>
>         Berts made more sense to me simply because signed support
>         negatives(-), where unsigned only support positive(+)..
>
>
>     Revising my previous suggestion...
>      >>> force unsigned
>      >>- force signed
>
>     cheers -ben
>
>
> As a latin, writing the most significant bit to least significant from
> left to right, and the sign leftmost, I would suggest ->> to suggest how
> we propagate the minus sign bit...
>
> Nicolas

Interesting point.