I used code like this: Procedure PROC ... call Further jmp end Further: ... ret end: ret When I compile this both RETs get compiled to LEAVE and then a RET. This causes the RET in Further: to not return to it's call, but to the call that called the procedure. Is it possible to tell the compiler to not add a LEAVE instruction at specific RETs?
Is Further also a PROC? Looks like it should work, if Further is a PROC... :) This message was edited by S/390, on 5/27/2001 1:14:17 AM
i had the exact same problem with calling a label inside a proc in my pelib (only in my case it was an enumeration proc, but nevermind). i solved it like this:
a bit dirty, but it works :P
Procedure PROC ... call Further jmp end Further: ... db 0C3h ; ret without masm garbage end: ret
fresh, you right, just replace ret with retn it is same as DB 0C3h Like this: Procedure PROC ... call Further jmp end Further: ... retn end: ret forge
So, would this work:
(Forgot code tags :rolleyes:) This message was edited by Qweerdy, on 5/27/2001 6:15:22 AM
xret MACRO db 0C3h xret ENDM xretn MACRO DB 0C3h xretn ENDM
Qweerdy, you have both macros same. Each of your macro = retn. Why to write a MACRO it is easier to use ret ; from your PROC and retn ; from your sub. Masm translate: ret ; to C2h plus xxxx for LEAVE and retn ; to C3h It is so simple. forge
The real problem here is not that MASM aliases ret into a macro. The problem is you're not using PROC as it expects. If you use PROC (which is already a macro), you can't stuff a seccond PROC inside it. PROCs don't nest. The solution is to keep seperate procs seperate:
As seperate procedures, all will work well. Also, nothing forces you to use PROC to define a procedure. You may manually establish your stack frame if you so choose by simply not using PROC. I'd advise not using PROC only in a rare special case, as stack frames are best left to the compiler. Frames are quite exacting in nature and mistakes may cause faults in other routines, are very hard to debug, and for all your trouble you're code will be an exact match to what MASM generates. In the anove example, "Further" terminates with a simple "ret" (opcode C3), not with a 'leave,' as MASM understood it didn't create a stack frame in that case.
Procedure PROC ... call Further ... ret Procedure ENDP Further PROC ... ret Further ENDP
Sorry to say so. I nested my sub into a procedure like this code, and I call it about 20 times and everything is OK. To me it better than repeat macro as with macro.
I may be wrong. But it work for me. forge
GraphPageGraphTextOut proc hWin :DWORD,hdc1 :DWORD, cxPage:DWORD, cyPage:DWORD .......... .......... .......... invoke SendMessage,SheetWHandle,WM_GETTEXT,10,addr SheetWidth_mm lea esi,SheetWidth_mm mov edi,esi call ASCIItoHex ;xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx .if edx!=0 ; If we have HEX .......... .......... .......... jmp overHEX ASCIItoHex: ; Convert ASCII to HEX number xor ebx,ebx xor edx,edx .......... .......... .......... retn ; xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx overHEX: .......... .......... .......... .......... .......... .......... invoke RestoreDC, hdc1, -1 ret GraphPageGraphTextOut endp
There is no problem calling an internal proc while within a normal MASM proc, as long as you dont try and nest normal procs. You also don't have to place a manually coded proc within the same proc that calls it if it is just a label followed later by a RET. You can build MASM library modules within a proc that have no parameters passed to them and you can write the code that receives the parameters in registers if you need it. I use the normal PROC method in most instances because its tidy and works OK but if I need code from elsewhere and don't want stack overhead, either writing it in a module with no parameters or just setting a location in code with a label + code followed by a RET works fine. Regards, firstname.lastname@example.org
writing it in a module with no parameters or just setting a location in code with a label + code followed by a RET works fine.I think ??? followed by a RETN works fine ---------------------------------------------------- I'm so confused and disoriented - I have to ask more. Question 1: What is a diference in here? and not from HLL point. procedure subroutine function label - (not the keyword) in disassembly they look the same. Question 2: What is a diference in here? retf retf 8 retn retn 8 ret ret 8 return 1 forge
For an explanation of the various returns, see www.hammick.com/hcs/returns.txt.
Thank you disease_2000 for answering question 1. Why did you erase your answer??????????????????? And thank you Larry Hammick for your supperior answer to my question number 2. It is a bit of treasure. Thanks again forge