Hi Tim,
I'm simulating bitblt code and have a situation where
(cmShiftTable at: 0) = 4294967280 (cmShiftTable at: 0) hex '16rFFFFFFF0'
Clearly this should be -4.
This breaks simulation because (sourcePixel bitAnd: (cmMaskTable at: 0)) bitShift: (cmShiftTable at: 0) is trying to make a 4Gb LargePositiveInteger ;-).
How can we make it so?
On 14-03-2014, at 6:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tim,
I'm simulating bitblt code and have a situation where
(cmShiftTable at: 0) = 4294967280 (cmShiftTable at: 0) hex '16rFFFFFFF0'
Clearly this should be -4.
This breaks simulation because (sourcePixel bitAnd: (cmMaskTable at: 0)) bitShift: (cmShiftTable at: 0) is trying to make a 4Gb LargePositiveInteger ;-).
How can we make it so?
Hmm, well if you need to make a 4Gb LPI I guess you’d best have plenty of memory?
Dunno; looks like cmShiftTable is supposed to use int32_t thingies in the C code. BitBltSimulation>loadColorMapShiftOrMaskFrom: looks like the culprit to me though - (simulated)firstIndexableField: might be not doing the right thing?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Always loses battles of wits because he's unarmed.
2014-03-15 2:44 GMT+01:00 tim Rowledge tim@rowledge.org:
On 14-03-2014, at 6:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tim,
I'm simulating bitblt code and have a situation where
(cmShiftTable at: 0) = 4294967280 (cmShiftTable at: 0) hex '16rFFFFFFF0'
Clearly this should be -4.
I presume you mean - 2^4 (-2r1e4 or -16) ;)
This breaks simulation because (sourcePixel bitAnd: (cmMaskTable at: 0)) bitShift:
(cmShiftTable at: 0)
is trying to make a 4Gb LargePositiveInteger ;-).
How can we make it so?
Hmm, well if you need to make a 4Gb LPI I guess you'd best have plenty of memory?
Dunno; looks like cmShiftTable is supposed to use int32_t thingies in the C code. BitBltSimulation>loadColorMapShiftOrMaskFrom: looks like the culprit to me though - (simulated)firstIndexableField: might be not doing the right thing?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Always loses battles of wits because he's unarmed.
On Sat, Mar 15, 2014 at 12:32 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2014-03-15 2:44 GMT+01:00 tim Rowledge tim@rowledge.org:
On 14-03-2014, at 6:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tim,
I'm simulating bitblt code and have a situation where
(cmShiftTable at: 0) = 4294967280 (cmShiftTable at: 0) hex '16rFFFFFFF0'
Clearly this should be -4.
I presume you mean - 2^4 (-2r1e4 or -16) ;)
doh! quite :)
This breaks simulation because (sourcePixel bitAnd: (cmMaskTable at: 0)) bitShift:
(cmShiftTable at: 0)
is trying to make a 4Gb LargePositiveInteger ;-).
How can we make it so?
Hmm, well if you need to make a 4Gb LPI I guess you'd best have plenty of memory?
Dunno; looks like cmShiftTable is supposed to use int32_t thingies in the C code. BitBltSimulation>loadColorMapShiftOrMaskFrom: looks like the culprit to me though - (simulated)firstIndexableField: might be not doing the right thing?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Always loses battles of wits because he's unarmed.
On Fri, Mar 14, 2014 at 06:44:59PM -0700, tim Rowledge wrote:
On 14-03-2014, at 6:16 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tim,
I'm simulating bitblt code and have a situation where
(cmShiftTable at: 0) = 4294967280 (cmShiftTable at: 0) hex '16rFFFFFFF0'
Clearly this should be -4.
This breaks simulation because (sourcePixel bitAnd: (cmMaskTable at: 0)) bitShift: (cmShiftTable at: 0) is trying to make a 4Gb LargePositiveInteger ;-).
How can we make it so?
Hmm, well if you need to make a 4Gb LPI I guess you?d best have plenty of memory?
Dunno; looks like cmShiftTable is supposed to use int32_t thingies in the C code. BitBltSimulation>loadColorMapShiftOrMaskFrom: looks like the culprit to me though - (simulated)firstIndexableField: might be not doing the right thing?
firstIndexableField is ok, this looks like a problem elsewhere.
Probably not helpful, but maybe it will point someone to a clue: The shifts array in a color map is an IntegerArray, so must be signed 32 bit int. Somewhere along the line, a perfectly valid entry in shift array with value -16 must have gotten converted or cast to unsigned int, such that it was now being interpreted as an integer with value 16rFFFFFFF0. I'm not very familiar with BitBlt, but this looks to me like in inappropriated conversion from int to unsigned, or possibly something related to the way an integer value is being extracted from an IntegerArray.
Dave
On Sat, Mar 15, 2014 at 1:24 PM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Mar 14, 2014 at 06:44:59PM -0700, tim Rowledge wrote:
On 14-03-2014, at 6:16 PM, Eliot Miranda eliot.miranda@gmail.com
wrote:
Hi Tim,
I'm simulating bitblt code and have a situation where
(cmShiftTable at: 0) = 4294967280 (cmShiftTable at: 0) hex '16rFFFFFFF0'
Clearly this should be -4.
This breaks simulation because (sourcePixel bitAnd: (cmMaskTable at: 0)) bitShift:
(cmShiftTable at: 0)
is trying to make a 4Gb LargePositiveInteger ;-).
How can we make it so?
Hmm, well if you need to make a 4Gb LPI I guess you?d best have plenty
of memory?
Dunno; looks like cmShiftTable is supposed to use int32_t thingies in
the C code.
BitBltSimulation>loadColorMapShiftOrMaskFrom: looks like the culprit to
me though - (simulated)firstIndexableField: might be not doing the right thing?
firstIndexableField is ok, this looks like a problem elsewhere.
Probably not helpful, but maybe it will point someone to a clue: The shifts array in a color map is an IntegerArray, so must be signed 32 bit int. Somewhere along the line, a perfectly valid entry in shift array with value -16 must have gotten converted or cast to unsigned int, such that it was now being interpreted as an integer with value 16rFFFFFFF0. I'm not very familiar with BitBlt, but this looks to me like in inappropriated conversion from int to unsigned, or possibly something related to the way an integer value is being extracted from an IntegerArray.
There are two different initializations. One in setupColorMasksFrom:to: uses an explicit IntegerArray (and this will work). The other in loadColorMap uses loadColorMapShiftOrMaskFrom: which just answers a vanilla CArray, and this won't work without appropriate access through the CArray. To add that I added this at the end of loadColorMap, immediately before the ^true:
self cCode: [] inSmalltalk: [cmShiftTable ifNotNil: [cmShiftTable := CPluggableAccessor new setObject: cmShiftTable; atBlock: [:obj :idx| obj intAt: idx - 1] atPutBlock: [:obj :idx :val| obj intAt: idx - 1 put: val]; yourself]]. ^true
vm-dev@lists.squeakfoundation.org