flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
jkhjklhgl
I get 'operand sizes do not match'.
Code: mov [timer_start],eax mov [timer_start+4],edx section '.data' data readable writeable timer_start rq 1 |
|||
![]() |
|
cod3b453
The natural size of timer_start is qword so you'll want to use the dword override:
Code: mov dword [timer_start],eax mov dword [timer_start+4],edx |
|||
![]() |
|
jkhjklhgl
But eax has 32 bits and I'm generating 32 bit code. The operation can only be 32 bits, so why demand the use of 'dword'?
|
|||
![]() |
|
jkhjklhgl
JohnFound wrote: Because the compiler is not sure you really want to write 32bit register to 64bit variable. You could misspell the names of similar named variables, for example. JohnFound wrote: Or you redefined the variable from 32 to 64 bit and then forgot to change the mov instruction from eax to rax. |
|||
![]() |
|
system error
timer_start is a 64-bit operand. EAX is a 32-bit operand. So "operand size doesn't match" pretty much sums it up. Rule of mov - two operands must be of equal size.
You can make it as an 32-bit operand by using a 32-bit pointer as operand, so this can save you the dword directive. Code: mov ebx,timer_start mov [ebx],eax |
|||
![]() |
|
jkhjklhgl
Maybe it's better to write:
Code: timer_start rd 2 |
|||
![]() |
|
l_inc
jkhjklhgl
That would be exactly my answer. The point is not what kind of code (16-, 32- or 64-bit) you write. The point is how you declare your variables. Declarations indicate what kind of variable you have and if that kind does not match the operation you try to apply to it, then the compiler complains. That the compiler "is not sure" is not correct in this case. It's quite sure that you're using a wrong operation unless you forcefully make it shut up with a size override operator. For that reason the change in the declaration is a much better idea as it needs no enforcement and allows the compiler to perform the size check. _________________ Faith is a superposition of knowledge and fallacy |
|||
![]() |
|
cod3b453
While it could infer the 32bit dword encoding there are many possible ambiguities that would otherwise be missed:
use32 vs use64/mov vs mov{s|z}x/Exx vs Rxx mov (gpr) vs movq (mmx) natual size (qword) vs explicit qualifier (dword) semantically incoherent halves (non-atomic modification) A further option is to make use of a union that has both the full 64bit value and its 32bit sub-components so that natural encodings can be selected. |
|||
![]() |
|
revolution
jkhjklhgl wrote: Maybe it's better to write: |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.
Website powered by rwasa.