flat assembler
Message board for the users of flat assembler.
Index
> Main > FASM CALL bytes ? |
Author |
|
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. |
|||
27 Sep 2010, 00:22 |
|
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? 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. |
|||
27 Sep 2010, 01:04 |
|
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 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. |
|||
27 Sep 2010, 02:18 |
|
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. |
|||
27 Sep 2010, 02:53 |
|
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... |
|||
27 Sep 2010, 04:31 |
|
janequorzar 27 Sep 2010, 13:52
revo1ution wrote: Just to re-iterate: 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. |
|||
27 Sep 2010, 13:52 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.