Hi David,
and another issue is that "unsigned" is shorthand for "unsigned int", so if you wanted to generalize the method to handle integers of the system's word size (as is the case with 64-bit Spur which will have 61-bit SmallIntegers, unlike the 31-bit SmallIntegers in 64-bit Squeak) you'd want to use "usqInt", not "unsigned".
On Sat, Sep 6, 2014 at 8:45 PM, commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker-dtl.350.mcz
==================== Summary ====================
Name: VMMaker-dtl.350 Author: dtl Time: 6 September 2014, 11:44:28.389 pm UUID: 2ad132b0-5fb3-4580-b5a8-29af12c3cb81 Ancestors: VMMaker-dtl.349
VMMaker 4.13.6
Fix primitiveBitShift (primitive 17) for sqInt declared 64 bits, as in a VM for 64-bit image format 68002.
In image format 68002, bit shift left failed because of return type limited to a 32-bit large integer, but internally the primitive successfully shifted left into a variable declared as a 64 bit sqInt.. The simple fix (implemented here) is to declare the variable as 32 bit unsigned to agree with the 32-bit logic of the existing primitive.
Note that permitting a left shift into a 64 bit variable makes sense generally, and the primitive could be recoded to accomodate this for shift left, with the primitive answering positive64BitIntegerFor: rather than positive32BitIntegerFor: in the case of a shift left to allow for the greater range (not implemented in this update).
With this update, all KernelTests-Numbers tests pass for the 64-bit image format 68002.
=============== Diff against VMMaker-dtl.349 ===============
Item was changed: ----- Method: InterpreterPrimitives>>primitiveBitShift (in category 'arithmetic integer primitives') ----- primitiveBitShift | integerReceiver integerArgument shifted |
<var: #shifted type: 'unsigned'>
integerArgument := self popInteger. integerReceiver := self popPos32BitInteger. self successful ifTrue: [ integerArgument >= 0 ifTrue: [ "Left shift -- must fail if we lose bits beyond 32" self success: integerArgument <= 31. shifted := integerReceiver << integerArgument. self success: (shifted >> integerArgument) =
integerReceiver. ] ifFalse: [ "Right shift -- OK to lose bits" self success: integerArgument >= -31. shifted := integerReceiver >> (0 - integerArgument). ]. ]. self successful ifTrue: [self push: (self positive32BitIntegerFor: shifted)] ifFalse: [self unPop: 2]!
Item was changed: ----- Method: VMMaker class>>versionString (in category 'version testing') ----- versionString
"VMMaker versionString"
^'4.13.6'!
^'4.13.7'!
I know that "unsigned" means "unsigned int". That is the intent.
With the primitive as currently implemented, that variable must be 32 bits, otherwise the shift left can successfully produce a five byte large integer that is truncated to four without failing the primitive. This change is to fix the current implementation of the primitive in the case of sizeof(sqInt) == 8.
Dave
Hi David,
and another issue is that "unsigned" is shorthand for "unsigned int", so if you wanted to generalize the method to handle integers of the system's word size (as is the case with 64-bit Spur which will have 61-bit SmallIntegers, unlike the 31-bit SmallIntegers in 64-bit Squeak) you'd want to use "usqInt", not "unsigned".
On Sat, Sep 6, 2014 at 8:45 PM, commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker-dtl.350.mcz
==================== Summary ====================
Name: VMMaker-dtl.350 Author: dtl Time: 6 September 2014, 11:44:28.389 pm UUID: 2ad132b0-5fb3-4580-b5a8-29af12c3cb81 Ancestors: VMMaker-dtl.349
VMMaker 4.13.6
Fix primitiveBitShift (primitive 17) for sqInt declared 64 bits, as in a VM for 64-bit image format 68002.
In image format 68002, bit shift left failed because of return type limited to a 32-bit large integer, but internally the primitive successfully shifted left into a variable declared as a 64 bit sqInt.. The simple fix (implemented here) is to declare the variable as 32 bit unsigned to agree with the 32-bit logic of the existing primitive.
Note that permitting a left shift into a 64 bit variable makes sense generally, and the primitive could be recoded to accomodate this for shift left, with the primitive answering positive64BitIntegerFor: rather than positive32BitIntegerFor: in the case of a shift left to allow for the greater range (not implemented in this update).
With this update, all KernelTests-Numbers tests pass for the 64-bit image format 68002.
=============== Diff against VMMaker-dtl.349 ===============
Item was changed: ----- Method: InterpreterPrimitives>>primitiveBitShift (in category 'arithmetic integer primitives') ----- primitiveBitShift | integerReceiver integerArgument shifted |
<var: #shifted type: 'unsigned'>
integerArgument := self popInteger. integerReceiver := self popPos32BitInteger. self successful ifTrue: [ integerArgument >= 0 ifTrue: [ "Left shift -- must fail if we lose bits beyond
32" self success: integerArgument <= 31. shifted := integerReceiver << integerArgument. self success: (shifted >> integerArgument) = integerReceiver. ] ifFalse: [ "Right shift -- OK to lose bits" self success: integerArgument >= -31. shifted := integerReceiver >> (0 - integerArgument). ]. ]. self successful ifTrue: [self push: (self positive32BitIntegerFor: shifted)] ifFalse: [self unPop: 2]!
Item was changed: ----- Method: VMMaker class>>versionString (in category 'version testing') ----- versionString
"VMMaker versionString"
^'4.13.6'!
^'4.13.7'!
-- best, Eliot
Hi David,
On Mon, Sep 8, 2014 at 12:18 PM, David T. Lewis lewis@mail.msen.com wrote:
I know that "unsigned" means "unsigned int". That is the intent.
With the primitive as currently implemented, that variable must be 32 bits, otherwise the shift left can successfully produce a five byte large integer that is truncated to four without failing the primitive. This change is to fix the current implementation of the primitive in the case of sizeof(sqInt) == 8.
OK, then it is fixing it in a way that will break a 64-bit implementation that uses 64-bit SmallIntegers. Personally I find the method defective (for reasons already stated), and will be rewriting it soon.
Dave
Hi David,
and another issue is that "unsigned" is shorthand for "unsigned int", so if you wanted to generalize the method to handle integers of the system's word size (as is the case with 64-bit Spur which will have 61-bit SmallIntegers, unlike the 31-bit SmallIntegers in 64-bit Squeak) you'd want to use "usqInt", not "unsigned".
On Sat, Sep 6, 2014 at 8:45 PM, commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker-dtl.350.mcz
==================== Summary ====================
Name: VMMaker-dtl.350 Author: dtl Time: 6 September 2014, 11:44:28.389 pm UUID: 2ad132b0-5fb3-4580-b5a8-29af12c3cb81 Ancestors: VMMaker-dtl.349
VMMaker 4.13.6
Fix primitiveBitShift (primitive 17) for sqInt declared 64 bits, as in a VM for 64-bit image format 68002.
In image format 68002, bit shift left failed because of return type limited to a 32-bit large integer, but internally the primitive successfully shifted left into a variable declared as a 64 bit sqInt.. The simple fix (implemented here) is to declare the variable as 32 bit unsigned to agree with the 32-bit logic of the existing primitive.
Note that permitting a left shift into a 64 bit variable makes sense generally, and the primitive could be recoded to accomodate this for shift left, with the primitive answering positive64BitIntegerFor: rather than positive32BitIntegerFor: in the case of a shift left to allow for the greater range (not implemented in this update).
With this update, all KernelTests-Numbers tests pass for the 64-bit image format 68002.
=============== Diff against VMMaker-dtl.349 ===============
Item was changed: ----- Method: InterpreterPrimitives>>primitiveBitShift (in category 'arithmetic integer primitives') ----- primitiveBitShift | integerReceiver integerArgument shifted |
<var: #shifted type: 'unsigned'>
integerArgument := self popInteger. integerReceiver := self popPos32BitInteger. self successful ifTrue: [ integerArgument >= 0 ifTrue: [ "Left shift -- must fail if we lose bits beyond
32" self success: integerArgument <= 31. shifted := integerReceiver << integerArgument. self success: (shifted >> integerArgument) = integerReceiver. ] ifFalse: [ "Right shift -- OK to lose bits" self success: integerArgument >= -31. shifted := integerReceiver >> (0 - integerArgument). ]. ]. self successful ifTrue: [self push: (self positive32BitIntegerFor: shifted)] ifFalse: [self unPop: 2]!
Item was changed: ----- Method: VMMaker class>>versionString (in category 'version testing') ----- versionString
"VMMaker versionString"
^'4.13.6'!
^'4.13.7'!
-- best, Eliot
Hi Eliot,
Agreed, the primitive will need to be rewritten to work with a 64-bit SmallInteger. There may be other integer primitives that will need attention too, although I have not looked.
Dave
Hi David,
On Mon, Sep 8, 2014 at 12:18 PM, David T. Lewis lewis@mail.msen.com wrote:
I know that "unsigned" means "unsigned int". That is the intent.
With the primitive as currently implemented, that variable must be 32 bits, otherwise the shift left can successfully produce a five byte large integer that is truncated to four without failing the primitive. This change is to fix the current implementation of the primitive in the case of sizeof(sqInt) == 8.
OK, then it is fixing it in a way that will break a 64-bit implementation that uses 64-bit SmallIntegers. Personally I find the method defective (for reasons already stated), and will be rewriting it soon.
Dave
Hi David,
and another issue is that "unsigned" is shorthand for "unsigned
int",
so if you wanted to generalize the method to handle integers of the
system's
word size (as is the case with 64-bit Spur which will have 61-bit SmallIntegers, unlike the 31-bit SmallIntegers in 64-bit Squeak) you'd want to use "usqInt", not "unsigned".
On Sat, Sep 6, 2014 at 8:45 PM, commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker-dtl.350.mcz
==================== Summary ====================
Name: VMMaker-dtl.350 Author: dtl Time: 6 September 2014, 11:44:28.389 pm UUID: 2ad132b0-5fb3-4580-b5a8-29af12c3cb81 Ancestors: VMMaker-dtl.349
VMMaker 4.13.6
Fix primitiveBitShift (primitive 17) for sqInt declared 64 bits, as
in a
VM for 64-bit image format 68002.
In image format 68002, bit shift left failed because of return type limited to a 32-bit large integer, but internally the primitive successfully shifted left into a variable declared as a 64 bit
sqInt..
The simple fix (implemented here) is to declare the variable as 32 bit unsigned to agree with the 32-bit logic of the existing primitive.
Note that permitting a left shift into a 64 bit variable makes sense generally, and the primitive could be recoded to accomodate this for shift left, with the primitive answering positive64BitIntegerFor: rather
than
positive32BitIntegerFor: in the case of a shift left to allow for the greater range (not implemented in this update).
With this update, all KernelTests-Numbers tests pass for the 64-bit image format 68002.
=============== Diff against VMMaker-dtl.349 ===============
Item was changed: ----- Method: InterpreterPrimitives>>primitiveBitShift (in category 'arithmetic integer primitives') ----- primitiveBitShift | integerReceiver integerArgument shifted |
<var: #shifted type: 'unsigned'>
integerArgument := self popInteger. integerReceiver := self popPos32BitInteger. self successful ifTrue: [ integerArgument >= 0 ifTrue: [ "Left shift -- must fail if we lose bits
beyond
32" self success: integerArgument <= 31. shifted := integerReceiver <<
integerArgument.
self success: (shifted >> integerArgument) =
integerReceiver. ] ifFalse: [ "Right shift -- OK to lose bits" self success: integerArgument >= -31. shifted := integerReceiver >> (0 - integerArgument). ]. ]. self successful ifTrue: [self push: (self positive32BitIntegerFor: shifted)] ifFalse: [self unPop: 2]!
Item was changed: ----- Method: VMMaker class>>versionString (in category 'version testing') ----- versionString
"VMMaker versionString"
^'4.13.6'!
^'4.13.7'!
-- best, Eliot
-- best, Eliot
Hi,
On 08.09.2014, at 23:23, David T. Lewis lewis@mail.msen.com wrote:
Hi Eliot,
Agreed, the primitive will need to be rewritten to work with a 64-bit SmallInteger. There may be other integer primitives that will need attention too, although I have not looked.
Having tried implementing other SqueakVMs, my impression is, that the SmallInt-is-31-bit assumption is like everywhere. Starting with some int-primitives and not ending with bitBlt. We really have to be careful here.
Best -Tobias
Dave
Hi David,
On Mon, Sep 8, 2014 at 12:18 PM, David T. Lewis lewis@mail.msen.com wrote:
I know that "unsigned" means "unsigned int". That is the intent.
With the primitive as currently implemented, that variable must be 32 bits, otherwise the shift left can successfully produce a five byte large integer that is truncated to four without failing the primitive. This change is to fix the current implementation of the primitive in the case of sizeof(sqInt) == 8.
OK, then it is fixing it in a way that will break a 64-bit implementation that uses 64-bit SmallIntegers. Personally I find the method defective (for reasons already stated), and will be rewriting it soon.
Dave
Hi David,
and another issue is that "unsigned" is shorthand for "unsigned
int",
so if you wanted to generalize the method to handle integers of the
system's
word size (as is the case with 64-bit Spur which will have 61-bit SmallIntegers, unlike the 31-bit SmallIntegers in 64-bit Squeak) you'd want to use "usqInt", not "unsigned".
On Sat, Sep 6, 2014 at 8:45 PM, commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker-dtl.350.mcz
==================== Summary ====================
Name: VMMaker-dtl.350 Author: dtl Time: 6 September 2014, 11:44:28.389 pm UUID: 2ad132b0-5fb3-4580-b5a8-29af12c3cb81 Ancestors: VMMaker-dtl.349
VMMaker 4.13.6
Fix primitiveBitShift (primitive 17) for sqInt declared 64 bits, as
in a
VM for 64-bit image format 68002.
In image format 68002, bit shift left failed because of return type limited to a 32-bit large integer, but internally the primitive successfully shifted left into a variable declared as a 64 bit
sqInt..
The simple fix (implemented here) is to declare the variable as 32 bit unsigned to agree with the 32-bit logic of the existing primitive.
Note that permitting a left shift into a 64 bit variable makes sense generally, and the primitive could be recoded to accomodate this for shift left, with the primitive answering positive64BitIntegerFor: rather
than
positive32BitIntegerFor: in the case of a shift left to allow for the greater range (not implemented in this update).
With this update, all KernelTests-Numbers tests pass for the 64-bit image format 68002.
=============== Diff against VMMaker-dtl.349 ===============
Item was changed: ----- Method: InterpreterPrimitives>>primitiveBitShift (in category 'arithmetic integer primitives') ----- primitiveBitShift | integerReceiver integerArgument shifted |
<var: #shifted type: 'unsigned'>
integerArgument := self popInteger. integerReceiver := self popPos32BitInteger. self successful ifTrue: [ integerArgument >= 0 ifTrue: [ "Left shift -- must fail if we lose bits
beyond
32" self success: integerArgument <= 31. shifted := integerReceiver <<
integerArgument.
self success: (shifted >> integerArgument) =
integerReceiver. ] ifFalse: [ "Right shift -- OK to lose bits" self success: integerArgument >= -31. shifted := integerReceiver >> (0 - integerArgument). ]. ]. self successful ifTrue: [self push: (self positive32BitIntegerFor: shifted)] ifFalse: [self unPop: 2]!
Item was changed: ----- Method: VMMaker class>>versionString (in category 'version testing') ----- versionString
"VMMaker versionString"
^'4.13.6'!
^'4.13.7'!
-- best, Eliot
-- best, Eliot
On Mon, Sep 8, 2014 at 2:43 PM, Tobias Pape Das.Linux@gmx.de wrote:
Hi,
On 08.09.2014, at 23:23, David T. Lewis lewis@mail.msen.com wrote:
Hi Eliot,
Agreed, the primitive will need to be rewritten to work with a 64-bit SmallInteger. There may be other integer primitives that will need attention too, although I have not looked.
Having tried implementing other SqueakVMs, my impression is, that the SmallInt-is-31-bit assumption is like everywhere. Starting with some int-primitives and not ending with bitBlt. We really have to be careful here.
That's what tests and sheer bloody-mindedness are for ;-)
Best -Tobias
Dave
Hi David,
On Mon, Sep 8, 2014 at 12:18 PM, David T. Lewis lewis@mail.msen.com wrote:
I know that "unsigned" means "unsigned int". That is the intent.
With the primitive as currently implemented, that variable must be 32 bits, otherwise the shift left can successfully produce a five byte large integer that is truncated to four without failing the primitive. This change is to fix the current implementation of the primitive in the
case
of sizeof(sqInt) == 8.
OK, then it is fixing it in a way that will break a 64-bit
implementation
that uses 64-bit SmallIntegers. Personally I find the method defective (for reasons already stated), and will be rewriting it soon.
Dave
Hi David,
and another issue is that "unsigned" is shorthand for "unsigned
int",
so if you wanted to generalize the method to handle integers of the
system's
word size (as is the case with 64-bit Spur which will have 61-bit SmallIntegers, unlike the 31-bit SmallIntegers in 64-bit Squeak) you'd want to use "usqInt", not "unsigned".
On Sat, Sep 6, 2014 at 8:45 PM, commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker-dtl.350.mcz
==================== Summary ====================
Name: VMMaker-dtl.350 Author: dtl Time: 6 September 2014, 11:44:28.389 pm UUID: 2ad132b0-5fb3-4580-b5a8-29af12c3cb81 Ancestors: VMMaker-dtl.349
VMMaker 4.13.6
Fix primitiveBitShift (primitive 17) for sqInt declared 64 bits, as
in a
VM for 64-bit image format 68002.
In image format 68002, bit shift left failed because of return type limited to a 32-bit large integer, but internally the primitive successfully shifted left into a variable declared as a 64 bit
sqInt..
The simple fix (implemented here) is to declare the variable as 32 bit unsigned to agree with the 32-bit logic of the existing primitive.
Note that permitting a left shift into a 64 bit variable makes sense generally, and the primitive could be recoded to accomodate this for shift left, with the primitive answering positive64BitIntegerFor: rather
than
positive32BitIntegerFor: in the case of a shift left to allow for the greater range (not implemented in this update).
With this update, all KernelTests-Numbers tests pass for the 64-bit image format 68002.
=============== Diff against VMMaker-dtl.349 ===============
Item was changed: ----- Method: InterpreterPrimitives>>primitiveBitShift (in category 'arithmetic integer primitives') ----- primitiveBitShift | integerReceiver integerArgument shifted |
<var: #shifted type: 'unsigned'>
integerArgument := self popInteger. integerReceiver := self popPos32BitInteger. self successful ifTrue: [ integerArgument >= 0 ifTrue: [ "Left shift -- must fail if we lose bits
beyond
32" self success: integerArgument <= 31. shifted := integerReceiver <<
integerArgument.
self success: (shifted >> integerArgument) =
integerReceiver. ] ifFalse: [ "Right shift -- OK to lose bits" self success: integerArgument >= -31. shifted := integerReceiver >> (0 - integerArgument). ]. ]. self successful ifTrue: [self push: (self positive32BitIntegerFor: shifted)] ifFalse: [self unPop: 2]!
Item was changed: ----- Method: VMMaker class>>versionString (in category 'version testing') ----- versionString
"VMMaker versionString"
^'4.13.6'!
^'4.13.7'!
-- best, Eliot
-- best, Eliot
On Mon, Sep 08, 2014 at 03:11:31PM -0700, Eliot Miranda wrote:
On Mon, Sep 8, 2014 at 2:43 PM, Tobias Pape Das.Linux@gmx.de wrote:
Hi,
On 08.09.2014, at 23:23, David T. Lewis lewis@mail.msen.com wrote:
Hi Eliot,
Agreed, the primitive will need to be rewritten to work with a 64-bit SmallInteger. There may be other integer primitives that will need attention too, although I have not looked.
Having tried implementing other SqueakVMs, my impression is, that the SmallInt-is-31-bit assumption is like everywhere. Starting with some int-primitives and not ending with bitBlt. We really have to be careful here.
That's what tests and sheer bloody-mindedness are for ;-)
A full frontal assault is one possible approach, but it may be worth considering the strategy that Dan used for the image format 68002 64-bit image. In this object memory, the object format allows for very large SmallInteger values, but does not require them. The minVal and maxVal for SmallInteger can remain unchanged in the image, and everything just works.
With that strategy, the task of converting the image to take advantage of the new SmallInteger object format can be separated from the task of getting the Spur 64-bit object memory and VM up and running.
Dave
vm-dev@lists.squeakfoundation.org