Re: OPTION PROLOGUE:NONE not working

[Ratch]

y-code,

     I am an advocate of "PROCless" programming.  Have you tried that approach?  I see a lot of stamping of feet and gnashing of teeth when it comes to PROC usage.  So many problems, so few solutions.   Perhaps you would appreciate my way of doing things.   By the way, I am not joking.  Ratch

[hutch--]

ratch,

I have always been a little wary of this definition of a PROCless application. I suggest that if you use CALL / RET, you are just like the rest of us within the normal range of variation.

[PBrennick]

When you think about , though, Ratch makes a lot of sense.  If you are going to cripple the PROC, why the heck use it?  I am NOT a fan of using a PROC without a stack frame.  I guess it probably shows.  y-code, I am sorry I gave you a hard time.  It is just that I do not approve of what you are doing.  I say, do it without the PROCs or let the PROCs handle the stack.

Paul

[Ratch]

hutch-- ,

I have always been a little wary of this definition of a PROCless application. I suggest that if you use CALL / RET, you are just like the rest of us within the normal range of variation.

     When I say PROCless, I mean that I do NOT use the PROC, ENDP directive pair in my program.  That means that I have to manually do what those directives do, but it eliminates another layer of software that gets in between the programmer and the problem solution. 

PBrennick,

I am NOT a fan of using a PROC without a stack frame.

     I am sure you understand that I use a stack frame without a PROC.  It is a FLOATING stack frame that uses the ESP register, and it frees the EBP register for other usage.  Ratch
     

     

[hutch--]

Ratch,

I think this means you write procs in the normal manner without using the prebuilt MASM notation for it.

Code Select Expand


label:

  ; your asm code

    ret


With a stack frame,

Code Select Expand


    push ebp                                ; set up a stack frame
    mov ebp, esp

    sub esp, LOCAL_BYTE_COUNT

  ; your code

    leave
    ret PARAMETER_BYTE_COUNT


There are variations on the exit.

Sounds like you are just manually coding your own procedures, either with or without a stack frame.

[Vortex]

y-code,

Can you post your code so that we can simulate individually the problem to help you?

[Ratch]

hutch--,

I think this means you write procs in the normal manner without using the prebuilt MASM notation for it.

     Nope, I do not define a PROC, therefore I do not use it.  I miss out on all the benefits and the grief.  I do some of the tasks that a PROC does, as every program has to do, but that does not make my code a PROC.  And there is a lot of behind your back things a PROC does that I do not get involved with.  Remember, a PROC is more than a routine or subroutine.  It is a weapons system that can bite its creator.  Ratch

[hutch--]

Well,

If what you say is true, you are just renaming procedures to something else. Where I come from,

Code Select Expand


label

  ; your code

    ret


is a procedure. You can call them routines, subroutines or with a return value, a function but the general usage of procedure covers them all. All you are saying when you don't use the masm PROC / ENDP directives is that you code a procedure manually, this is useful but hardly anything new.

[Ratch]

hutch--

Code Select Expand


All you are saying when you don't use the masm PROC / ENDP directives is that you code a procedure manually


     I code some of its functionality manually, but the code I use and generate is quite different.  As I intimated before, wrapping a routine in a PROC/ENDP causes subtle changes in how MASM treats the assembly, that are different than with no PROC/ENDP pair.  Ratch

[AlchoholicSnake]

Code Select Expand


label

  ; your code

    ret

is a procedure.

That sure doesnt sound alot like thinking in asm to me at least. :P Why think of it as a procedure when you can actually just look at it as a label, code and a jump to esp? Not very high-level, but more fun that way dont you think? And you can do some pretty practical stuff that way so I know I'd rather do that.

And by the way y-code, I have actually experienced something very close to what you did, only with the VC2003 compiler, where it at a point seems to not compile a few sections over, and then the bugs I fix dont go away until after a few compilations or renaming, and then I ofcourse mean without the options of not compiling the whole code, so it is a bug there, but that is ofcourse totally unrelated to masm. Just thought I'd add that such bugs actually can exist, even though those who havent seen it happen usually see it as completely unlogical. :toothy

[hutch--]

There is nothing subtle about using PROC / ENDP, its result in masm is very clear and well understood, it constructs a stack frame, allocates local space and if there are stack parameters, it balances the stack on exit after a LEAVE instruction if it STDCALL. The variations are many, pass args on the stack, pass args in registers, pass args in global memory with or without a stack frame. Some algos need an extra register so you write it without a stack frame and if you are desperate, you copy ESP to memory and restore it later for 8 GP registers.

