Re: OPTION PROLOGUE:NONE not working

[y-code]

<SIGH> Where were all these helpful replies the other week when I was having bitmap problems... </SIGH>

[Ratch]

y-code,

<SIGH> Where were all these helpful replies the other week when I was having bitmap problems... </SIGH>

     And here I thought I was being helpful.  I did not suggest a solution that I would not apply myself if I had the same problem.  Ratch

[Mark Jones]

...hmmm.

Also remember the global jump label:

Code Select Expand


MyGlobalProc::
    ; code here...
    ret


[P1]

y-code,

You are new here.  The more we work this out, the more I realize.  You have not posted code that is doing anything or told us what we are working on.  Your last proc was MyProc.  You have been precise in what you needed to do, not like a normal new programmer looking for direction.  And from what I can tell, no stranger to binary level debugging.

Curious to know more about you and what we are working on.   Most professionals here introduce themselves and give us a little background information.

Regards,  P1  :8)

[hutch--]

Ratch,

I guess an example makes the point. Here is a module from the masm32 library that has no stack frame and no locals using standard masm procedure syntax including the original topic in the original Campus thread. This is both a procedure by manual coded definition and a PROC by masm definition, tell us how you are doing it any different.

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

align 4

OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

align 4

szLen proc src:DWORD

    mov eax, [esp+4]
    sub eax, 4

  @@:
    add eax, 4
    cmp BYTE PTR [eax], 0
    je lb1
    cmp BYTE PTR [eax+1], 0
    je lb2
    cmp BYTE PTR [eax+2], 0
    je lb3
    cmp BYTE PTR [eax+3], 0
    jne @B

    sub eax, [esp+4]
    add eax, 3
    ret 4
  lb3:
    sub eax, [esp+4]
    add eax, 2
    ret 4
  lb2:
    sub eax, [esp+4]
    add eax, 1
    ret 4
  lb1:
    sub eax, [esp+4]
    ret 4

szLen endp

OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««


[Ratch]

hutch--,

I guess an example makes the point. Here is a module from the masm32 library that has no stack frame....

     Well, it does have a stack frame.  It has a FLOATING stack frame using ESP instead of an ANCHORED stack frame using EBP.

This is both a procedure by manual coded definition and a PROC by masm definition

     It is a procedure because it has the PROC/ENDP directives wrapping it.  The procedure has some of its functionality disabled.  The disablement does not make it a procedure, the PROC/ENDP directives do.

...tell us how you are doing it any different.

     I'll be glad to.  The difference is that I am not using the PROC/ENDP directives.  Therefore the code will not show up in the cross reference table as a procedure.  Even though my code duplicates what your PROC does, it is not a PROC.  Both code snippets are subroutines, but only yours is a PROC.  That is because you have DEFINED your code to be a PROC through the directives, and I have not.  Whether you agree with my viewpoint or not, that is what I believe.  Ratch

Code Select Expand


B EQU BYTE PTR
ALIGN 4

szLen:
  MOV EAX, [ESP+DWORD]
  SUB EAX, DWORD

  .REPEAT
    ADD EAX, DWORD
    CMP B[EAX+0*BYTE],0
    JE LB1
    CMP B[EAX+1*BYTE],0
    JE LB2
    CMP B[EAX+2*BYTE],0
    JE LB3
    CMP B[EAX+3*BYTE],0
  .UNTIL ZERO?

  INC EAX
LB3:
  INC EAX
LB2:
  INC EAX
LB1:
  SUB EAX, [ESP+DWORD]
  RET DWORD



[hutch--]

Here is the difference you speak of, opcode for opcode exact match, your assertion on the PROC directive is simply mistaken. There is absolutely ZERO modification of the code manually written between the PROC / ENDP directives which have been disabled in terms of code generation but function to make the INVOKE syntax usable.

Pedantics are no match for semantics which you are trying to shift to make your code design sound different, you have done no more than manually code a procedure and that is something the rest of the world does on a regular basis.

Code Select Expand


