[Vm-dev] type inferrence for #<< is IMO all wrong...

[Eliot Miranda]

Hi Nicolas, Hi Clément, Hi Pierre, Hi All,

    I'm working again on ARMv8 having got confused and with help clear
headed again.  So I'm getting the real system to run (it displays the full
desktop before crashing).  One issue is the IMO mis-typing of #<<.

The expression in question is
1 << (cogit coInterpreter highBit: cogit methodZone zoneEnd)
which is used to determine a type for mask:
mask := 1 << (cogit coInterpreter highBit: cogit methodZone zoneEnd) -
dataCacheMinLineLength.


In Smalltalk this evaluates to something large, and in the real VM it
should evaluate to 1 << 39.  However, because in
CCodeGenerator>>returnTypeForSend:in:ifNil: we explicitly assume C
semantics here:

^kernelReturnTypes
at: sel
ifAbsent:
[sel
caseOf: {
...
"C99 Sec Bitwise shift operators ... 3 Semantics ...
The integer promotions are performed on each of the operands.
 The type of the result is that of the promoted left operand..."
[#>>] -> [sendNode receiver typeFrom: self in: aTMethod].
[#<<] -> [sendNode receiver typeFrom: self in: aTMethod].

we compute the type of 1 << anything to be #int, and hence the type of mask
to be int, and hence mask is both truncated to 32-bits and later extended
to 64-bits by virtue of being passed as an argument to a #sqInt parameter.
So instead of generating the mask 16r7FFFFFFFC0 we generate the
mask 16rFFFFFFFFFFFFFFC0.  Clearly nonsense.

It seems to me that we have the wrong philosophy.
In CCodeGenerator>>returnTypeForSend:in:ifNil: we should be computing types
that cause the generated C to mimic as closely as possible what happens in
Smalltalk, *not* typing according to the C99 standard, which creates
unintended incompatibilities between the simulated Slang and the generated
Slang.

Surely what we should be doing for << is seeing if the right operand is a
constant and if so typing according to that, but in general typing << as
#sqInt or #usqInt, depending on the type of the left operand.  This is what
Smalltalk does; left-shifting a signed value preserves the sign; left
shifting a non-negative value always yields a non-negative value.  Yes,
eventually we will truncate to the word size, but the word size is sqInt,
not int, and we are familiar with the truncation issue.

The mistyping of << as int is unexpected and extremely inconvenient.  We
force the Slang programmer to type all variables receiving the result of a
<< explicitly.

Do you agree or does my way lead to chaos?

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200221/630afb7d/attachment.html>