Folks, ============================================== push 0 ;<-it's a 2 bit command if u wana optimizin use: xor ebx, ebx ;<-ebx is set zero push ebx ;<-this is 1 bit command It becomes critical when u use it often in ur program - for API functions and so on. Windows APIs not changin the ebx register, so it'll be enough one "xor ebx,ebx" for all program. ============================================== There are a number of blunder here, first one is that API calls are slow in comparison to assembler so optimising an API call is useless. Using XOR reg, reg is no faster than MOV reg, immediate, this is old DOS leftover technology. EBX MUST be preserved when making API calls, its standard Windows convention to preserve EBX, ESI & EDI. Putting 2 instructions in the place of one while setting the stack for a function call is rediculous, its both longer and slower. Free of the folklore, you optimise on the basis of need and only if it works, optimisations of this type make code biger and slower. Regards, hutch@pbq.com.au
Posted on 2001-03-08 10:11:00 by hutch--
Well, hutch, he is correct that if you need to push a lot of zeroes in a row, your code will be smaller if you use the "xor reg, reg" approach and the "push reg" instead of "push 0". However, I do agree with you that optimizing code around API calls is pretty useless. I wouldn't even say it matters for viral coding (it did back in the jolly DOS days), but under win32? Naw. As for "mov eax, 0" compared to "xor eax, eax" ... the xor method is quite a bit shorter - three bytes shorter. So yes, I always use the XOR method (some people seem to prefer sub) in my programs. Out of pure instinct, "from the dos days when this mattered".
Posted on 2001-03-08 10:54:00 by f0dder
============================== EBX MUST be preserved when making API calls, its standard Windows convention to preserve EBX, ESI & EDI ============================== And what i said? Windows APIs not touching it And i'm not talking about optimizin API functions, first of all by usin my approach u reduce the program size, and, secondly u make it A BIT FASTER. Hutch, mister Guru, do u read posts or u just think that u can come say something and everyone aggree, just because ur so... ehm, big and bold? :P
Posted on 2001-03-08 12:23:00 by DLnC
Mr. Optimising guru, =========================================================================== And i'm not talking about optimizin API functions, first of all by usin my approach u reduce the program size, and, secondly u make it A BIT FASTER. Hutch, mister Guru, do u read posts or u just think that u can come say something and everyone aggree, just because ur so... ehm, big andbold? =========================================================================== 1. Reduction in program size. DOS mentality of byte alignment fails in win32, using the default linker from the DDK gives you files that are increments or 512 bytes so you can forget the idea of making the program smaller by close range opcode selection. 2. Increase in program speed.

MOV reg, immediate = 1 micro-op
XOR reg, reg       = 1 micro-op
1 = 1, forget the idea of an increase in program speed with this type of coding, its leftover DOS coding. 3. Optimising an API call. API calls are a LOT slower than assembler. ============================================== for example u need to show a simple msgbox:

    xor ebx, ebx
    push ebx
    push ebx
    push offset wndName
    push offset buff
    push MB_OK
    call MessageBox
============================================== Your code, not mine. Optimising a manually called API call is a waste of time in performance terms, it could not be benchmarked. 4. Folklore. A lot of this nonsense is derived from a particular coding style in DOS where byte alignment and instruction choice gave marginally smaller code. String instructions are a good example, they are smaller but a LOT slower, the only use for these instructions is when used with REP as in REP MOVSD. 5. Self proclaimed optimisation gurus. The only test that matters is not 2 or 3 lines of code but the capacity to write small fast applications in win32. Feel free to show us all how its done. DOS is 1980 technology, welcome to the 21st Century. Regards, hutch@pbq.com.au This message was edited by hutch--, on 3/8/2001 5:55:34 PM
Posted on 2001-03-08 17:49:00 by hutch--
================================ --Apploading for 30 minutes :)-- ================================ Well, the only thing i can say now? 8)) 1.U can do ur own inc's, with only that functs, that u need. 2.There's also one realy optimized pice of code in my previous posts, not the one u chose for ur critics 8) And i'm not talking about optimizin API calls. 3.Use "mov" or "xor", but we was talking about writing "push reg" instead of writing "push 0" when u need to make more than 2 pushes. That what i ment, when said "do u read posts?". 4.If u are talking like this: "it doesn't matter now", heh, then why u code in asm? Go and code in Visual Basic! Even one free byte can matter! --------------------------- If u can't program good, don't program at all.
Posted on 2001-03-09 08:51:00 by DLnC
Mr Code Optimising guru, Here is the timings for your code optimisation, (reference Agner Fog timings PII - PIII)

    push reg, immediate     ; 1 micro-op
    push reg, immediate     ; 1 micro-op


    xor reg, reg            ; 1 micro-op
    push reg                ; 1 micro-op
    push reg                ; 1 micro-op
