0007447: byteSizeOf: is wrong for 64bit images

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0007447

[Squeak] Squeak 64 bit

major

always

01-13-10 22:49

01-14-10 12:53

Reporter

johnmci

View Status

public

Assigned To

Priority

normal

Resolution

open

Status

new

Product Version

trunk

Summary

0007447: byteSizeOf: is wrong for 64bit images

Description

BTW, there's clearly an exception for format = 7 which is supposed to be 64-bit longs. So lengthOf:baseheader:format: looks wrong for 64-bit images. It needs to say something like

    fmt <= 4
        ifTrue: [ ^ (sz - BaseHeaderSize) >> ShiftForWord "words"].
    fmt = 7
        ifTrue: [ ^ (sz - BaseHeaderSize) >> 3 "64-bit longs"].
    fmt < 8
        ifTrue: [ ^ (sz - BaseHeaderSize) >> 2 "32-bit longs"]
        ifFalse: [ ^ (sz - BaseHeaderSize) - (fmt bitAnd: 3) "bytes"]

or format = 7 needs to be documented as being unused.

On Wed, Jan 13, 2010 at 10:16 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

On Wed, Jan 13, 2010 at 9:13 AM, Andreas Raab <andreas.raab@gmx.de> wrote:

John M McIntosh wrote:
So I was trying to build a 64bit VM this evening and it would die in loadBitBltFromWarping
where it check to see if the destination bit form has a byteSizeOf() that is equal to pitch * height
this causes a prim failure before any drawing can occur.
In the past if the form was 1,521,520 bytes this altered call returns 3,043,040.

I assume this is a bug since with the previous code I could build runnable 64bit VMs...?

Or then again is the bitBitPlugin wrong in it's assumption of slot size?

Depends. In a 64bit image does a Bitmap contain 32 bit entities or 64 bit entities? If the former, then byteSizeOf is wrong for Bitmap (and possibly other 32 bit containing entities). If the latter, then the pitch computation in BitBlt is wrong.

The former. See lengthOf:baseHeader:format:. There is a distinction between pointer objects (format <= 4) whose slots are BytesPerWord long, 32-bit objects (fmt between: 5 and: 7) whose slots are 32-bits in size, and byte objects whose slots are 8 bits in size. byteSizeOf: clearly discards this distinction. Why not reimplement it as

byteSizeOf: oop
    | header format size |
    (self isIntegerObject: oop) ifTrue:[^0].
    header := self baseHeader: oop.
    format := self formatOfHeader: header.
    (header bitAnd: TypeMask) = HeaderTypeSizeAndClass
        ifTrue: [ size := (self sizeHeader: oop) bitAnd: LongSizeMask ]
        ifFalse: [ size := (header bitAnd: SizeMask)].
    size := size - (header bitAnd: Size4Bit).
    format <= 4
        ifTrue: [ ^ size - BaseHeaderSize "words"].
    format < 8
        ifTrue: [ ^ size - BaseHeaderSize "32-bit longs"]
        ifFalse: [ ^ (size - BaseHeaderSize) - (format bitAnd: 3) "bytes"]

which is lengthOf:baseHeader:format: rewritten not to reduce the byte size to slot count, and is of course equal to

byteSizeOf: oop
    | header format size |
    (self isIntegerObject: oop) ifTrue:[^0].
    header := self baseHeader: oop.
    format := self formatOfHeader: header.
    (header bitAnd: TypeMask) = HeaderTypeSizeAndClass
        ifTrue: [ size := (self sizeHeader: oop) bitAnd: LongSizeMask ]
        ifFalse: [ size := (header bitAnd: SizeMask)].
    size := size - (header bitAnd: Size4Bit).
    ^format < 8
        ifTrue: [ size - BaseHeaderSize "32-bit longs"]
        ifFalse: [ (size - BaseHeaderSize) - (format bitAnd: 3) "bytes"]

with the implementation for formatOfHeader: attached and used everywhere where ((format >> 8) bitAnd: 16rF) is used?

Cheers,
- Andreas

Additional Information

Attached Files

Relationships

Notes
(0013475 - 168 - 174 - 174 - 174 - 174 - 174) lewis 01-14-10 05:13	Interpreter>>byteLengthOf: looks questionable also. It is very similar to #lengthOf:, has only one sender, does not handle 64/32 bit word size, and is timestamped 1998.

(0013476 - 273 - 285 - 285 - 285 - 285 - 285) lewis 01-14-10 12:53	One more followup issue. InterpreterProxy>>byteSizeOf: needs to be updated to match Interpreter>>byteSizeOf:. Currently it still refers to 4 rather than #bytesPerWord. Whenever we have the agreed implementation for #byteSizeOf:, both classes need to be updated accordingly.

Issue History
Date Modified	Username	Field	Change
01-13-10 22:49	johnmci	New Issue
01-14-10 02:04	lewis	Issue Monitored: lewis
01-14-10 05:13	lewis	Note Added: 0013475
01-14-10 12:53	lewis	Note Added: 0013476

Mantis 1.0.8[^]

38 total queries executed.
29 unique queries executed.