flat assembler
Message board for the users of flat assembler.

Index > Main > FASM CALL bytes ?

Author
Thread Post new topic Reply to topic
janequorzar



Joined: 11 Sep 2010
Posts: 60
janequorzar 26 Sep 2010, 23:19
In FASM is CALL or rather just calling a Macro still 3 bytes pushed into the stack ? I have noticed that after so many calls, my programs goes into a tripple fault / locks up. Is this because FASM doesn't clear the 3 byte stack on a return from a macro ?

I have not had a problem with this in NASM, so since I am learning FASM, i'm trying to understand this.

example :

Code:

include 'somemacro.inc'

getsomethingdone    <--- from the past I have known this to use 3 Bytes pushed onto the stack.

pop ( a register )     < do I need to call pop 3 times to clear out the stack ?
pop ( a register )
pop ( a register )

hlt

--------------------------
( THIS IS THE MACRO INC FILE )

macro getsomethingdone
{
do something here
}
    


Has this been changed or is this still in effect ? Do I need to put a pop in there ?

I have not had to do this before, but I been noticing some strange behavior when I use MACROS in FASM.
Post 26 Sep 2010, 23:19
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 27 Sep 2010, 00:22
There is something odd here, how do you manage to push 3 bytes onto stack when actually only word, dwords and qwords (64-bit mode only) is possible?

pop reg instruction will work with 16-, 32- and 64-bit registers so any combination will either leave some bytes not popped out or you'll pop out one or more bytes in excess.

PS: I did not understand much what has this to do with macros so I better clarify also this:

Code:
macro clear [reg]{
forward
  xor reg, reg
}

clear eax, ebx, ecx, edx, esi, edi ; This does not affect the stack in any way at all, no bytes are never reserved in stack and none is freed neither.    
Post 27 Sep 2010, 00:22
View user's profile Send private message Reply with quote
janequorzar



Joined: 11 Sep 2010
Posts: 60
janequorzar 27 Sep 2010, 01:04
LocoDelAssembly wrote:
There is something odd here, how do you manage to push 3 bytes onto stack when actually only word, dwords and qwords (64-bit mode only) is possible?

pop reg instruction will work with 16-, 32- and 64-bit registers so any combination will either leave some bytes not popped out or you'll pop out one or more bytes in excess.

PS: I did not understand much what has this to do with macros so I better clarify also this:

Code:
macro clear [reg]{
forward
  xor reg, reg
}

clear eax, ebx, ecx, edx, esi, edi ; This does not affect the stack in any way at all, no bytes are never reserved in stack and none is freed neither.    




Yea, that was kinda my impression too. Here is why I ask... it has been documented that when you use a CALL ( which FASM doesn't use the actual term CALL but instead you call by just putting the name of the MACRO there ) it actually pushes the stack pointer decreased by 2. NOTE : This is a NEAR call.

But since we do not use RET in FASM, is it programmed in to increase the sp back up by two ?

And forgive me, I meant 2.. NOT 3.. I am overly worked.. lol

Thanks for any ideas on this. Right now, i'm not sure if FASM even uses a CALL / RET at all. So not sure what its doing yet.
Post 27 Sep 2010, 01:04
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 27 Sep 2010, 02:18
I think you have a little confusion here, macros are something handled by the preprocessing stage and consists in just expanding all references to them. In my example, what the assembling stage receives is the following:
Code:
xor eax, eax
xor ebx, ebx
xor ecx, ecx
xor edx, edx
xor esi, esi
xor edi, edi    
As you can see, there is no call to anywhere nor return, since macros are not called at run-time.

When you use CALL and RET, you are using the CPU instructions (unless macros with the same name were defined somewhere). A proc is a different thing (and not natively supported by fasm, you need to write macros to emulate them or use the ones provided in the Windows package), in that case, only a single copy of the code exists in the entire binary output and to invoke it you need to use the "stdcall" or "ccall" macro (depending on what calling convention you specified), or use plain PUSHes and CALL (and ADD to adjust stack pointer if you called a cdecl proc).

PS: If you are writting 16-bit code then the PROC macro in the Windows package will not be useful. I ported it once for 16-bit code and posted it in the forum but I don't remember where nor if the port was 100% correct.
Post 27 Sep 2010, 02:18
View user's profile Send private message Reply with quote
revo1ution



Joined: 04 Mar 2010
Posts: 34
Location: somewhere, twiddling something
revo1ution 27 Sep 2010, 02:53
Just to re-iterate:
Macros are not subroutines. They do not get CALL'd and RET'd from.
They are just replaced by in-line code during assembly.
So every instance of a macro just increases the size of the executable binary.
Post 27 Sep 2010, 02:53
View user's profile Send private message Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 796
Location: Massachusetts, USA
bitshifter 27 Sep 2010, 04:31
If you pushed 3 machinewords you can either pop them into a register
when done with them or just fixup the stack pointer manually...
Code:
push [x]
push [y]
push [z]
;do something...
pop (e)ax
pop (e)ax
pop (e)ax
    

Code:
push [x]
push [y]
push [z]
;do something...
add (e)sp, (sizeof_machineword * 3)
    

Note: The (e) signifies the difference between 16 and 32 bit registers...
Post 27 Sep 2010, 04:31
View user's profile Send private message Reply with quote
janequorzar



Joined: 11 Sep 2010
Posts: 60
janequorzar 27 Sep 2010, 13:52
revo1ution wrote:
Just to re-iterate:
Macros are not subroutines. They do not get CALL'd and RET'd from.
They are just replaced by in-line code during assembly.
So every instance of a macro just increases the size of the executable binary.


Yes, that is what I was wanting to know.. ok so its not adding extra bytes. Thank you.

LocoDelAssembly & bitshifter - Yes, I agree with what your saying. And it makes sense. But the info I got was from one of my old text books. And I was not sure if FASM was using a CALL or not. That was what I was confused about. revo1ution answered it for me.

I really appreciate the help. Thanks guys. Very Happy
Post 27 Sep 2010, 13:52
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-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.