flat assembler
Message board for the users of flat assembler.

Index > Main > push/pop default size modifier

Author
Thread Post new topic Reply to topic
yoshimitsu



Joined: 07 Jul 2011
Posts: 96
yoshimitsu
Hi,
just a quick question:
Wouldn't it be plausible, to give push and pop a default size modifier such as dword for x86 and qword for x64 since the stack is also aligned to those values.
Because its kind of ugly and annoying to always have to write "push dword [ebx]"
Post 04 Oct 2011, 14:23
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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    
Now "push [Debx]" and "push [Qrbx]" will be equivalent to "push dword [ebx]" and "push qword [rbx]" respectively.
Post 04 Oct 2011, 14:40
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
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
Post 04 Oct 2011, 16:52
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7750
Location: Kraków, Poland
Tomasz Grysztar
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:
Code:
label Debx dword at ebx
label Qrbx qword at rbx    
Now "push [Debx]" and "push [Qrbx]" will be equivalent to "push dword [ebx]" and "push qword [rbx]" respectively.

You can try to go a bit further and do something like:
Code:
use32
push equ pushd

use64
push equ pushq    
These mnemonics are there for you to use them.
Post 04 Oct 2011, 16:53
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
in the fasm manual, there is also something about:
Code:
b equ byte
w equ word
d equ dword
q equ qword
    
Post 04 Oct 2011, 17:04
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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.
Post 04 Oct 2011, 17:33
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7750
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 04 Oct 2011, 17:45
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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.
Post 04 Oct 2011, 18:41
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7750
Location: Kraków, Poland
Tomasz Grysztar
LocoDelAssembly wrote:
(...)and the fact that imms are unsized
Imms are sized just as memory operands are. Or perhaps I do not understand what did you mean by this.
Post 04 Oct 2011, 18:47
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7750
Location: Kraków, Poland
Tomasz Grysztar
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. Smile
Post 04 Oct 2011, 18:53
View user's profile Send private message Visit poster's website Reply with quote
yoshimitsu



Joined: 07 Jul 2011
Posts: 96
yoshimitsu
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..
Post 04 Oct 2011, 19:01
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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.
Post 04 Oct 2011, 19:05
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7750
Location: Kraków, Poland
Tomasz Grysztar
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    
Post 04 Oct 2011, 19:06
View user's profile Send private message Visit poster's website Reply with quote
yoshimitsu



Joined: 07 Jul 2011
Posts: 96
yoshimitsu
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
Post 04 Oct 2011, 19:10
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7750
Location: Kraków, Poland
Tomasz Grysztar
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    
Post 04 Oct 2011, 19:13
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4240
Location: 2018
edfed
uneeded bloat moved elswhere Wink


Last edited by edfed on 04 Oct 2011, 19:32; edited 1 time in total
Post 04 Oct 2011, 19:22
View user's profile Send private message Visit poster's website Reply with quote
yoshimitsu



Joined: 07 Jul 2011
Posts: 96
yoshimitsu
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?
Post 04 Oct 2011, 19:25
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7750
Location: Kraków, Poland
Tomasz Grysztar
edfed: it seems to me that you are making an unnecessary bloat out of this thread. Could you please move it elsewhere?
Post 04 Oct 2011, 19:26
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7750
Location: Kraków, Poland
Tomasz Grysztar
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    
Post 04 Oct 2011, 19:28
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
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.
Post 04 Oct 2011, 19:50
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.