flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > [sug] Yet another PROC macro suggestion for freeing up EBP

Goto page Previous  1, 2

Would you like to integrate an ESP base proc macro into fasm?
Yes please, it is a good thing
64%
 64%  [ 18 ]
Yes, but it should operate differently
7%
 7%  [ 2 ]
Perhaps, I am unsure either way
7%
 7%  [ 2 ]
No thanks, it is evil
0%
 0%  [ 0 ]
Chocolate is yummy
21%
 21%  [ 6 ]
Total Votes : 28

Author
Thread Post new topic Reply to topic
IceStudent



Joined: 19 Dec 2003
Posts: 60
Location: Ukraine
IceStudent
revolution wrote:
What format is that file in? My editor displays nonsense.

Change file extension to ".chm".
Post 07 Oct 2006, 12:01
View user's profile Send private message Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Reverend
How about overloading all common instructions which modify esp? It would be push, pop, pushad, popad, <add esp, xxx>, <sub esp, xxx>, call, ret. Programmer will just have to know not to multiply esp, or change its value via mov or other instructions. Overloading these instructions would work only inside procedures and would change some equate (+/- 4 for example). It will later be used as a delta for all esp-based queries.
Post 08 Oct 2006, 20:32
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
reverend: hehe, are you sure these are all instructions that can modify esp?

Razz Wink
Post 08 Oct 2006, 20:49
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17281
Location: In your JS exploiting you and your system
revolution
Reverend wrote:
How about overloading all common instructions which modify esp?
That would not be enough, any macro would need to analyse the code to make a proper job. I tried to explain the reason for this in a previous post.
Post 08 Oct 2006, 22:51
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17281
Location: In your JS exploiting you and your system
revolution
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.
Post 11 Oct 2006, 23:05
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
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. Wink

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! Wink )

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. Cool 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.
Post 12 Oct 2006, 08:13
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17281
Location: In your JS exploiting you and your system
revolution
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.
Yes, I agree 100% with that, but just sometimes, if one wants to, they can place ...
Code:
 cmp x,y
 jae .major_error_quit_now
 ;...
.major_error_quit_now:
 ret    
... and not have to concern oneself with how many parameters or call levels we need to skip before the "pop <reglist>". Of course this is usually considered bad programming by many but since we are assembly programmers we like to do such things because it is clear and simple. Having to properly "clean" the stack might actually generate bugs with complicated "stack repair" code. One possible repair code that pops to mind is this:
Code:
.clean_stack_and_quit:
 mov esp,ebp
 sub esp,stack_restore_reglist_size
 pop <reglist>
 leave ;or simply - pop ebp
 retn    
But it would be nicer to have a macro that just "gets it right" without having to worry oneself with small minutae.

Tomasz Grysztar wrote:
For any other kind of solutions I suggest making the dedicated separate sets of macros.
Yes, I'm sure we all have our own particular set of macros that we use and love. I know I do. So far there seems to be no standard or official way of getting an esp based proc defined.

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.
Post 12 Oct 2006, 11:50
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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.
Not always... requiring to balance stack either disallows you to use push / pop / dynamic stack allocation, or it dirties your epiloque... and it is not that easy with more complex error handling.
Post 12 Oct 2006, 12:03
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
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. Wink
Post 12 Oct 2006, 12:19
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
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
Post 12 Oct 2006, 13:25
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
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.
Post 12 Oct 2006, 13:37
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Just remember that code like the above isn't re-entrant - hell if you write multithreaded code Smile
Post 12 Oct 2006, 13:43
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
Well, the [frame] can be a local variable, no problem with that. Wink
Post 12 Oct 2006, 13:54
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Tomasz Grysztar wrote:
Well, the [frame] can be a local variable, no problem with that. Wink

Also if you want to free up EBP for computations? I guess it could work, with some fancy proc wizardry Smile

(proc support for aligning the stack would be nice)

_________________
Image - carpe noctem
Post 12 Oct 2006, 14:29
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17281
Location: In your JS exploiting you and your system
revolution
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"?
Post 12 Oct 2006, 14:47
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
tomasz: your solution wouldn't work without ebp anyway. and thus, you can use ebp directly and save yourself from having another local varaible
Post 12 Oct 2006, 15:58
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7725
Location: Kraków, Poland
Tomasz Grysztar
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. Wink


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. Very Happy
Post 12 Oct 2006, 17:32
View user's profile Send private message Visit poster's website Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
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 Smile
Post 12 Oct 2006, 21:03
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< 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.