C / C++ / MFC

viewing my program's assembly code

3-Dec-04 2:47

Why? What does that have to do with my reply to wk_vigorous? Knowing where something is located is one thing, but knowing how to find it is another.

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

BlackDice2-Dec-04 2:42

2-Dec-04 2:42

I've read a few times that "..doing it THIS operation is no faster than doing it THAT way; just look at the assembly after it's compiled" - or something like that. I've used the Win32 disassembler to look at code, and even seen the assembly for an .exe in VS. But if I write a function, how can I view the assembly for that specific function, so that I could see which takes more operations?

int i = 2, x = 2;

int j = x + y;

sprintf("%d",j);

4.7388937 ???

My articles

www.stillwaterexpress.com

BlackDice

David Crow2-Dec-04 3:58

2-Dec-04 3:58

Are you referring to the /FAs compiler switch?

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

BlackDice2-Dec-04 4:49

2-Dec-04 4:49

I really don't know. I'm trying to find out how I can view the difference between this:

//hypothetically, GetRate() performs some intensive calculations that returns an int

for(int i = 0; i < 5; i++)
{
  int j = GetRate() * i;
}

and this:

int x = GetRate();
int j;
for(int i = 0; i < 5; i++)
{
 j = x * i;
}

once they're compiled

int i = 2, x = 2;

int j = x + y;

sprintf("%d",j);

4.7388937 ???

My articles

www.stillwaterexpress.com

BlackDice

David Crow2-Dec-04 5:27

2-Dec-04 5:27

The latter is going to be a bit more efficient since the GetRate() function is only called once. Also, since the value of x does not change, the compiler is likely to optimize that by using a register.

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

BlackDice2-Dec-04 5:39

2-Dec-04 5:39

I already understand that (not that I usually do Smile | :)

) Just in case you didn't know, I am the programmer formerly known as 'bdiamond'. Anyway, I was talking about for other operations that I might not be familiar with. I wrote in another forum once (please CPians forgive me) that using the '+=' operator was faster with CStrings because I read that in a game programming book. One of the forums moderators told me there was no difference. So I put a breakpoint in my code (release version) in an arbitrary function that I used just to test this by going to debug->windows->disassembly and went back throught the disassembly, and this is what I got for two CStrings that started off as "test" and then had "add" concatenated to them.

str += "add";004015BC  push        offset string "add" (4037D0h) <br />
004015C1  lea         ecx,[esp+8] <br />
004015C5  call        dword ptr [__imp_ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >::operator+= (4031DCh)] <br />
<br />
str2 = str2 + "add";<br />
004015CB  push        offset string "add" (4037D0h) <br />
004015D0  lea         eax,[esp+4] <br />
004015D4  push        eax  <br />
004015D5  lea         ecx,[esp+10h] <br />
004015D9  push        ecx  <br />
004015DA  call        ATL::operator+ (4011C0h) <br />
004015DF  add         esp,0Ch <br />
004015E2  push        eax  <br />
004015E3  lea         ecx,[esp+4] <br />
004015E7  mov         byte ptr [esp+18h],2 <br />
004015EC  call        dword ptr [__imp_ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >::operator= (4031D8h)] <br />
004015F2  lea         ecx,[esp+8] <br />
004015F6  call        dword ptr [__imp_ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > >::~CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > (403188h)]

int i = 2, x = 2;

int j = x + y;

sprintf("%d",j);

4.7388937 ???

My articles

www.stillwaterexpress.com

BlackDice

David Crow2-Dec-04 5:56

Inline assembly - what good is it?

2-Dec-04 5:56

One of the underlying reasons why the += operator might be a bit faster is that it (possibly) does not have to copy the source strings (the left side of the +=) for most cases. In VC++ 6.0 Release mode, all CString buffers are allocated in predefined amounts (e.g., 64, 128, 256, and 512 bytes). So, unless the strings are very long, the creation of the concatenated string is an optimized version of a strcat() operation (since it knows the location of the end of the string it doesn't have to search for it, as strcat() would; it just calls memcpy() to the correct place) plus a recomputation of the length of the string. So it is about as efficient as the clumsier pure-C code.

Read here for more.

"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow

BlackDice2-Dec-04 2:37

2-Dec-04 2:37

I'm just wondering, how much of a performance increase could I gain from using inline assembly? I know it's all relative to what I'm doing and so on and so forth. But if every nanosecond counts in a processing loop that dealt with a lot of numbers, would inline assembly make it any faster?

int i = 2, x = 2;

int j = x + y;

sprintf("%d",j);

4.7388937 ???

My articles

www.stillwaterexpress.com

BlackDice

geo_m2-Dec-04 4:29

geo_m

2-Dec-04 4:29

I think, this depends how smart is your compiler. If you will do it in the inline assembly (or in the assembly at all) you know exactly what are you doing so you can take the appropriate optimalization (e.g. using registers and memory as needed), compiler can just guess it from your code in the higher level language. Also, compiler writers can optimize only on some common scenarios.

So in theory, with a supersmart compiler, your assembly and result of the compilation should be equal. But in reality, it always depends how smart your compiler is in that specific situation, and how your high-level language is structured and interpreted by the compiler.

BlackDice2-Dec-04 4:51

2-Dec-04 4:51

cool, thanks!

int i = 2, x = 2;

int j = x + y;

sprintf("%d",j);

4.7388937 ???

My articles

www.stillwaterexpress.com

BlackDice

John R. Shaw2-Dec-04 4:52

John R. Shaw

2-Dec-04 4:52

Optimized assembly code can make it faster, but now days the ability of modern complires to optimize the code makes it difficult to improve upon.

Writing your C/C++ code with optimization in mind, is the simplest aproach. Because it makes it easeir for the compiler to optimize the code for you.

-------------------------------------------------
I'll answer you 2nd question here as well.
-------------------------------------------------

You can look at the disassembled code at run-time: View->Debug Windows->Disassembly

If your program is compiled for debugging, that will bring up a mixed assembly and C/C++ source code view. You should place a break point at the point in your code where you want to look at the assembly code. This is mainly used for debugging, in the case where you think the compiler may have messed up (I have not seen this happen in years).

You can also look at the dissembled code for a program compiled for realese by running it as if it where a debug version from VC6, but I am not sure if you can see the whole program.

-------------------------------------------------
-------------------------------------------------

Although with modern compileres (with multiple optimization options) it is not as important, but having some idea of what assembly code your compiler produces for a given piece of C/C++ code, helps you make better decisions on how to write that code (with optimization in mind).

FYI: Airliners have 3 redundant computer systems. Each one is running the same program and each program was compiled using a different compiler. Why? Because each compiler produces code in its own way. That is if one compiler introduce a flaw in the final program, then that same problem will not be on either of the other systems (in theory).

-------------------------------------------------
Learning game programing
-------------------------------------------------
1) Tons of sights and new groups.
2) Graphics Programming By Michael Abrash.
3) http://sourceforge.net/[^];)

