Some question about SIZE and SIZEOF

[Marko]

Hello,

i am getting some confusion about SIZE and SIZEOF and also between LENGHT and LENGHTOF, while i getting different results when i assemble this pseudo istruction i can't understand where the diffrence are.

Some clarification would be very appreciated.

tnx
Marko

[ChrisLeslie]

The differences are quite clearly spelt out in the masm reference:

Syntax:   LENGTHOF variable

            SIZEOF variable

            SIZEOF type

            LENGTH expression

            SIZE expression

  Description:

     The LENGTHOF operator returns the number of data items allocated
     for <variable>. The SIZEOF operator returns the total number of
     bytes allocated for <variable> or the size of <type> in bytes. For
     variables, SIZEOF is equal to the value of LENGTHOF times the

     number of bytes in each element.

     The LENGTH and SIZE operators are allowed for compatibility with
     previous versions of the assembler. When applied to a data label,
     the LENGTH operator returns the number of elements created by the
     DUP operator; otherwise it returns 1. When applied to a data
     label, the SIZE operator returns the number of bytes allocated by
     the first initializer at the <variable> label.

     The LENGTHOF and SIZEOF operators in MASM 6.1 handle arrays much more

     consistently. These operators return the number of data items and the
     number of bytes in an initializer.
                                    -o-

So therefore an array of 10 DWORDs will have a LENGTHOF 10, but a SIZEOF 40 as there are 4 bytes in each DWORD.

Chris

[Marko]

i underastand now, another simple question if i have something like this ;

Code Select Expand


.data
test1 dw 0,0,0,0,0

.code
mov test1[2],0cccccccch


usually compiler coplain when i try to mov something that do not match in size but in that case the compiler just truncate the immediate value to  match the word size

[ChrisLeslie]

I may stand corrected, but I think that you are moving the DWORD value into the third byte position of test1, thereby spiltting the value across DWORD boundaries. Moving to test1[2*4] will probably align the DWORD to the third DWORD boundary of test1, if that is what you want.

Chris

[ChrisLeslie]

Sorry, I misread your test1 array as a DWORD array whereas it is a WORD array. However, the same principles apply, i.e. move to test1[2*2] will align to a WORD boundary. Your immediate value was DWORD in size though!

Chris

[Mark Jones]

Code Select Expand


.data
test1 dw 0,0,0,0,0

.code
mov test1[2],0cccccccch


Hi Marko, maybe this will help. During compilation, "test1" is converted to an offset inside the executable. Say that offset is 00401000h. MASM associates this offset with the word "test1" so every time you write "test1", it is really using that pointer. Now since you defined test1 as being of type WORD and gave it 5 values of zero, then you've actually created this:

Code Select Expand


00401000h:  00 00   00 00
00401004h:  00 00   00 00
00401008h:  00 00


Now your code,

Code Select Expand


.code
mov test1[2],0cccccccch


Really gets converted to this:

Code Select Expand


mov offset 00401000h[2],0cccccccch


Brackets can be confusing but here it simply means "add two." So this command is understood as:

Code Select Expand


mov offset 00401002h,0cccccccch


So starting at 00401002h, four bytes are written to that offset in memory. Remember however, that Intel architecure stores data in little-endian format, so those four bytes are stored in reverse-order.

Code Select Expand


00401000h:  00 00   CC CC
00401004h:  CC CC   00 00
00401008h:  00 00


Now if you read a DWORD value from offset "test1", can you see that it would read CCCC0000h?

Hope that helps.  :U

P.S., is there any reason why you're using 0CCCCCCCCh instead of say, 12345678h?

[Marko]

No reason they was the first value that camed to my mind, surely using 12345678h is a better value as example

tnx for the time


Edit : just a second i definded an array of WORD not double word

so there are only 10 bytes and not 20

[ChrisLeslie]

Hi Mark Jones

Glad that you can explain that more explicitly that I can!

Chris  :P

[MichaelW]

I consider this behavior to be a bug in MASM. When an assembler/compiler encounters an instruction/statement that cannot be encoded as specified it should return an error, instead of silently encoding something that is unlikely to be what the programmer intended. MASM returns an error if you attempt to load a value that is too large for a byte operand, and I can't think of any good reason to deviate from this behavior for word operands.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    .data
      testdb db 0,0,0,0
      testdw dw 0,0,0,0
      testdd dd 0,0,0,0
    .code
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    ; error A2070: invalid instruction operands
    ;mov   al, 012345678h

    ; error A2070: invalid instruction operands
    ;mov   al, 01234h

    ; error A2070: invalid instruction operands
    ;mov   testdb[0], 012345678h

    ; error A2070: invalid instruction operands
    ;mov   testdb[0], 01234h
   
    mov   testdb[0],012h

    movzx eax, testdb[0]
    print uhex$(eax),13,10              ; 00000012
    movzx eax, testdb[1]
    print uhex$(eax),13,10              ; 00000000
    movzx eax, testdb[2]
    print uhex$(eax),13,10              ; 00000000
    movzx eax, testdb[3]
    print uhex$(eax),13,10,13,10        ; 00000000

    mov   WORD PTR testdb[0], 012345678h

    movzx eax, testdb[0]
    print uhex$(eax),13,10              ; 00000078
    movzx eax, testdb[1]
    print uhex$(eax),13,10              ; 00000056
    movzx eax, testdb[2]
    print uhex$(eax),13,10              ; 00000000
    movzx eax, testdb[3]
    print uhex$(eax),13,10,13,10        ; 00000000

    mov   DWORD PTR testdb[0], 012345678h

    movzx eax, testdb[0]
    print uhex$(eax),13,10              ; 00000078
    movzx eax, testdb[1]
    print uhex$(eax),13,10              ; 00000056
    movzx eax, testdb[2]
    print uhex$(eax),13,10              ; 00000034
    movzx eax, testdb[3]
    print uhex$(eax),13,10,13,10,13,10  ; 00000012

    mov   ax, 012345678h
    cwd
    print uhex$(eax),13,10,13,10        ; 00005678

    mov   testdw[0], 012345678h

    movzx eax, testdw[0]
    print uhex$(eax),13,10              ; 00005678
    movzx eax, testdw[2]
    print uhex$(eax),13,10,13,10        ; 00000000

    mov   WORD PTR testdw[0], 012345678h

    movzx eax, testdw[0]
    print uhex$(eax),13,10              ; 00005678
    movzx eax, testdw[2]
    print uhex$(eax),13,10,13,10        ; 00000000

    mov   DWORD PTR testdw[0], 012345678h

    movzx eax, testdw[0]
    print uhex$(eax),13,10              ; 00005678
    movzx eax, testdw[2]
    print uhex$(eax),13,10,13,10        ; 00001234

    mov   WORD PTR testdd[0], 012345678h

    movzx eax, WORD PTR testdd[0]
    print uhex$(eax),13,10              ; 00005678
    movzx eax, WORD PTR testdd[2]
    print uhex$(eax),13,10,13,10        ; 00000000

    inkey "Press any key to exit..."
    exit
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start


[Mark Jones]

Edit : just a second i definded an array of WORD not double word

You're right, sorry, I realized this after posting it but could not correct it until today. :wink

Thanks Chris, well I think your quotation is about as explicit as it can get. :) I just converted it to it's Prime Factors. :toothy

Michael - any chance of getting Pelle to add this capability to POASM? (And do something with the silly brackets too...) :U

[Marko]

oh well there s no problems errors are the bread of my day too and explanation was very clear indeed  :dance:

best regards
Marko