00401020                    fn_00401020:                ; Xref 00401011
00401020 8B442404               mov     eax,[esp+4]
00401024 83E804                 sub     eax,4
00401027                    loc_00401027:               ; Xref 0040103F
00401027 83C004                 add     eax,4
0040102A 803800                 cmp     byte ptr [eax],0
0040102D 7430                   jz      loc_0040105F
0040102F 80780100               cmp     byte ptr [eax+1],0
00401033 7420                   jz      loc_00401055
00401035 80780200               cmp     byte ptr [eax+2],0
00401039 7410                   jz      loc_0040104B
0040103B 80780300               cmp     byte ptr [eax+3],0
0040103F 75E6                   jnz     loc_00401027
00401041 2B442404               sub     eax,[esp+4]
00401045 83C003                 add     eax,3
00401048 C20400                 ret     4
0040104B                    loc_0040104B:               ; Xref 00401039
0040104B 2B442404               sub     eax,[esp+4]
0040104F 83C002                 add     eax,2
00401052 C20400                 ret     4
00401055                    loc_00401055:               ; Xref 00401033
00401055 2B442404               sub     eax,[esp+4]
00401059 83C001                 add     eax,1
0040105C C20400                 ret     4
0040105F                    loc_0040105F:               ; Xref 0040102D
0040105F 2B442404               sub     eax,[esp+4]
00401063 C20400                 ret     4


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««

align 4

OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE

align 4

szLen proc src:DWORD

; -------------------------------------------------------------------------

    mov eax, [esp+4]
    sub eax, 4

  @@:
    add eax, 4
    cmp BYTE PTR [eax], 0
    je lb1
    cmp BYTE PTR [eax+1], 0
    je lb2
    cmp BYTE PTR [eax+2], 0
    je lb3
    cmp BYTE PTR [eax+3], 0
    jne @B

    sub eax, [esp+4]
    add eax, 3
    ret 4
  lb3:
    sub eax, [esp+4]
    add eax, 2
    ret 4
  lb2:
    sub eax, [esp+4]
    add eax, 1
    ret 4
  lb1:
    sub eax, [esp+4]
    ret 4

; -------------------------------------------------------------------------

szLen endp

OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef

; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««


[Ratch]

hutch--

Here is the difference you speak of, opcode for opcode exact match, your assertion on the PROC directive is simply mistaken.

     In what way?

There is absolutely ZERO modification of the code manually written between the PROC / ENDP directives which have been disabled in terms of code generation but function to make the INVOKE syntax usable

     So what if the generated code is the same an what can be served up by a PROC.  That does not make my code a PROC too.  Just the fact that my code cannot be called by INVOKE without some extra work shows that a PROC gives it something extra.

Pedantics are no match for semantics which you are trying to shift to make your code design sound different,

     My code is a copy of what you presented, with some minor improvements.  Precious little design is involved.   I am going with whether a PROC is defined before a call it a PROC.  Ratch

[hutch--]

The disassembly proves there is no diference between the code written and the code generated. You cannot hide behind the notion that the use of PROC changes something in the generated code because it does not, what it in fact does in conjunction with a prototype is give the assembler (note not the generated code) the information required to use the invoke syntax.

Now again, pedantics don't solve the problem of semantic shift that you are attempting, the word "procedure" is a very widely used term for a block of remote (from the caller) code that execution branches to with the return address stored on the stack. You can call it a function, sub, routine or anything else you can imagine but it fits the commonly used term "procedure" so all you are doing here is trying to aviod the name because masm has a higher level directive PROC / ENDP pair. Instead of claiming that you don't write procedures, you should be claiming that you don't use masm's high level procedure templates with the PROC / ENDP operators.

Now I have no problem with you not using a high level PROC / ENDP pair but claiming you are doing anything different to a manually code procedure does not hold water. Whether you write it in gas, fasm, goasm or anything else, a procedure by massive common usage is a procedure.

The code variation you have presented looks fine but its nothing unusual, it uses a fall through where the library code I posted in uses multiple exits, INC is slower that ADD and you process some extra instructions on the way through. 5 versus 3 at worst case.

[Ratch]

hutch--,

The disassembly proves there is no diference between the code written and the code generated. You cannot hide behind the notion that the use of PROC changes something in the generated code because it does not, what it in fact does in conjunction with a prototype is give the assembler (note not the generated code) the information required to use the invoke syntax.

     Why is the similarity of the generated code the criteria for whether something is a PROC or not?  Things other than code  generation happen differently when you use the PROC/ENDP directives, than when you don't. 

Now again, pedantics don't solve the problem of semantic shift that you are attempting, the word "procedure" is a very widely used term for a block of remote (from the caller) code that execution branches to with the return address stored on the stack. You can call it a function, sub, routine or anything else you can imagine but it fits the commonly used term "procedure" so all you are doing here is trying to aviod the name because masm has a higher level directive PROC / ENDP pair. Instead of claiming that you don't write procedures, you should be claiming that you don't use masm's high level procedure templates with the PROC / ENDP operators.

     Well, I claim both, because I think they are one and the same.  If I contained the return address and some parameters in registers without using the stack, would you call that a PROC?  Or what if I jumped to a subroutine and used memory other than the stack for parameters and return address?