:-DGood luck and have fun.

INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen

BlackDice2-Dec-04 4:57

2-Dec-04 4:57

thanks a bunch. Looks like you put forth some effort and time in posting your answer, and it's appreciated. Smile | :)

int i = 2, x = 2;

int j = x + y;

sprintf("%d",j);

4.7388937 ???

My articles

www.stillwaterexpress.com

BlackDice

Henry miller2-Dec-04 9:07

Henry miller

2-Dec-04 9:07

Maybe. What processor? In many cases something that will make one processor faster will make a different one slower.

In many cases your compiler can optimise things better than you can (unless you have years to write the whole thing in assembly using the highest priced experts, and even then a new processor is like to come out that needs different optimizations) because it will optimise a larger part of the code.

Never even consider inline assembly until you are convinced (with several eyes looking) that you have the best algorithm for the job, and you know something the compiler doesn't know.

When I was working with RC5 we could get major improvements from 2 lines of assembly, but that was a special case where the compiler did not know about an instruction (ROTL) that is almost never useful, but is critical to that algorithm. In the real world it is rare for such a situation come up.

In most cases the most optimized code can only save you nano-seconds over the less optimized code, and your loop won't be long enough for those nano-second to add up. However there are exceptions. Don't forget that when you go to a different processor (AMD athlon and P4, not just x86 to powerPc) your best optimization changes.

BlackDice2-Dec-04 10:46

2-Dec-04 10:46

Henry miller wrote:
and your loop won't be long enough for those nano-second to add up

well, I am thinking about doing some game programming eventually, and that's one of the reasons I asked this question in the first place. Thanks for your response

int i = 2, x = 2;

int j = x + y;

sprintf("%d",j);

4.7388937 ???

My articles

www.stillwaterexpress.com

BlackDice

Harold Bamford3-Dec-04 6:06

Harold Bamford

3-Dec-04 6:06

This is something of a religious subject in that people have certain beliefs and will not change them whatever the argument. And those that do convert, tend to froth at the mouth! Smile | :)

However, IMHO, unless you need to do low-level access to hardware, or you have something in an extremely tight loop, assembly code should not ever be seen.

Remember, the vast majority of the life-cycle of a program is in the maintenance phase and assembly is harder to read and understand than a higher level language. And porting is an issue with assembly, even if on the same processor -- different compilers handle assembly escapes differently.

And modern compilers are pretty good. If you think about how the code is liable to be translated (or peek at the generated code), you can optimize the C/C++ code to make very good machine code. Things like using the natural size integer for a processor rather than something that needs conversion, e.g, use an int rather than a short for a number so low level conversion doesn't have to happen. Naturally, such code should be heavily commented.

As an aside, certain kinds of optimizations that programmers often use because they think they are smarter than the compiler are not needed. For instance, doing x <<= 1; in instead of x *= 2; is almost never needed. The compiler can figure this out just fine. And the first is harder to read...

Harold Bamford3-Dec-04 6:20

Harold Bamford

3-Dec-04 6:20

You should be aware that this is a religious subject; people of one faith will ignore all arguments from heretics. And converts tend to be evangelistic! Smile | :)

IMHO, unless you need to do low-level hardware access or are in an extremely tight loop, assembly code should never be seen. And if it is, it should be heavily commented. Remember, the vast majority of the life-cycle of a piece of software is in the maintenance phase, not development -- assuming it is a successful program! And assembly is harder to read and hard to port. Even when porting from one compiler to another for the same target processor, porting can be awkward as different compilers have different assembly escapes, stack conventions, internal symbol representations, etc.

Further, modern compilers are smart. Even things like x <<=1; instead of the more readable x *= 2; don't buy you anything as the compiler understands what *= 2 means and will find the best way to accomplish this.

If you really are concerned about optimization in a tight loop, then optimize your algorithm (always your best bang for the buck) and adjust variables such that a minimum of assembly-level conversions are needed. For instance, use the machine's natural size integer (usually int) instead of a short. If the compiler cannot determine the absolute maximum value and the processor doesn't handle shorts as easily as ints, then a low-level conversion might be needed. Try peeking at the generated assembly. And heavily comment such tweaks!

API constants value

wk_vigorous2-Dec-04 2:18

wk_vigorous

2-Dec-04 2:18

Guys, how can I know an API constant exact value? For example, PURGE_TXABORT. Any documents?

Thanks a lot.

vigorous

Re: API constants value

BlackDice2-Dec-04 2:33