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
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.
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
hutch-- ,
Quote
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,
Quote
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
Ratch,
I think this means you write procs in the normal manner without using the prebuilt MASM notation for it.
label:
; your asm code
ret
With a stack frame,
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.
y-code,
Can you post your code so that we can simulate individually the problem to help you?
hutch--,
Quote
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
Well,
If what you say is true, you are just renaming procedures to something else. Where I come from,
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.
hutch--
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
Quote from: hutch-- on April 27, 2006, 05:22:28 AM
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
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.
Quote from: hutch-- on April 27, 2006, 12:23:19 AM
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)
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:
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:
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.
hutch--,
Quote
.....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
y-code,
Quote
....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
<SIGH> Where were all these helpful replies the other week when I was having bitmap problems... </SIGH>
y-code,
Quote
<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
...hmmm.
Also remember the global jump label:
MyGlobalProc::
; code here...
ret
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)
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.
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
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
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
hutch--,
Quote
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.
Quote
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.
Quote
...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
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
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.
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
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
hutch--
Quote
Here is the difference you speak of, opcode for opcode exact match, your assertion on the PROC directive is simply mistaken.
In what way?
Quote
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.
Quote
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
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.
hutch--,
Quote
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.
Quote
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?
Quote
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
Quote
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
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.
hutch--,
Quote
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.
Quote
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.
Quote
...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.
Quote
... 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
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.
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
: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.
Take it easy Hutch,
I like the violins playing too but
I don't afraid to die at the stakes as a heretic... :lol
Greg,
QuoteI prefer using PROC / ENDP, thank you very much.
Your are welcome. No one is forced to use any MASM method within the privacy of their own computer.
QuoteThat goes for the other high-level directives too.
Certainly!
QuoteI don't think anything substantial is gained by not using them.
I guess you missed the reason stated earlier, that parameters can sometimes be pushed on the stack earlier when they might be available, instead of having store the parameters and let the PROC do it when it is time to call the subroutine. And don't forget the amount of time and bandwidth expended explaining to nubes why PROCs don't work the way they think they should. A simple search on PROCs within this forum will confirm that statement. Also, with cascaded calls to subroutines, do PROCs allow the called subroutine to use the parameters of the previous subroutines, or does one have to PUSH those parameters again on the stack for the called PROC to use? And last but not least, PROCs use up a precious register (EBP) of a already register starved CPU, which has be to saved and restored if used.
QuoteThey are a convenience. If you don't want to use them, knock yourself out.
An unneeded crutch in my humble opinion. I get along just fine without them, without knocking myself out. The STRUCT directive keeps track of the relative positions of the parameters of the dynamic stackframe. Ratch
lingo,
QuoteWhy you hold unorthodox opinions in conflict with the dogma of the "Hutch's Assembly Flat Earth Society"?
Don't ask me, ask Christopher Columbus.
QuoteImmediately go and delete your "unreadable and unreliable code" and start to learn how to write "in assembly" in orthodox way...
Where is it written in stone about what is the "orthodox way"? Just because Uncle Bill bestowed PROCs to you does not mean you have to use them.
QuoteYou 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
I cannot for the life of me ascertain what is masterful about that code, or what that link is supposed to illustrate. Perhaps you can elucidate. Ratch
If someone wants to get good at programming with MASM, they should learn how to program without using the high-level directives. After you learn that, unless you really need to optimize some code, there is no reason to not take advantage of the high-level directives.
If you don't want to use them, fine, don't use them. But don't belittle others for doing so. It doesn't make your code superior, in fact, it could be argued that it does the opposite.
Greg,
QuoteIf someone wants to get good at programming with MASM, they should learn how to program without using the high-level directives.
What is a high level directive? High level with respect to what? Is PROC/ENDP high level? If so, why? I never said that one should not use "high level" directives. I only stated that I, repeat I, did not find PROC/ENDP helpful. Other directives like MACRO are about as "high" as you can get, and you never saw me write anything against them in general.
QuoteIf you don't want to use them, fine, don't use them. But don't belittle others for doing so. It doesn't make your code superior, in fact, it could be argued that it does the opposite.
A recommendation of using a particular method does not belittle anyone not using that method. It calls attention to a new way of doing things that others can either accept or reject. I challenge you to find any past posts where I said someone was wrong for not using my method. If I aver my method to be superior, then I give reasons why it is, and you can challenge those reasons. Otherwise, you are mischaracterizing what I am doing. Ratch
:bg
> I don't afraid to die at the stakes as a heretic...
We only light the fire if anyone wants to preach in the Campus, the rest of the place is well geared for heresy. :P
Ratch,
Having heard most of this stuff before, answer this question for us as in the topic about the MASM operator "OPTION PROLOGUE".
With code like,
; -------------------------------------------------------------------------
OPTION PROLOGUE:NONE
OPTION EPILOGUE:NONE
MyProc proc arg1:DWORD
mov ecx, [esp+4]
; write asm code here
retn 4
MyProc endp
OPTION PROLOGUE:PrologueDef
OPTION EPILOGUE:EpilogueDef
What is the difference in terms of code generation in MASM with the following code ?
; -------------------------------------------------------------------------
MyProc:
mov ecx, [esp+4]
; write asm code here
retn 4
; -------------------------------------------------------------------------
I will save you the trouble of answering, it is NOTHING. What you need to do is learn enough MASM to know how the OPTION PROLOGUE operator works.
Why bother to use the OPTION PROLOGUE style of code ?
The answer to this one is simple as well, it allows a prototype to be written so the use can use the standard invoke syntax.
All of the older programmers know how to write stack frame free procedures in pure mnemonics so its not as if its a big deal to be able to do so, there are a reasonable number of deviations that are more or less well known for passing values to a procedure, globals, stack frame, arrays, structures, arrays of structures etc etc etc .....
Quote from: Ratch on March 29, 2007, 02:09:23 AM
...that parameters can sometimes be pushed on the stack earlier when they might be available, instead of having store the parameters and let the PROC do it when it is time to call the subroutine.
That's why I use PUSH/CALL a lot, rather than INVOKE (I push all my WNDCLASSEX stuff onto the stack for RegisterClassEx) - makes more sense to me.
As for the OPTION PROLOGUE thing, surely it only applies if you use PROC/ENDP and not myproc:
hutch--
QuoteWhy bother to use the OPTION PROLOGUE style of code ?
So that when you use PROC/ENDP, you do not get all the setup code at the beginning of the subroutine. I don't use PROC/ENDP, so I don't use OPTION PROLOGUE either. Just more red tape as far as I am concerned.
QuoteThe answer to this one is simple as well, it allows a prototype to be written so the use can use the standard invoke syntax.
PROC/ENDP, OPTION PROLOGUE and OPTION EPILOGUE are not needed for PROTO and INVOKE. I use the INVOKE syntax, and sometimes my own invoke macro INV0KIT within the same file, and they both work fine without PROC/ENDP, OPTION PROLOGUE and OPTION EPILOGUE .
QuoteAll of the older programmers know how to write stack frame free procedures in pure mnemonics so its not as if its a big deal to be able to do so, there are a reasonable number of deviations that are more or less well known for passing values to a procedure, globals, stack frame, arrays, structures, arrays of structures etc etc etc .....
The methods are only limited by one's imagination. Ratch
sinsi,
QuoteThat's why I use PUSH/CALL a lot, rather than INVOKE (I push all my WNDCLASSEX stuff onto the stack for RegisterClassEx) - makes more sense to me.
I use a roll my own MACRO called INVOKIT which PUSHes parameters onto the stack in reverse order and then CALLs the subroutine. It is not guided by PROTO, and therefore does not warn me about the number of parameters PUSHed. I too PUSH the RegisterClassEx parameters onto the stack and then add the to the ESP register to get rid of the parameters after RegisterClassEx has been called. No need to keep WNDCLASS around taking up space if it is only going to be used once.
QuoteAs for the OPTION PROLOGUE thing, surely it only applies if you use PROC/ENDP and not myproc:
Right on. Ratch
hmmmm,
> Just more red tape as far as I am concerned.
So the reason for not using PROC/ENDP and OPTION PROLOGUE is not technical but a personal disposition, it can do nother better than direct manual mnemonic coding and is nothing more than a sales pitch for a particular coding technique.
> I too PUSH the RegisterClassEx parameters onto the stack and then add the to the ESP register to get rid of the parameters after RegisterClassEx has been called.
But why would you use such an inefficient technique that does its stack adjustments after each function call rather than doing it in one instruction at the end of the Proc ? The whole purpose of using LOCAL or what are often called automatic variables is so you don't write sloppy code that does them sequentially instead of the efficient way at the end.
One trailing stack adjustment at the end of the proc is far more efficient than adjusting the stack after each function call.
hutch--,
QuoteSo the reason for not using PROC/ENDP and OPTION PROLOGUE is not technical but a personal disposition.
It is partly technical. See reply #31 of this thread for some technical reasons. Because of those technical reasons, I like it.
Quoteit can do nother better than direct manual mnemonic coding
I think my method is quite direct and more manual. More so than PROC/ENDP. Of course direct manual coding can do anything. It is just a question of coding difficulity and resource tradeoffs.
Quoteand is nothing more than a sales pitch for a particular coding technique.
Nothing to sell, nothing to buy, no profit involved. Just a good faith advocacy of a method I think is better, at least for me. Everyone has to decide for themselves if the method is for them.
QuoteBut why would you use such an inefficient technique that does its stack adjustments after each function call rather than doing it in one instruction at the end of the Proc ? The whole purpose of using LOCAL or what are often called automatic variables is so you don't write sloppy code that does them sequentially instead of the efficient way at the end.
1) That particular API, RegisterClass, is usually called only once in a program, so it does not have to be top efficient.
2) It does not leave dead storage (WNDCLASS) lying around in memory for the life of the program.
3) I don't have to PUSH the parameters sequentially for WNDCLASS. I can write them to the stack directly and out of order using the WNDCLASS structure.
4) RET XXX does the same thing as (ADD ESP,XXX) , albeit slightly more efficiently. Not enough to matter though.
Ratch
:bg
> It is partly technical.
It either is or it ain't and I sugest that if you understand how the OPTION PROLOGUE operators work in relation to PROC / ENDP you would not make these claims.
> I think my method is quite direct and more manual. More so than PROC/ENDP.
Same problem of you not understanding the OPTION PROLOGUE operators in MASM.
> Nothing to sell, nothing to buy, no profit involved. Just a good faith advocacy of a method I think is better, at least for me.
A sales pitch by any other name is still a sales pitch and it is for a technique that cannot do anything that the PROC / ENDP operators cannot do using the OPTION PROLOGUE operator.
Quote
1) That particular API, RegisterClass, is usually called only once in a program, so it does not have to be top efficient.
2) It does not leave dead storage (WNDCLASS) lying around in memory for the life of the program.
3) I don't have to PUSH the parameters sequentially for WNDCLASS. I can write them to the stack directly and out of order using the WNDCLASS structure.
4) RET XXX does the same thing as (ADD ESP,XXX) , albeit slightly more efficiently. Not enough to matter though.
1) So lousy code is justified if you only use it once no matter how inefficient it is.
2) The stack is already pre-allocated, dead storage in this context is nonsense.
3) You are confusing your own view of allocating from the stack and freeing it after the function call with pushing arguments in sequence. Your method of allocating from the stack then deallocating it directly after the function call is SEQUENTIAL where the normal method of writing to local or automatic variables is far more efficient and only requires the stack to be balanced at the end of the PROC.
4) "RET XXX does the same thing as (ADD ESP,XXX)" This is nonsense, a RET(N) branches back to the following instruction after the CALL and if it uses the trailing WORD size number it corrects the stack as well. Adding to the stack pointer only corrects the stack.
RET and CALL are balanced opcodes on any of the later processors so using any technique that interferes with this balance is again very inefficient coding practice.
It seems that you are willing to throw away many more efficient programming techniques on the alter of flogging a method that by your own admission is inefficient when the normal PROC / ENDP suffers none of the problems that your own method does. Freestyle architecture goes towards full manual mnemonic coding, not pre-canned methods that have a number of buit in inefficiencies contained within its design.
hutch--,
QuoteIt either is or it ain't and I sugest that if you understand how the OPTION PROLOGUE operators work in relation to PROC / ENDP you would not make these claims.
Not everything in this world is on/off, black/white. When I said that my reasons for not using PROC/ENDP were partly technical, that is what I meant. No arguments you countered with prove otherwise. My dislike for PROC/ENDP is technical for reasons already given, and personal for the extra red tape they cause. Combine the two, and you get partial technical and partial personal.
QuoteSame problem of you not understanding the OPTION PROLOGUE operators in MASM.
Wrong, not much to understand. It either adds or suppresses beginning/prolog code, which I don't need.
QuoteA sales pitch by any other name is still a sales pitch and it is for a technique that cannot do anything that the PROC / ENDP operators cannot do using the OPTION PROLOGUE operator.
It is a pitch, but not a sales pitch. Don't you see the distinction? And are you not "pitching" the PROC/ENDP directives which cannot do some things my method can do, and is less flexible for the reasons given earlier.
Quote1) So lousy code is justified if you only use it once no matter how inefficient it is.
You have to prove that it is lousy code. So far you have not done that. Why would it be lousy code to put the parameters for RegisterClass on the stack instead of a .DATA or .DATA? segment? All CALLs to APIs do that.
Quote2) It does not leave dead storage (WNDCLASS) lying around in memory for the life of the program.
It does if you put the parameters in a .DATA(?) segment. Unless you reuse the WNDCLASS storage for something else.
Quote3) You are confusing your own view of allocating from the stack and freeing it after the function call with pushing arguments in sequence. Your method of allocating from the stack then deallocating it directly after the function call is SEQUENTIAL where the normal method of writing to local or automatic variables is far more efficient and only requires the stack to be balanced at the end of the PROC.
Nothing wrong with being sequential. The "normal" method of reading/writing to a PROC/ENDP stackframe is to use an offset with respect to EBP, whereas my method uses ESP. Are you saying that EBP is far better or far faster? At the expense of using the EBP register? And one has to save/restore EBP and balance the stack at the end, too. I think you should explain what you mean a little better.
Quote4) "RET XXX does the same thing as (ADD ESP,XXX)" This is nonsense, a RET(N) branches back to the following instruction after the CALL and if it uses the trailing WORD size number it corrects the stack as well. Adding to the stack pointer only corrects the stack.
RET and CALL are balanced opcodes on any of the later processors so using any technique that interferes with this balance is again very inefficient coding practice.
Of course I know that RET XXX returns back to where it was called after balancing the stack. I would not be able to do what I do unless I did know that. What I should have made clearer is that RET XXX does an effective (ADD ESP,XXX) before it returns. My method does a call/ret XXX sequence, so no problem with balancing the call/ret sequence either.
QuoteIt seems that you are willing to throw away many more efficient programming techniques on the alter of flogging a method that by your own admission is inefficient when the normal PROC / ENDP suffers none of the problems that your own method does. Freestyle architecture goes towards full manual mnemonic coding, not pre-canned methods that have a number of buit in inefficiencies contained within its design.
Not at all. I never said my code was inefficient. You did. I believe my method is more efficient because it uses fewer resources (no EBP usage and overhead), and is more flexible, especially in cascaded calls. Why don't we compare a simple coding by your method and my method? Ratch
:bg
> Not everything in this world is on/off, black/white.
The truth of a statement is, its called the "Law of excluded middle".
> When I said that my reasons for not using PROC/ENDP were partly technical, that is what I meant.
Not in the context of the topic, the use of OPTION PROLOGUE renders your arguments nonsense. You may have a dispositional problem with the standard MASM notation but using OPTION PROLOGUE/EPILOGUE to turn off the generation of a stack frame makes ALL of your arguments nonsense. The PROC / ENDP then serve a different purpose, that of being the MASM defined model of the procedure that is matched with a prototype for the procedure.
You may whinge about the extra "red tape" but it is THE MASM defined method of writing a stack frame free procedure that still has a working standard MASM prototype. To make the point again, there is NO DIFFERENCE in the code generation between a fully manually coded procedure and the code that is generated between the OPTION PROLOGUE/EPILOGUE operators but the standard MASM method of creating a prototype works as it was designed to work.
> And are you not "pitching" the PROC/ENDP directives which cannot do some things my method can do, and is less flexible for the reasons given earlier.
I am "pitching" the standard MASM method of using PROC / ENDP either with OR without the OPTION PROLOGUE/EPILOGUE operators depending on what you require. One generates a standard MASM stack frame procedure, the other generates EXACTLY what you write between the operators but with the added advantage that it allows a standard MASM prototype and collectively this pair of techniques are exhaustive. Your claim that there is a technical reason NOT to use PROC / ENDP in conjunction with the OPTION PROLOGUE/EPILOGUE operators is simply nonsense, you can code ABSOLUTELY anything between them.
Now when it comes to coding efficiency with one of the techniques you have described, either pushing the arguments for a WNDCLASSEX structure directly onto the stack or manually allocating space on the stack then writing the arguments to the stack and, calling the stack address with RegisterClassEx() and then correcting the stack after the function has returned, I will make the same criticism that your code is sloppy and inefficient in comparison to a normal LOCAL structure which is preallocated at the beginning or the procedure and cleaned up at the end as the standard LOCAL is simply more efficient as it does less work than you repeated stack corrections.
I have occasionally used this technique when I had a stack frame free procedure as a matter of convenience but it is certainly less efficient than a LOCAL variable.
I have no doubt that the method you use works but you are the one who has repeatedly tried to inflict it on others on the basis of it being in some sense "better". Technically its is not and is less efficient code.
hutch--,
QuoteThe truth of a statement is, its called the "Law of excluded middle".
The truth in this case is fuzzy logic, in which statements may be true, false, or somewhere in between. In rhetoric, the law of excluded middle is readily misapplied, leading to the logical fallacy of the excluded middle, also known as a false dilemma.
QuoteNot in the context of the topic, the use of OPTION PROLOGUE renders your arguments nonsense.
In what way? Why do I need it for my method?
QuoteYou may have a dispositional problem with the standard MASM notation but using OPTION PROLOGUE/EPILOGUE to turn off the generation of a stack frame makes ALL of your arguments nonsense. The PROC / ENDP then serve a different purpose, that of being the MASM defined model of the procedure that is matched with a prototype for the procedure.
Ah! Now I determined what you are saying. I always thought that PROTO would work without PROC/ENDP, but I just tried it and it does not. Strange, I have never explicitly coded PROTO in my code before. In fact, I developed a MACRO called INVOKIT to bypass parameter counting. That was so I could PUSH parameters before the INVOKE. I guess I never missed the benefits of PROTO too much because oftentimes I bypassed it.
QuoteYou may whinge about the extra "red tape" but it is THE MASM defined method of writing a stack frame free procedure that still has a working standard MASM prototype. To make the point again, there is NO DIFFERENCE in the code generation between a fully manually coded procedure and the code that is generated between the OPTION PROLOGUE/EPILOGUE operators but the standard MASM method of creating a prototype works as it was designed to work.
Personally I don't plan to use the PROC/ENDP method, but I can see how someone who wants MASM to count the INVOKE parameters would. However, my method is not about counting parameters, it is about managing the stack manually and not using the EBP register.
QuoteI am "pitching" the standard MASM method of using PROC / ENDP either with OR without the OPTION PROLOGUE/EPILOGUE operators depending on what you require. One generates a standard MASM stack frame procedure, the other generates EXACTLY what you write between the operators but with the added advantage that it allows a standard MASM prototype and collectively this pair of techniques are exhaustive. Your claim that there is a technical reason NOT to use PROC / ENDP in conjunction with the OPTION PROLOGUE/EPILOGUE operators is simply nonsense, you can code ABSOLUTELY anything between them.
What you say is true, it is exhaustive but verbose. Its "features" I don't need and I often bypass.
QuoteNow when it comes to coding efficiency with one of the techniques you have described, either pushing the arguments for a WNDCLASSEX structure directly onto the stack or manually allocating space on the stack then writing the arguments to the stack and, calling the stack address with RegisterClassEx() and then correcting the stack after the function has returned, I will make the same criticism that your code is sloppy and inefficient in comparison to a normal LOCAL structure which is preallocated at the beginning or the procedure and cleaned up at the end as the standard LOCAL is simply more efficient as it does less work than you repeated stack corrections.
I don't know how you can say that. Pushing parameters has to be the most efficient way of putting something on the stack. After the CALL, one stack correction finishes up. What's sloppy about that? A LOCAL structure has to preallocate the stack, then write with either the ESP or EBP offset, and finally correct the stack after the CALL. How is writing to the stack with ESP or EBP more efficient than a PUSH?
QuoteI have no doubt that the method you use works but you are the one who has repeatedly tried to inflict it on others on the basis of it being in some sense "better". Technically its is not and is less efficient code.
I assume you are talking about putting WNDCLASS on the stack. You should explain how a PUSH is less efficient than a direct write to the stack. Ratch
This is so tiresome... I must have been nuts to read the whole sordid diatribe!
Paul
:bg
> The truth in this case is fuzzy logic, in which statements may be true, false, or somewhere in between.
I guess your problem of unintelligible arguments has to have a basis somewhere. Here is yet another dilemma for you in your reasoning style.
If "statement" is TRUE, then its not FUZZY logic.
If "statement" is fuzzy logic, then its not TRUE.
>> Not in the context of the topic, the use of OPTION PROLOGUE renders your arguments nonsense.
>In what way? Why do I need it for my method?
You have among other things confused the difference between your argument which you try and inflict on others and your method which is your problem. While your method will probably work your argument does not depend on your subjective experience but on whether what you say is true.
Quote
Ah! Now I determined what you are saying. I always thought that PROTO would work without PROC/ENDP, but I just tried it and it does not. Strange, I have never explicitly coded PROTO in my code before. In fact, I developed a MACRO called INVOKIT to bypass parameter counting. That was so I could PUSH parameters before the INVOKE. I guess I never missed the benefits of PROTO too much because oftentimes I bypassed it.
Surprise surprise, MASM has worked this way since the delivery of MASM 6.0 in 1990. My own disposition on pseudo "invoke" macros is they are a waste of time as they fail to do anything useful in terms of argument checking yet they still restrict full manual coding. In every instance the manual PUSH / CALL technique is a better option than phony "invoke" macros.
> However, my method is not about counting parameters, it is about managing the stack manually and not using the EBP register.
Its called writing a procedure without a stack frame, tell us something new.
> How is writing to the stack with ESP or EBP more efficient than a PUSH?
Simple, the MOV mnemonic is almost exclusively faster than the PUSH mnemonic when it comes to loading a structure like a WNDCLASSEX. A MOV is copy data to destination, a PUSH is copy data to stack
AND alter the stack pointer. Do more = take longer.
Now your distinction between space allocated on the stack for LOCAL or AUTOMATIC variables as against on the fly allocation from one function call to another is this simple, for an entire procedure the LOCAL or AUTOMATIC variables are only done once on entry and exit to the procedure where you method must perform the task multiple times for multiple functions, thats why its sloppy inefficient code.
PBrennick,
QuoteThis is so tiresome... I must have been nuts to read the whole sordid diatribe!
Sorry Paul. Just hang in there a little longer. You can do it. Ratch
hutch--,
QuoteI guess your problem of unintelligible arguments has to have a basis somewhere. Here is yet another dilemma for you in your reasoning style.
If "statement" is TRUE, then its not FUZZY logic.
If a statement is TRUE, then it could be fuzzy logic.
QuoteIf "statement" is fuzzy logic, then its not TRUE.
If a statement is fuzzy logic, then it could be TRUE, FALSE, or in-between.
QuoteYou have among other things confused the difference between your argument which you try and inflict on others and your method which is your problem. While your method will probably work your argument does not depend on your subjective experience but on whether what you say is true.
I think that is a distinction without a difference. If I apply what I say, and it turns out like it I expect, then the method must be valid. That does not make it the only method. Others must judge whether my method is for them.
QuoteSurprise surprise, MASM has worked this way since the delivery of MASM 6.0 in 1990. My own disposition on pseudo "invoke" macros is they are a waste of time as they fail to do anything useful in terms of argument checking yet they still restrict full manual coding. In every instance the manual PUSH / CALL technique is a better option than phony "invoke" macros.
Yes, psuedo invokes do something useful. They don't error out if one doesn't PUSH the full set of parameters because some parameters were pushed earlier. Manual PUSH/CALL will certainly do the job, but "phony" invoke macros mimic some characteristics of INVOKE by keeping parameters on one line and PUSHing in reverse order.
QuoteIts called writing a procedure without a stack frame, tell us something new.
All right. It still is a stack frame, albeit a DYNAMIC or FREE stack frame. The stack frame used the PROC/ENDP is a STATIC or ANCHORED frame. They both have advantages and disadvantages. It is not 'frameless" in my case because I define it by a shifting STRUCTURE.
QuoteSimple, the MOV mnemonic is almost exclusively faster than the PUSH mnemonic when it comes to loading a structure like a WNDCLASSEX. A MOV is copy data to destination, a PUSH is copy data to stack AND alter the stack pointer. Do more = take longer.
True, unless more silicon is devoted to PUSH nowadays on the newer CPUs. And you have the parameters in registers, or the the parameters are addresses or constants. Can't MOV memory contents onto the stack like a PUSH can. Otherwise you have to load 'em into registers first, and that takes time. Not that it matters much, but a MOV to the stack uses more bytes that a PUSH does. All in all, I don't think you are saving big time, since it is usually called only once and not too many params are involved.
QuoteNow your distinction between space allocated on the stack for LOCAL or AUTOMATIC variables as against on the fly allocation from one function call to another is this simple, for an entire procedure the LOCAL or AUTOMATIC variables are only done once on entry and exit to the procedure where you method must perform the task multiple times for multiple functions, thats why its sloppy inefficient code.
I don't understand what you are saying. The PROC/ENDP subroutines have to SUB ESP,XXX and ADD ESP,XXX to allocate/release local storage just as I do every time the function is called. What am I missing here? Ratch
:bg
The problem as I see it with Ratch's view is that he has argued against using the standard MASM PROC / ENDP for some years in ignorance of how it works. Vascillating between "I can do it better" and "I don't know how it works" tells us no more than Ratch has not done his homework on how MASM works. Using "fuzzy logic" of the type "I don't know how it works so there is something wrong with it" may function as being "Hopelessly pedantic" but it has little to say about the value of the criticism of the standard PROC / ENDP notation in MASM and how it works.
Now if Ratch was selling an advanced technique that may have some coding advantage, I have no doubt that someone would look at it to see if its actually useful but making years of criticism of very well known standard methods in MASM on the basis of ignorance is another matter that leaves Ratch open to technical criticism for what he clearly did not know for those years of criticism.
============================
Beware, waffle below :)
============================
Now to deal with the last posting of blunders.
> If a statement is TRUE, then it could be fuzzy logic.
> If a statement is fuzzy logic, then it could be TRUE, FALSE, or in-between.
Both statements have the same blunder, the expression "could" has no objective reference, it is a personal subjective value judgement that is not subject to being either true or false.
The next blunder is the multi-value truth system being assumed. TRUE and FALSE are well understood where the "inbetween" operator is an unknown. The viable distinction is between "what exists" and "how you know it exists", historically referred to as the distinction between ontology and epistemology. Apply a multi-value truth system to itself and it becomes unintelligible.
I could comment on the further technical blunders and term redefinitions but its a case of "who cares".
hutch--,
QuoteThe problem as I see it with Ratch's view is that he has argued against using the standard MASM PROC / ENDP for some years in ignorance of how it works.
Of course I know how it works. To say otherwise is disengenuous. The only thing you can say is that I was unaware that the PROTO directive needs the PROC/ENDP to work. I don't use the PROTO directive with my subroutines because it would lock me into a standard calling sequence where every param of the subroutine would have to be PUSHed onto the stack concurrently instead of possibly PUSHing them when they first become available. If I used and needed the PROTO directive, then you can be sure that I would have learned how it to implement it.
QuoteVascillating between "I can do it better" and "I don't know how it works" tells us no more than Ratch has not done his homework on how MASM works.
Another disengenuous statement. I have been consistent on both "I can do it better" and "I don't need it, want it, and have to bypass it".
QuoteUsing "fuzzy logic" of the type "I don't know how it works so there is something wrong with it" may function as being "Hopelessly pedantic" but it has little to say about the value of the criticism of the standard PROC / ENDP notation in MASM and how it works.
You are confused about what fuzzy logic is. I have explained my dislike of PROC/ENDP and enumerated the virtues and faults of my method many times. You have not offered any effective substantive criticism of my method except to pronounce in general terms that my reasoning is somehow flawed.
QuoteNow if Ratch was selling an advanced technique that may have some coding advantage, I have no doubt that someone would look at it to see if its actually useful but making years of criticism of very well known standard methods in MASM on the basis of ignorance is another matter that leaves Ratch open to technical criticism for what he clearly did not know for those years of criticism.
My technique is not really new or advanced. Perhaps my implementation is somewhat different. Everyone will have to decide for themselves whether it is right for them. This technique was not developed by being ignorant. The act of not using, needing, bypassing, or not learning how to implement a "feature" of the PROC/ENDP-PROTO is not ignorance. And it does not change my method or its effectiveness. What more can I say?
QuoteNow to deal with the last posting of blunders.
> If a statement is TRUE, then it could be fuzzy logic.
> If a statement is fuzzy logic, then it could be TRUE, FALSE, or in-between.
Both statements have the same blunder, the expression "could" has no objective reference, it is a personal subjective value judgement that is not subject to being either true or false.
Both statements above are absolutely true. It is not necessarily a subjective judgement. It might be a fact. That is why the conditional "could" is in the definition.
QuoteThe next blunder is the multi-value truth system being assumed.
No, not multi-valued, partially TRUE or partially FALSE. That can happen in everyday life.
QuoteThe viable distinction is between "what exists" and "how you know it exists", historically referred to as the distinction between ontology and epistemology. Apply a multi-value truth system to itself and it becomes unintelligible.
An irrelevant false observation as to whether my method has merit.
QuoteI could comment on the further technical blunders and term redefinitions but its a case of "who cares".
"Who cares" is the best observation you made so far.
------------------------------------------------------------------------------
All right, let's summarize. I proposed a method that basically uses a floating stack frame implemented by a STRUCT. Because the stack frame is floating, it does not need to use EBP, or need some of the set up code. Furthermore, the params do not have to be PUSHed onto the stack concurrently. The method is also very well suited to efficient cascaded subroutine CALLs where the called subroutine can use the parameters directly from the stack of the previous calling subroutines. And, some of the original params can be left on the stack for subsequent calls if desired. This REQUIRES that I do not use PROC/ENDP and PROTO. You said that I was in error for not using OPTION PROLOG/EPILOG:NONE. I said that it was completely useless to me because I did not use PROTO. You then said that I was coding in ignorance or some such nonsense. As a sideline, we also discussed PUSHing WNDCLASS vs writing it directly to the stack. You said that it was more efficent to MOV instead of PUSH, and PUSHing was sloppy and inefficent. I pointed out to you that coding the address of the stack took more bytes than a PUSH, and memory contents had to be loaded into a register before a MOV to the stack could be done. So far, you have not said anything further about that. You also have not so far explained why you think the PROC/ENDP is more efficient for setting up LOCAL storage than my method is, as you avered at the end of response #48. I would be interested in that explanation. Ratch
Quote
:bg
The problem for Ratch as I see it is a history of railing for years against standard techniques built into MASM on the basis of ignorance. Whether he understands it or not, MASM is very well understood by a massive number of people and this extends to how it constructs a stack frame with its standard PROC / ENDP as well as how the OPTION PROLOGUE / EPILOGUE operators works.
There is no mystery about how these things work as long as you understand them yet from the things that Ratch has said for some years, he has YET to understand the standard MASM notation for creating procedures either with or without a stack frame (by conventional definition).
Ratch's problem is that he is WRONG, not half left, not communist but just plain WRONG in what he has kept trying to misrepresent about how MASM works.
The "Hopelessly pedantic" approach is just that, "hopeless" and pedantic". It seems the only approach to put an end to it is to find Gidney and Clyde so they can give him a serious "scrooching" before those ferocious grannies from Arizona beat him to a pulp with their walking sticks. :cheekygreen:
hutch--,
QuoteThe problem for Ratch as I see it is a history of railing for years against standard techniques built into MASM on the basis of ignorance.
Just one technique thus far. And not on the basis of ignorance--upon enlightenment.
QuoteWhether he understands it or not, MASM is very well understood by a massive number of people and this extends to how it constructs a stack frame with its standard PROC / ENDP as well as how the OPTION PROLOGUE / EPILOGUE operators works.
Yes, we all understand how it works. It is not rocket science.
QuoteThere is no mystery about how these things work as long as you understand them yet from the things that Ratch has said for some years, he has YET to understand the standard MASM notation for creating procedures either with or without a stack frame (by conventional definition).
I never said I don't understand how procedures are created. I said I have a better way of doing it other than the conventional MASM way.
QuoteRatch's problem is that he is WRONG, not half left, not communist but just plain WRONG in what he has kept trying to misrepresent about how MASM works.
I only explained my way. I never tried to teach anyone how MASM works. That would be a giantic subject.
QuoteThe "Hopelessly pedantic" approach is just that, "hopeless" and pedantic". It seems the only approach to put an end to it is to find Gidney and Clyde so they can give him a serious "scrooching" before those ferocious grannies from Arizona beat him to a pulp with their walking sticks.
You sure you don't mean Bonnie & Clyde? I can still run faster than any old granny. :toothy Ratch
Why do I detect some back door revisionism ? Easy, Ratch is not happy with his past history of mistakes being revealed. :P Having railed against the standard methods built into MASM for a period of years only to find out that Ratch has not properly understood how they even work when we have heard comments about "subtle" changes to procedures and "hidden" changes when you use the PROC / ENDP operators when in fact MASM stack frames are very well understood.
The next jewel was not understanding how the topic OPTION PROLOGUE / EPILOGUE notation works and how it relates to MASM prototyping when it has only been done this way since MASM 6.0 in 1990. Arguing from a position of personal ignorance does not convince anyone yet Ratch has been doing this for years with his whinging about the way MASM works with its PROC / ENDP capacity either with or without the topic modifiers.
Born again revisionism aside, the problem for Ratch is that he is WRONG in what hew has asserted about MASM for years and a vaste number of people already know it.
If Ratch was just selling a different technique there would be no problems as it would be evaluated on its merits but as long as Ratch tries to misrepresent the capacity of the assembler, he keeps making a fool of himself when the capacity is so well known by so many people.
hutch--,
QuoteWhy do I detect some back door revisionism ?
Your imagination is running wild.
QuoteEasy, Ratch is not happy with his past history of mistakes being revealed.
What mistakes? Everything I described about my method works.
QuoteHaving railed against the standard methods built into MASM for a period of years only to find out that Ratch has not properly understood how they even work when we have heard comments about "subtle" changes to procedures and "hidden" changes when you use the PROC / ENDP operators when in fact MASM stack frames are very well understood.
The method of using PROC/ENDP is singular, not plural. And PROC/ENDP does affect how code is generated. Yes, everyone except nubes understands how stack frames work. You are foolish in thinking that I don't know that. I would not have been able to develop my method without understanding it. Are you getting mixed up in differentiating between how PROC/ENDP works and how stack frames are or could be implemented?
QuoteThe next jewel was not understanding how the topic OPTION PROLOGUE / EPILOGUE notation works and how it relates to MASM prototyping when it has only been done this way since MASM 6.0 in 1990.
So what? Why learn something if you are never going to use it or need? That's like recording every license plate you pass while driving. It's useless knowledge.
QuoteArguing from a position of personal ignorance does not convince anyone yet Ratch has been doing this for years with his whinging about the way MASM works with its PROC / ENDP capacity either with or without the topic modifiers.
I would call it personal enlightment.
QuoteBorn again revisionism aside, the problem for Ratch is that he is WRONG in what hew has asserted about MASM for years and a vaste number of people already know it.
You keep saying that like a mantra, but you never prove it. My method works and it is efficient. You cannot deny that.
QuoteIf Ratch was just selling a different technique there would be no problems as it would be evaluated on its merits but as long as Ratch tries to misrepresent the capacity of the assembler, he keeps making a fool of himself when the capacity is so well known by so many people.
The capacity of MASM is indeed known by a lot of people, but that is not the question, except in your mind. I never questioned that MASM could not do what the documentation says it could do. I just found a better method, at least in my viewpoint. I use MASM to implement it, so how could I be downgrading MASM? If I wrote a MACRO to do something better than MASM does, like maybe generate a instruction that MASM does not, would you complain?
I am still awaiting your explanation of how PUSHs are better that direct writes to the stack, and how PROC/ENDP handles LOCAL storage better than procless programming does. Ratch
:bg
> Your imagination is running wild.
No, your memory is failing you. You have made the mistake of writing your own ignorance in a miriad of postings.
> What mistakes? Everything I described about my method works.
The mistakes you are trying to avoid after having misrepresented how MASM works in so many postings.
> The method of using PROC/ENDP is singular, not plural.
This is trash, the topic makes a nonsense of what you say.
> And PROC/ENDP does affect how code is generated.
This is trash as well, it generates a stack frame by default, it fdoes not modify code AT ALL.
> So what? Why learn something if you are never going to use it or need?
What you "learn" is your problem, what you have repeatedly misrepresented is another altogether.
> I would call it personal enlightment.
Only if you had bothered to actually learn it rather than misrepresent how it works as you have been doing in ignorance for years.
> I never questioned that MASM could not do what the documentation says it could do.
No, you simply continue to misrepresent what it does do with your years of postings in ignorance.
> I just found a better method, at least in my viewpoint.
Self reference is no reference. You may have a method but your assertions about MASM made over a period of years are simply WRONG. Do your own homework and read your own previous posts, no one is going to waste their time doing it for you.
All you demonstrate at the moment is that your are hopelessly pedantic but then we already know that. It looks like those grannies need to give you a sound beating with their walking sticks and be careful, those grannies are a lot craftier than you think. :P
hutch--,
QuoteNo, your memory is failing you. You have made the mistake of writing your own ignorance in a miriad of postings.
Saying so does not make it so.
QuoteThe mistakes you are trying to avoid after having misrepresented how MASM works in so many postings.
Show me one mistake that is significant with respect to what I am trying to do. Just one.
Quote> The method of using PROC/ENDP is singular, not plural.
This is trash, the topic makes a nonsense of what you say.
How?
Quote> And PROC/ENDP does affect how code is generated.
This is trash as well, it generates a stack frame by default, it fdoes not modify code AT ALL.
I said it affects how code is generated, not modify code already written. For instance, it enables the PROTO directive as you already pointed out.
Quote> So what? Why learn something if you are never going to use it or need?
What you "learn" is your problem, what you have repeatedly misrepresented is another altogether.
What I learn is my advantage. I have not misrepresented anything about MASM to any significant degree.
Quote> I would call it personal enlightment.
Only if you had bothered to actually learn it rather than misrepresent how it works as you have been doing in ignorance for years
I already explained why I did not bother to learn it. It has no value to me. If it had significance, why did you not correct me earlier?
QuoteNo, you simply continue to misrepresent what it does do with your years of postings in ignorance.
An unneeded feature of insignificant value. If it was important, why did not you or someone else correct me on this?
Quote> I just found a better method, at least in my viewpoint.
Self reference is no reference. You may have a method but your assertions about MASM made over a period of years are simply WRONG. Do your own homework and read your own previous posts, no one is going to waste their time doing it for you.
Self reference does have standing if it is backed by reasons. There you go with plural again. Because you did not correct me at the time, and you are vague about what I said was wrong, you should at least give one example where the error is significant. I too am not going to reread my previous posts just on your say so.
QuoteAll you demonstrate at the moment is that your are hopelessly pedantic but then we already know that. It looks like those grannies need to give you a sound beating with their walking sticks and be careful, those grannies are a lot craftier than you think.
Yes, I am hopelessly pedantic. Those grannies are crafty, but so am I.
Still waiting your response for PUSH vs writing to the stack, and the advantages of PROC/ENDP for LOCAL storage. Are you ever going to explain what you meant? Ratch
:bg
Sounds like a serious scrooching is the only solution to someone who is hopelessly pedantic and thats before the grannies give you a good pasting with their walking stick but beware of the older grannies who use walking frames, they are much heavier.
> Yes, I am hopelessly pedantic. Those grannies are crafty, but so am I.
Crafty != hopelessly pedantic && hopelessly pedantic != crafty. About the only crafting those grannies will do with you is with their walking sticks around your ears. :P
> Still waiting your response for PUSH vs writing to the stack, and the advantages of PROC/ENDP for LOCAL storage. Are you ever going to explain what you meant?
Why bother when you don't even understand what you have repeatedly misrepresented about how MASM works.
Being hopelessly pedantic about simply being WRONG will not help you when those grannies catch up with you and this is BEFORE you get scrooched.
hutch--,
QuoteSounds like a serious scrooching is the only solution to someone who is hopelessly pedantic and thats before the grannies give you a good pasting with their walking stick but beware of the older grannies who use walking frames, they are much heavier.
Scrooching means, according to the dictionary, "to hunch down or crouch". You sure you don't mean smootching? And I can be charming as well as crafty with the grandmas. I can easily run away from the ones with the walkers.
QuoteCrafty != hopelessly pedantic && hopelessly pedantic != crafty. About the only crafting those grannies will do with you is with their walking sticks around your ears.
Those characteristics are mutually exclusive with each other. I am both.
QuoteWhy bother when you don't even understand what you have repeatedly misrepresented about how MASM works.
What a copout! Everyone can discern the REAL reason you don't explain yourself.
QuoteBeing hopelessly pedantic about simply being WRONG will not help you when those grannies catch up with you and this is BEFORE you get scrooched.
They have to catch me first. Ratch
:bg
> You sure you don't mean smootching?
Hopeless pedantry will not help you here. Gidney and Clyde will not be "smootching" you at all.
> And I can be charming as well as crafty with the grandmas.
Grannies are not that stupid.
> What a copout!
You mean like being hopelessly pedantic ?
> Everyone can discern the REAL reason you don't explain yourself.
You have just become the spokesman for "everybody" ? Hopeless pedantry will not get you there except in your wildest imagination.
hutch--,
QuoteYou have just become the spokesman for "everybody" ? Hopeless pedantry will not get you there except in your wildest imagination.
No. Just an observation. Ratch
:bg
The price of hopeless pedantics is hopeless pedantics.
hutch--,
I am used to paying that price. Ratch
Sounds kinky, self inflicted injuries.
Just beware of those ferocious grannies, one may use a walking fame as a pull through to clean the nonsense out of you which would probably work OK but if two of them started from opposite ends you would get a jam up in the middle and forever have a walking frame handle sticking out each end. :bg
hutch--,
QuoteSounds kinky, self inflicted injuries.
The price of being right.
QuoteJust beware of those ferocious grannies, one may use a walking fame as a pull through to clean the nonsense out of you which would probably work OK but if two of them started from opposite ends you would get a jam up in the middle and forever have a walking frame handle sticking out each end.
I avoided them this long, I can do it longer. Sounds like you were born out of time. Was your period the Dark/Middle Ages? Ratch
:bg
> The price of being right.
This is an interesting excuse for being kinky but I doubt it will work with those ferocious grannies who know how to deal with many things incluing hopeless pedantry.
> Was your period the Dark/Middle Ages?
No, the stone age, thats why I recognise hopeless pedantry without the need for interpretation.
hutch--,
QuoteThis is an interesting excuse for being kinky but I doubt it will work with those ferocious grannies who know how to deal with many things incluing hopeless pedantry.
Naw, grannies are clueless and easy to avoid.
QuoteNo, the stone age, thats why I recognise hopeless pedantry without the need for interpretation.
I might be pedantic, but I am still right. Ratch
:bg
> Naw, grannies are clueless and easy to avoid.
You must be avoiding the normal ones, they can sus out a hoipeless pedant any old time.
> I might be pedantic, but I am still right.
Right of what ?
hutch--,
QuoteYou must be avoiding the normal ones, they can sus out a hoipeless pedant any old time.
Those are few and far between, and are easily distracted.
QuoteYou must be avoiding the normal ones, they can sus out a hoipeless pedant any old time.
Not right of what, right about what we were discussing. Ratch
Why does this just sound like more hopeless pedantics ?
Ah, I know !
Its because its just more hopeless pedantics.