CALL / RET is built into the hardware so its not as if there is another way to construct a procedure. You can try messy direct jump in and out but you generally gain little.

Using or not using the inbuilt masm PROC / ENDP has nothing to do with writing procless code, masm internally has the OPTION PROLOGUE / EPILOGUE to do exactly that while preserving the prototype and invoke system. A procedure is still a branch, execute code and return and masm like any other basic mnemonic assembler can code pure mnemonic code which does not use the built in PROC system but unless the code you write is purely linear with no CALL / RET, it is procedural code like anything else.

[P1]

I think if the Phantom found out the name was misspelled, that person may need constant care.  :green

If you only knew, how many misspellings I have had to track down in code.  This would almost be laughable.  Then he would not be a phantom then?

Now, did I put that programmer's spell check at?

There are times when a call/ret makes sense for what your doing, but you lose the readability of the code with it versus coding in a proc.  But doing it that way for everything is for masochists.

Regards,  P1  :8)

[y-code]

If anyone cares what I think about all this...  :eek

From what I experienced, it looked as if something was caching information about the proc. I'd cut and pasted an existing proc from the code I'd downloaded here (a timing test in the Laboratory) and was making some modifications to test them. When I first realised it was ignoring the OPTION PROLOGUE:NONE/EPILOGUE:NONE I'd added around it, I went through line-by-line looking for anything that might be preventing it. As Tedd commented, a reference to a local variable (which I'd removed) or any of the parameters by name was an obvious culprit. But I'd already removed them and it was still doing it.

I tried inserting the proc at different positions in the code, nothing worked. Debugging it showed that it was consistently adding in the stack frame. The top of the proc was similar to this:

Code Select Expand

MyProc proc Param1:DWORD,Param2:DWORD,Param3:DWORD,Param4:DWORD

    push    edi
    push    esi
    push    ebx
    push    ebp
    mov    edi, [esp+28] ; Param3
    mov    esi, [esp+32] ; Param4

I'd replaced ALL the explicit references to parameters by name with direct stack references. Yet the assembler was replacing all the ESP references with EBP+offsets even though those were clearly wrong. However, further down in the proc, where I'd pushed a register and referred to it briefly by [ESP] before popping it later, it had left that reference which was clearly inconsistent.

That's when I posted here, I'd exhausted all possibilities of working out why it was doing this. And my original post clearly asked why it would ignore my directive. And all I did to "fix" it was to rename those parameters to something not referred in the original proc I'd copied from, which did have stack frames. And then renaming them back it continued to assemble fine, as I reported. It's very odd behaviour and certainly looks to me like a link between the two procs which shouldn't have existed was broken somehow.

However you look at this behavious it IS a bug. If I attempt to do something as trivial as read EAX from a .DATA location I've defined as a WORD and not a DWORD, the assembler throws an error, despite it being a valid memory location. It demands that I cast the location as a DWORD first. If I try and INVOKE a procedure like this:

Code Select Expand

    invoke  MyProc, eax, ADDR MyDataLocation
then it rightly notices that the EAX value will be trashed by calculating the ADDR, and throws an error to let me know.

Yet the assembler SILENTLY ignored my OPTION directive, which was there for a reason because the subsequent code I'd written wasn't compatible with a stack frame, and didn't tell me or flag it as an error. It replaced ESP references with EBP ones although I'd changed the value of EBP immediately before. That's a bug in my book given the way it otherwise nannies the code writer with stuff like I've jsut mentioned, it's not a "feature". Why it happened at all is another discussion that I still feel is worth exploring, but at the end of the day it wrongly assembled my proc and didn't tell me, leaving me to find out why with a debugger. It's not a laughing matter.

[Ratch]

hutch--,

.....Using or not using the inbuilt masm PROC / ENDP has nothing to do with writing procless code.....

    You are iterating and expanding on what you already said in reply #24.  My answer is still  reply #26.  Mimicking the functionality by alternative code is not the same as using the built in directives. For instance, writing out a constant 100 times in a .DATA segment is not the same as using a DUP 100 statement, even though the code generated is the same.  Ratch

[Ratch]

y-code,

....That's when I posted here, I'd exhausted all possibilities of working out why it was doing this. ....

     As I said and implied in my previous posts.  PROCs affect the code in different and subtle ways at times.  At least when you code something in a different way.  Unless you get a full listing, you are never quite sure what the code will be.  Also one has to wonder what the PROC is telling the assembler to do in order to surprise you.  That is why I never use  them.  Ratch