Index
> Main > push/pop default size modifier |
| Author |
|
|
LocoDelAssembly 04 Oct 2011, 14:40
I think it could be problematic at times to automatically break the ambiguity. You could relief the annoyance a bit by doing the following:
Code: label Debx dword at ebx label Qrbx qword at rbx |
|||
04 Oct 2011, 14:40 |
|
|
edfed 04 Oct 2011, 16:52
i am agree with yoshimitsu.
for the rest, i'm sorry... Last edited by edfed on 04 Oct 2011, 19:29; edited 2 times in total |
|||
|
04 Oct 2011, 16:52 |
|
|
Tomasz Grysztar 04 Oct 2011, 16:53
LocoDelAssembly wrote: I think it could be problematic at times to automatically break the ambiguity. You could relief the annoyance a bit by doing the following: You can try to go a bit further and do something like: Code: use32 push equ pushd use64 push equ pushq |
|||
|
04 Oct 2011, 16:53 |
|
|
edfed 04 Oct 2011, 17:04
in the fasm manual, there is also something about:
Code:
b equ byte
w equ word
d equ dword
q equ qword
|
|||
|
04 Oct 2011, 17:04 |
|
|
LocoDelAssembly 04 Oct 2011, 17:33
Tomasz, I forgot about those, but notice that doing so will make "push word 0 word [ebx]" (which would also maintain stack alignment) no longer work unless you use one of the other 15 ways to refer to the same instruction or you restore the equate. I know pushing 16-bit words is not really common but yet it is something that could happen.
|
|||
|
04 Oct 2011, 17:33 |
|
|
Tomasz Grysztar 04 Oct 2011, 17:45
Yes, it all depends on your usage scenario. In general case you'd have to stick with "pushd [ebx]".
Though, would it really cause problems if default size was used when operand is unsized memory reference? fasm already does such thing with "push imm" - so perhaps it in fact should get unified. |
|||
|
04 Oct 2011, 17:45 |
|
|
LocoDelAssembly 04 Oct 2011, 18:41
Well, you'd miss a somewhat important checking which not only prevents pushing more bytes than the programmer intended in the imm case, but you could also accidentally access more source bytes than it was intended (potentially causing even memory access faults).
The imm case is relatively fine the way it is now because of the CPU's default operand size and the fact that imms are unsized, but in the mem case you can no longer do this because memory operands are not unsized. It is fine to default the dest size, but I think it is not so OK to default source mem size and since the assembler needs to know both src and dest sizes then it should refuse to compile PUSH/POP. |
|||
|
04 Oct 2011, 18:41 |
|
|
Tomasz Grysztar 04 Oct 2011, 18:47
LocoDelAssembly wrote: (...)and the fact that imms are unsized |
|||
|
04 Oct 2011, 18:47 |
|
|
Tomasz Grysztar 04 Oct 2011, 18:53
Oh, I understood what did you mean - that for the imm it doesn't really matter what size it is in this case, as only the destination size is important for PUSH. For memory operand the source size matters too, and that why this check is needed. Thanks for reminding.
 |
|||
|
04 Oct 2011, 18:53 |
|
|
yoshimitsu 04 Oct 2011, 19:01
But as it's not even possible to "push byte [ebx]", I'd say the dword in "push dword [ebx]" is superfluous.
And as "push imm", "loop label", etc. are also default sized, push and pop should probably stick to it, as well. Btw. I still didn't really get what was meant with src and dest size.. Does dest refer to the stack in case of push/pop? And LocoDelAssembly says you still need to check src which would be either imm or mem, but checking is only needed when it's mem? Sorry, if I misunderstood.. |
|||
|
04 Oct 2011, 19:01 |
|
|
LocoDelAssembly 04 Oct 2011, 19:05
I mean the imm naked like "7" (without the quotes) which could be byte, word, dword or qword. Imms adapt their size to the dest like mov al, 7; mov ax, 7; mov eax, 7; mov rax, 7; in all these cases I don't need to tell the size of the imm itself (and actually I never need to, only the dest size needs to be specified since imposing a size over the imm affects the encoding only). The example I'm giving is also favoring using the default size somehow by replacing the 7s with mem, I know, but in the example the programmer is explicitly stating the size with the dest register, that is not something that is happening in the PUSH/POP where the processor supports two dest sizes in any mode and the programmer haven't specified any yet.
|
|||
|
04 Oct 2011, 19:05 |
|
|
Tomasz Grysztar 04 Oct 2011, 19:06
LolDelAssembly: but notice that there are cases, where it's the other operand that gets adapted to the imm size:
Code: mov [ebx],dword 7 |
|||
|
04 Oct 2011, 19:06 |
|
|
yoshimitsu 04 Oct 2011, 19:10
Yeah, but push/pop indirectly specifies the destination size which is either word or dword on x86.
But as push imm already becomes a dword-push and loop refers to loopd instead of loopw, I think there wouldn't be anything wrong making the default size of push mem dword, matching those other cases. Last edited by yoshimitsu on 04 Oct 2011, 19:14; edited 2 times in total |
|||
|
04 Oct 2011, 19:10 |
|
|
Tomasz Grysztar 04 Oct 2011, 19:13
yoshimitsu: please look at this example, it shows why it is important to ensure what the size of source is exactly.
Code: a dd 1 b dd 2 use64 push [a] ; assembler is able to catch your mistake lea rbx,[a] push [rbx] ; now it is not able to check, so it asks that you knowingly specify the size |
|||
|
04 Oct 2011, 19:13 |
|
|
edfed 04 Oct 2011, 19:22
uneeded bloat moved elswhere
 Last edited by edfed on 04 Oct 2011, 19:32; edited 1 time in total |
|||
|
04 Oct 2011, 19:22 |
|
|
yoshimitsu 04 Oct 2011, 19:25
Tomasz, is your example only fitting long mode assembling?
Code: a dw 1 use32 push [a] As this isn't erroneous. Btw. to resolve your code example's problem a zero padded 64-bit value would be needed, wouldn't it? Therefore not having a default size for push/pop would be more of a mistake-catcher, wouldn't it? |
|||
|
04 Oct 2011, 19:25 |
|
|
Tomasz Grysztar 04 Oct 2011, 19:26
edfed: it seems to me that you are making an unnecessary bloat out of this thread. Could you please move it elsewhere?
|
|||
|
04 Oct 2011, 19:26 |
|
|
Tomasz Grysztar 04 Oct 2011, 19:28
yoshimitsu: the same example for 32-bit case would look like:
Code: a db 1 b db 2 use32 push [a] ; assembler is able to catch your mistake lea ebx,[a] push [ebx] ; now it is not able to check, so it asks that you knowingly specify the size |
|||
|
04 Oct 2011, 19:28 |
|
|
l_inc 04 Oct 2011, 19:50
I agree, that at this point fasm's behaviour is reasonable. But what is fairly annoying, is non-unified macros behaviour regarding push/pushd usage. The following code will compile fine, which I personally find pretty convenient.
Code: use32 include 'win32a.inc' stdcall $,[ebx] But as soon as the include-file is changed to win32ax.inc, the compilation fails with unspecified operand size error. Same issue concerns also the invoke and ccall macros. |
|||
|
04 Oct 2011, 19:50 |
|
< Last Thread | Next Thread > |
Forum Rules:
|