Index
> Macroinstructions > [sug] Yet another PROC macro suggestion for freeing up EBPGoto page Previous 1, 2 |
| Would you like to integrate an ESP base proc macro into fasm? | |||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||
| Total Votes : 29 |
| Author |
|
|
IceStudent 07 Oct 2006, 12:01
revolution wrote: What format is that file in? My editor displays nonsense. Change file extension to ".chm". |
|||
07 Oct 2006, 12:01 |
|
|
vid 08 Oct 2006, 20:49
reverend: hehe, are you sure these are all instructions that can modify esp?
  |
|||
|
08 Oct 2006, 20:49 |
|
|
revolution 08 Oct 2006, 22:51
Reverend wrote: How about overloading all common instructions which modify esp? |
|||
|
08 Oct 2006, 22:51 |
|
|
revolution 11 Oct 2006, 23:05
Voting is currenty mostly in favour. With one person unsure and another would like to do it differently.
I am curious to hear from the person that voted for a different implementation as to what they are intending? Is it the discussion about adding the automatic adjustment for push/call etc.? If there is a better way to do it then I am keen to try it out. Please suggest here, thanks. It is also nice to see three (chocolate loving) people took the time to vote even though they had no interest. |
|||
|
11 Oct 2006, 23:05 |
|
|
Tomasz Grysztar 12 Oct 2006, 08:13
revolution wrote: Even the current proc macro has problems when using push/pop but people either don't notice or don't understand why it is a problem. If the assembly programmer doesn't balance the stack before doing RET, he's actually asking for problems. He might consider himself very lucky if it works just thanks to the particular implementation. revolution wrote: This could be easily fixed by including the prologue/epilogue code for all proc's that don't have input parameters or local variables. Initially it was done this way, but I changed it as I constantly received comments like "what does it set up this stack frame for here? it's not needed!" After I did it like it's now, I no longer receive any complaints.
See also comments in this thread, this was the main discussion of the current macros. Especially when they are complex and could cause the further additional slow-down. (BTW, i see the new movement of people going back to not using any macros for Win32 programming. Ah! I dreamed about it! )
In general, the "proc" macro in its current form tries to emulate as much as possible the TASM/MASM constructions - thus if you want the "noframe" proc, you do it just as the people do it with MASM.  Check out http://board.flatassembler.net/topic.php?t=5332
For any other kind of solutions I suggest making the dedicated separate sets of macros. |
|||
|
12 Oct 2006, 08:13 |
|
|
revolution 12 Oct 2006, 11:50
Tomasz Grysztar wrote: If the assembly programmer doesn't balance the stack before doing RET, he's actually asking for problems. He might consider himself very lucky if it works just thanks to the particular implementation. Code: cmp x,y jae .major_error_quit_now ;... .major_error_quit_now: ret Code: .clean_stack_and_quit: mov esp,ebp sub esp,stack_restore_reglist_size pop <reglist> leave ;or simply - pop ebp retn Tomasz Grysztar wrote: For any other kind of solutions I suggest making the dedicated separate sets of macros. Anyhow I still live in hope that something, anything, will become a defacto standard for esp based procs and people can post examples which others can compile without rewriting. Certainly I am open to all ideas about how to get things like this into the minds of assembly programmers. We can use our advantage of using the CPU directly to better effect when needed. |
|||
|
12 Oct 2006, 11:50 |
|
|
vid 12 Oct 2006, 12:03
Quote: If the assembly programmer doesn't balance the stack before doing RET, he's actually asking for problems. He might consider himself very lucky if it works just thanks to the particular implementation. |
|||
|
12 Oct 2006, 12:03 |
|
|
Tomasz Grysztar 12 Oct 2006, 12:19
Requiring to balance the stack is for me the only clean way of using the "proc" - just as if you were writing routine as a plain label with RETN instruction. If you want to poke inside the proc's stack frame yourself, you'd better not use the macros at all. Depending on the LEAVE to happen when you don't have this LEAVE written directly in your code is a bad programming IMO.
Or, following the MASM's way - include your own prologue and epilogue macros and then depend on the stack cleanup that they do. Well, this is also the reason why I haven't build such facilities into the assembler, but left them as macros. You can always blame just macros to be problematic, assembler stays clean. |
|||
|
12 Oct 2006, 12:19 |
|
|
vid 12 Oct 2006, 13:25
sure, i too use only to define arguments and locals. but sometimes getting stack back by hand is not that easy:
Code: push eax call something jc .error1 push eax call something jc .error2 push eax call something jc .error3 .error1 mov eax, ERR_1 add esp, 4 ret .error2: mov eax, ERR_2 add esp, 2*4 ret .error3: mov eax, ERR-3 add esp, 3*4 ret you see what i mean - it may be very hard to maintain such code |
|||
|
12 Oct 2006, 13:25 |
|
|
Tomasz Grysztar 12 Oct 2006, 13:37
I see nothing wrong with this, really. Well, if you have problem with tracing all your stack changes, you can make it like this:
Code: mov [frame],esp push eax call something jc .error1 .error1: mov eax, ERR_1 mov esp,[frame] ret You can find both such kinds of plays with stack in the fasm's source. No macros involved. |
|||
|
12 Oct 2006, 13:37 |
|
|
f0dder 12 Oct 2006, 13:43
Just remember that code like the above isn't re-entrant - hell if you write multithreaded code
 |
|||
|
12 Oct 2006, 13:43 |
|
|
Tomasz Grysztar 12 Oct 2006, 13:54
Well, the [frame] can be a local variable, no problem with that.
|
|||
|
12 Oct 2006, 13:54 |
|
|
f0dder 12 Oct 2006, 14:29
Tomasz Grysztar wrote: Well, the [frame] can be a local variable, no problem with that. Also if you want to free up EBP for computations? I guess it could work, with some fancy proc wizardry
(proc support for aligning the stack would be nice) _________________  - carpe noctem |
|||
|
12 Oct 2006, 14:29 |
|
|
revolution 12 Oct 2006, 14:47
Just to clarify for those readers that may be confused, I think the last few post here are discussing the unbalanced stack problem, not the esp base problem. Yes, probably my fault for mixing the two topics in my first post.
My personal feeling about the unbalanced stack problem is to do the push before the frame setup thus allowing exiting at any time without any extra hassle to restore the stack. While this is not that same as MASM or TASM, I think it is a better solution with less problems and that it outweighs the desire to be MASM/TASM compatible. This problem can be solved locally with a small amount of code by use of the "option" statement. So now I guess another question that arises is: should the push-before-frame be the fasm default or should we leave it as is and keep it MASM/TASM "standard"? |
|||
|
12 Oct 2006, 14:47 |
|
|
vid 12 Oct 2006, 15:58
tomasz: your solution wouldn't work without ebp anyway. and thus, you can use ebp directly and save yourself from having another local varaible
|
|||
|
12 Oct 2006, 15:58 |
|
|
Tomasz Grysztar 12 Oct 2006, 17:32
To both f0dder and vid: well, either you sacrifice EBP or you have to control your stack status strictly and carefully; there are no compromises.
PS. Well, of course you can allocate some area for local variables addressed with EBX or ESI, if you love to do things differently from the rest of world.  |
|||
|
12 Oct 2006, 17:32 |
|
|
f0dder 12 Oct 2006, 21:03
Well... what about TLS for saving the register? I guess that might work, although it would probably be more overhead than what it's worth
|
|||
|
12 Oct 2006, 21:03 |
|
| Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|