Your code is slower by 1 micro-op. Put this in an intensive loop and you can measure the difference so I suggest that your optimisation technique is a BAD IDEA(tm). Here is the benchmark code to test it, change the number in ECX so that the loop runs for over .5 of a second and measure the difference in real time.

    mov ecx, 1000000
  @@:
    push 0
    push 0
    pop ebx
    pop ebx
    dec ecx
    jnz @B

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

    mov ecx, 1000000
  @@:
    xor ebx, ebx
    push ebx
    push ebx
    pop ebx
    pop ebx
    dec ecx
    jnz @B
Optimising to get slower code is the same brain that writes Visual Basic, why write in assembler when you can do it even slower in VB ? Maybe you have a future writing M$ .NET. Ho hum, welcome to the wonderful world of pentium optimisation. =============================================== If u can't program good, don't program at all. =============================================== Try this, If you can't program properly, learn to fix it. There are a lot of very good assembler programmers who post on this forum, try learning something from them instead of boasting about how badly you can write code. Regards, hutch@pbq.com.au
Posted on 2001-03-09 17:29:00 by hutch--
OWWWWW!!!! Now i see, that u are blind!!!! DUMBA**!!!!!!!!!!!!! Can u read? Or the shining of ur nimb is too blinding?! U must use xor ebx, ebx only once! Why u repeat it in loop?! Think i'm an idiot?! I reduce the PROGRAM SIZE! Ur puny efforts to hurt me are very funy, but useless. And about VB: if u say "leftover DOS coding" then u are just another heretic, VB is ur field. U write:

    push reg, immediate     ; 1 micro-op <-U PUSH REG!
    push reg, immediate     ; 1 micro-op


    xor reg, reg            ; 1 micro-op
    push reg                ; 1 micro-op
    push reg                ; 1 micro-op
And then u write:

    mov ecx, 1000000
  @@:
    push 0 ;<-push reg, eh?! haha
    push 0
    pop ebx
    pop ebx
    dec ecx
    jnz @B

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

    mov ecx, 1000000
  @@:
    xor ebx, ebx ;<-u mustn't put it here and u know it!
    push ebx     ;<-add one more "push ebx" and it WILL MATTER
    push ebx
    pop ebx
    pop ebx
    dec ecx
    jnz @B
