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:
Procedure PROC
...
call Further
jmp end
Further:
...
db 0C3h ; ret without masm garbage
end:
ret
a bit dirty, but it works :Pfresh,
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:
xret MACRO
db 0C3h
xret ENDM
xretn MACRO
DB 0C3h
xretn ENDM
(Forgot code tags :rolleyes:)
This message was edited by Qweerdy, on 5/27/2001 6:15:22 AMQweerdy,
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:
Procedure PROC
...
call Further
...
ret
Procedure ENDP
Further PROC
...
ret
Further ENDP
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.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.
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
I may be wrong.
But it work for me.
forgeThere 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,
hutch@pbq.com.au
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
forgeFor 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