Now I have no problem with you not using a high level PROC / ENDP pair but claiming you are doing anything different to a manually code procedure does not hold water. Whether you write it in gas, fasm, goasm or anything else, a procedure by massive common usage is a procedure

     The very fact that I have to do things manually is proof that I am not using a procedure.  The last clause of the above sentence is a circular definition.  By the way, I could name a mainframe that calls what WINTEL calls a MACRO a PROC (procedure).  That mainframe has no name or support for what WINTEL calls a procedure.  Ironically the name of their assembler is MASM (Meta-Assembler). It could generate code for different word sizes up to 72 bits as I recall, and op codes for different architectures.  It was infinitely flexible.  I worked for that company (UNISYS) for 17 years.  http://192.61.3.24/cfapps/inforep/topic.cfm?id=32&more=detail

The code variation you have presented looks fine but its nothing unusual, it uses a fall through where the library code I posted in uses multiple exits, INC is slower that ADD and you process some extra instructions on the way through. 5 versus 3 at worst case.

     I am not sure that INC is slower for a AMD Athlon, which I have.  And the INC instructions are only one byte.  Ratch

[hutch--]

ratch,

all you are doing here is trying to redefine a very commonly used term. You could call a "procedure" a routine but this will not help you in terms of claiming you are doing something different to manualy coding a procedure. Substitute "routine" or "function" or subroutine" or whatever you like, it is still addressing the same concept. Now if I have your redefinition correctly, you are performing a translation from "procedure" to "ratch_non_procedure" and using the same concept under a different label.

Anyone who has been around for a long time can code manual procedures with many variations but unless you are into branchless sequential code, you are (by any other name) writing procedures so the fundamental distinction you are trying to draw collapses to nothing. You are not doing anything different apart from mnemonic variation to what anyone else is doing.

Now noting that the original topic was about a masm operator "OPTION PROLOGUE" and how it is used to remove a stack frame, the posted identical code from what was written within this option to what disassembles is proof that what you write is what you get and there is no magic or mischief behind you back with what the assembler outputs. As I am sure you are aware, the sum total of assembler operators distinct from mnemonic output do not constitute assembled code, they are no more than directives to the assembler that outputs the code.

Now while I certainly encourage you to post advanced stack frame designs to help members writing more advanced code, I would ask that you don't flog these term definitions in the Campus where the rules prohibit it. If someone wants to learn to use standard masm procedures complete with the templating built into masm, that is of course their choice and even if you don't approve, the Campus is not the place to advance the alternatives. Thats what the other general purpose forums are for.

[Ratch]

hutch--,

You could call a "procedure" a routine but this will not help you in terms of claiming you are doing something different to manualy coding a procedure.

     Certainly I am doing something different when I don't use PROC/ENDP.  And certainly the concept of CALL/RET is, in that respect, the same.  The way I do it is different. 

You are not doing anything different apart from mnemonic variation to what anyone else is doing.

     True, the results are are the same, the way is different.

...they are no more than directives to the assembler that outputs the code.

     If not in this case, at other times directives can have a great influence on what the generated code will be.

... the Campus is not the place to advance the alternatives. Thats what the other general purpose forums are for.

     OK, no more  campus controversy.  This is the workshop.  Let's go at it.  Ratch

[GregL]

I prefer using PROC / ENDP, thank you very much. That goes for the other high-level directives too. I don't think anything substantial is gained by not using them. They are a convenience. If you don't want to use them, knock yourself out.

[lingo]

Ratch,

Why you hold unorthodox opinions in conflict with the dogma of the "Hutch's Assembly Flat Earth Society"?   :lol
Immediately go and delete your "unreadable and unreliable code" and start to learn  how to write "in assembly" in orthodox way... :lol

You can start to learn with "general purpose" masterpiece or (chef d'œuvre) here:
http://www.masm32.com/board/index.php?topic=6307.0

especially pay attention to:
   dec edx
   dec ecx
@@:
   add edx,1  :lol

[hutch--]

 :bg

Why do I hear sad violins playing ?  :boohoo:

> "Hutch's Assembly Flat Earth Society"

If you are going to try and quote me, at least get it right, I have gone on record in the past as saying "The world is SQUARE" (Look up the term from the 60s.)

Looking at the track record of which approach produced modern 32 bit assembler you are coming down on te side that made assembler a laughing stock with crappy unreadable unreliable and unextendable code. For someone who claims that their main development language is C++, I guess that yet another criticism of assembler programming is nothing uncommon from someone who is only willing to produce examples of the "gee whiz, aren't I clever" variety.