[Vm-dev] bitShift: and runtime sign discussion

[Nicolas Cellier]

I have opened http://code.google.com/p/cog/issues/detail?id=111 with
proposed .cs to review (for .oscog branch)

Nicolas

2012/12/27 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> Another candidate in the same category of refactoring..,
>
>
> 2012/12/23 Igor Stasenko <siguctua at gmail.com>:
>>
>> On 23 December 2012 18:05, David T. Lewis <lewis at mail.msen.com> wrote:
>>>
>>> On Sun, Dec 23, 2012 at 02:14:37PM +0100, Nicolas Cellier wrote:
>>>>
>>>> As you may know, the CCodeGenerator is clever enough to
>>>> #generateBitShift:on:indent: with proper direction << or >> when the
>>>> shift is literal.
>>>> When the shift in (expr bitShift: shift) is a variable or another
>>>> expression, it will produce a runtime test (shift <0) ? expr>>shift :
>>>> expr <<shift;
>>>> This is good for an arbitrary shift, but more than often we know the
>>>> sign and direction of the shift in advance, and this runtime test is
>>>> void.
>>>> We must be aware that aggressive inlining will spread these useless
>>>> code all around.
>>>> Well, we might ignore impact on performance but we shall better not
>>>> ignore warnings generated by C compiler (or XCode analyzer) if we want
>>>> the code to be portable to other compilers (including future versions
>>>> of gcc).
>>>> ...and the eventual warnings will be spreaded too
>>>>
>>>> Maybe we could arrange for CCodeGenerator to recognize more cases when
>>>> the shift is unsigned, but
>>>> 1) the CCodeGenerator is yet unable to infer expression type (except
>>>> some hack for declared variable)
>>>> 2) we almost never use unsigned declaration in vm source anyway.
>>>>
>>>> In the mean time, I suggest we use << and >> directlty in smalltalk
>>>> code (slang) when we know the direction in advance.
>>>
>>> IMO it is better to write these expressions directly, as you have done
>>> in your examples. There are many places in the VM code where types are
>>> not carefully declared, and I suspect that trying to make the code
>>> generator be more clever would only lead to unintended side effects.
>>> Better to just write these explicitly using << and >> when you know
>>> that it is safe to do so.
>>>
>> +1
>>
>> --
>> Best regards,
>> Igor Stasenko.