Ur talking is a waste of time. -------------------------------- Noble warriors stay silent!
Posted on 2001-03-09 17:59:00 by Alex_SS (DLnC was temporary nick for this forum)
As you can see, if this code was part of a program the xor ebx,ebx would be ran once everytime this section of code was ran. so to bench mark it, you have to include it into the loop example that HUTCH was showing you. If you still don't get it, I know some very good Books you can read, about Optimizing windows apps. This message was edited by Zcoder, on 3/9/2001 9:00:55 PM
Posted on 2001-03-09 21:00:00 by Zcoder
Mr Optimising Guru (Alex), As it appears you have missed that the benchmarking was not a loop optimisation demo, try looking at your own code to see where the benchmark comes from, you have asserted that an XOR and 2 register pushes are faster than 2 immediate value pushes. The timings of the instructions alone show you are wrong, 3 micro-ops are slower than 2 micro-ops. The benchmark was constructed to show that your assertion is simply wrong in real time. Zcoder has pointed out that your assertion on the benchmarking is simply wrong, it tests your assertion and shows that it is wrong. ==================================== OWWWWW!!!! Now i see, that u are blind!!!! DUMBA**!!!!!!!!!!!!! Can u read? Or the shining of ur nimb is too blinding?! ==================================== I am also senile, bad mannered, antisocial and an Australian so compliments of this type are always welcome. Come back when you learn how to code, there are many very good programmers who can help you as it appears you need a lot of help but you will have to improve your manners first or they will not take much notice of you. Regards, hutch@pbq.com.au
Posted on 2001-03-09 21:51:00 by hutch--
Mr Blind-Australian-Badmanared-Guru and all his supporters, in my last post i wasn't talking about SPEEDING UP the program. I said, that my method makes program a bit smaller, and even one byte matters. And ur loop example with "xor ebx,ebx" in it "for bechmarking", heh, even a child can see that it'll be longer, then the first approach. But as I said in one of my first posts here, it'll be enough one "xor" in the beginning of the program, especially small program, like that we are talking about (or u forgot???). Why should I repeat evident things?! I think u underastand what I'm talking about and aggree, but ur selfishness can't allow u to say this. Stop talking, go and do ur australian job, I have many things to do also. Mister Guru, u seem to be so stragulated... don't worry about it in minds of this forum visitors ur are a real guru, who cares about single man, that knows what's realy inside u? And again, have a nice day.
Posted on 2001-03-10 05:12:00 by Alex_SS
Alex_SS your attitude really will have to change. It's not done to come into this forum and (try to :rolleyes: ) insult its members like you're doing. This forum is about coding and c÷operation in good spirit. Regardless of who is right, when you wish to make a point come across please withdraw yourself from the use of abusive language or derogatory adjectives. Thank you. -H-
Posted on 2001-03-10 06:36:00 by Hiroshimator
first of all, the idea that EBX is always preserved is not always correct. I have know under certain circumstances, in which i couldn't figure out, ebx got changed whenever i made a call to CreateWindowEx. And another thing, you can create a prog, which is only 512 bytes in size. It does nothing: here is the souce, and no special linking or nuthing is required:

.386
.model flat, stdcall

text SEGMENT DWORD
start:
text ENDS

end start

Also, my opionion on packers, is that they have a certain size limit, as eventuly the will start to increase the size of the file more than they compress it. You try it with UPX, if you try to compress a file whch is smaller than about 3kb, you get some sort off error. Just a few things to point out, cause we are dealing with windows, and you can bugger off if you think it is relible. This message was edited by George, on 3/10/2001 6:44:49 AM
Posted on 2001-03-10 06:40:00 by George
what? just type "hutch" in your search-engine and look how "correct" hutch trys to inflict his opinion on other ppl. in MY opinion it's very spasmodic to post things like this benchmark here even though he's knowing that alex is right. this means not that that i'm - pro cuss - but i think it's also wrong to pick on someone who just wants to posts his solution here.
Posted on 2001-03-10 17:17:00 by drcmda
drcmda, I live in a world where I am happy to live with differences between all sorts of people but when someone elses arrogance inflicts itself over many other programmers, I will make comments. ========================== And one more thing i forgot to tell u in my previous message, about code optimization: usual mistake made by... hehe, inexpirienced porgrammers: never use ========================== When Alex attempts to take the piss out of many other programmers, he must expect some correction, especially when he is wrong technically. I have posted the timings from Agner Fog's optimisation manual to prove that the assumption that a register push is faster than an immediate push is wrong, by my count, 1 micro-op = 1 micro-op where an extra XOR adds an extra micro-op. The benchmark proves it in real time, 3 micro-ops is slower than 2 micro-ops. The lesson here for Alex is that when you laugh at people and tell them they are inexperienced, you had better have your facts right first and he does not. Size optimisation at an opcode selection level does not build smaller programs, the linker granularity of 512 bytes makes this idea a nonsense. It is a leftover from the DOS days of BYTE alignment where instruction choice gave you marginally smaller code and when there was no performance penalty with opcode choice. In size terms, the smallest valid PE file I can build is 1024 bytes to display a messagebox and that is using standard MASM options. Many of us know how to write custom DOS stubs in HEX but some versions of Windows will not run non standard PE files so the technique fails. In terms of your comments about the frequency of my name in a search engine, you are correct, I have worked hard to make assembler available to the current generation of young guys and it will show with the amount of stuff that I have posted over a period of years. My generation has assembler as a normal part of programming and it had many advantages in code design. Like many other older programmers, I have tried to make this available to the next generation. What I have happily attacked is the DOS brain TASM style of virus coding as it failed to help anyone and died a natural death in the face of modern programming technique and a far more powerful assembler in MASM. Regards, hutch@pbq.com.au
Posted on 2001-03-10 19:17:00 by hutch--