Back to General and Gameplay Programming

Tip: Writing assembly-friendly C

Promit Roy · 2004-03-09T07:45:22

A while ago, I rewrote a section of C++ that swaps BGR to RGB in a bitmap in assembly. It ran noticeably faster, and looking at the listing revealed that the assembly version was much tighter and smaller. Since the code still has to compile on non-x86 targets, I left the C++ loop in when not compiled on x86. But I was playing with the loop and looking at the listing today, and what I found was pretty interesting. Depending on how you write your code, the assembly output can be very different. Let''s look at the original loop: unsigned char temp; for( int i = 0; i < m_Size * 3; i += 3 ) { temp = RawData[i]; RawData[i] = RawData[i+2]; RawData[i+2] = temp; } It''s pretty self explanatory; RawData is the bitmap data in BGR, and m_Size is the number of pixels in the texture. The assembly listing, however, is pretty long: ; 220 : unsigned char temp; ; 221 : for( int i = 0; i < m_Size * 3; i += 3 ) mov eax, DWORD PTR [esi+12] add esp, 24 ; 00000018H lea ecx, DWORD PTR [eax+eax*2] test ecx, ecx jbe SHORT $L33435 mov ebp, -2 ; fffffffeH lea eax, DWORD PTR [ebx+2] sub ebp, ebx $L33433: ; 222 : { ; 223 : temp = RawData[i]; mov cl, BYTE PTR [eax-2] ; 224 : RawData[i] = RawData[i+2]; mov dl, BYTE PTR [eax] mov BYTE PTR [eax-2], dl ; 225 : RawData[i+2] = temp; mov BYTE PTR [eax], cl mov ecx, DWORD PTR [esi+12] add eax, 3 lea edx, DWORD PTR [eax+ebp] lea ecx, DWORD PTR [ecx+ecx*2] cmp edx, ecx jb SHORT $L33433 $L33435: ; 226 : } I''m not even going to bother explaining that; there''s a ton of stuff going on, and it''s not exactly relevant. Suffice to say that it''s way longer than it needs to be -- 18 instructions. So now I''m wondering how I can restructure this slightly. The first thing I do is add a couple variables and mark them with the ''register'' keyword, to try to discourage the amount of memory interaction above. Here''s the new version of the C: register unsigned char temp; register int i = 0; register unsigned char* data = RawData; for( ; i < m_Size * 3; i += 3 ) { temp = data[i]; data[i] = data[i+2]; data[i+2] = temp; } And the resulting assembly: ; 220 : register unsigned char temp; ; 221 : register int i = 0; ; 222 : register unsigned char* data = RawData; ; 223 : for( ; i < m_Size * 3; i += 3 ) mov eax, DWORD PTR [esi+12] add esp, 24 ; 00000018H lea ecx, DWORD PTR [eax+eax*2] test ecx, ecx jbe SHORT $L33436 mov ebp, -2 ; fffffffeH lea eax, DWORD PTR [ebx+2] sub ebp, ebx $L33434: ; 224 : { ; 225 : temp = data[i]; mov cl, BYTE PTR [eax-2] ; 226 : data[i] = data[i+2]; mov dl, BYTE PTR [eax] mov BYTE PTR [eax-2], dl ; 227 : data[i+2] = temp; mov BYTE PTR [eax], cl mov ecx, DWORD PTR [esi+12] add eax, 3 lea edx, DWORD PTR [eax+ebp] lea ecx, DWORD PTR [ecx+ecx*2] cmp edx, ecx jb SHORT $L33434 $L33436: ; 228 : } Well, it got shorter, but let''s see if we can do better... What I tried next was iterating backwards and incrementing by only 1 each time. Instead of moving i so much, I move the pointer to the data as well. register unsigned char temp; register int i = m_Size; register unsigned char* reg = RawData; while( i > 0 ) { temp = reg[0]; reg[0] = reg[2]; reg[2] = temp; reg += 3; --i; } We''re now down to using a while loop, and iterating backwards. Why did I change it like this? Well, the first important thing is that we''re now checking i against 0 instead of m_Size. Also, decrementing i is the last step. This is because a decrement call (dec in x86) will set the zero bit on the CPU if it hits 0, and we can jump back to the top of the loop based on that bit alone. Also, we''re moving reg by 3, which allows us to use constant indices into reg and avoid accessing another variable. So what does the assembly look like? ; 223 : while( i > 0 ) test ecx, ecx jle SHORT $L33436 ; 166 : } ; 167 : ; 168 : fread( &Info, sizeof(Info), 1, pBitmap ); mov ebp, ecx $L33435: ; 224 : { ; 225 : temp = reg[0]; mov cl, BYTE PTR [eax] ; 226 : reg[0] = reg[2]; mov dl, BYTE PTR [eax+2] mov BYTE PTR [eax], dl ; 227 : reg[2] = temp; mov BYTE PTR [eax+2], cl ; 228 : reg += 3; add eax, 3 dec ebp jne SHORT $L33435 $L33436: ; 229 : --i; ; 230 : } Now we''ve got some really pretty short code here. I noticed, however, that there was an extra test and jump (jle) at the beginning of the loop, since the test condition is at the beginning and if the test fails, it has to jump to the end. I removed this by using do-while, neatly moving the test to the end: register unsigned char temp; register int i = m_Size; register unsigned char* reg = RawData; do { temp = reg[0]; reg[0] = reg[2]; reg[2] = temp; reg += 3; --i; } while( i > 0 ); And of course its assembly: ; 221 : register unsigned char temp; ; 222 : register unsigned char* reg = RawData; mov eax, ebx $L33433: ; 222 : do ; 223 : { ; 224 : temp = RawData[0]; mov cl, BYTE PTR [edi] ; 225 : RawData[0] = RawData[2]; mov dl, BYTE PTR [edi+2] mov BYTE PTR [edi], dl ; 226 : RawData[2] = temp; mov BYTE PTR [edi+2], cl ; 227 : RawData += 3; add edi, 3 ; 228 : --i; dec eax ; 229 : } while( i > 0 ); test eax, eax jg SHORT $L33433 Now, after having rearranged the code and giving the compiler a few hints, we''re down to just a handful of instructions (9 to be exact). The only thing left bothering me was the test/jg pair at the end of the loop. It should only take a single instruction to loop back; jump if the 0 bit isn''t set. However, this isn''t what I wrote! I told it to check i > 0. Changing this last line to i != 0 yielded: register int i = m_Size; register unsigned char temp; register unsigned char* reg = RawData; do { temp = reg[0]; reg[0] = reg[2]; reg[2] = temp; reg += 3; --i; } while( i != 0 ); And its assembly output: ; 221 : register unsigned char temp; ; 222 : register unsigned char* reg = RawData; mov eax, ebx $L33434: ; 223 : do ; 224 : { ; 225 : temp = reg[0]; mov cl, BYTE PTR [eax] ; 226 : reg[0] = reg[2]; mov dl, BYTE PTR [eax+2] mov BYTE PTR [eax], dl ; 227 : reg[2] = temp; mov BYTE PTR [eax+2], cl ; 228 : reg += 3; add eax, 3 ; 229 : --i; dec ebp ; 230 : } while( i != 0 ); jne SHORT $L33434 And voila! We are down to a mere 8 instructions, the same length as the handwritten assembly I "stole" from NeHe to do this a few weeks back. More importantly, it''s still written in C++, not assembly, so it maintains all of its portability across architectures and doesn''t look totally meaningless to someone unfamiliar with assembly. To be fair, the new C++ block is somewhat less obvious in purpose than the original, but a quick comment is all it takes to help someone else see what is going on. The point of this whole example is basically that just because it''s a high level language doesn''t mean you can do whatever the hell you want and let the compiler try and sort it out into fast assembly. You have to write your code to give it hints about what you''re trying to do and how you want it done, and this is hard to do unless you actually know assembly. The concepts of handwritten assembly are important, even if actually writing the stuff isn''t. This new C++ code runs at over double the speed of the original loop, and actually saves a lot of load time if you have a significant number of bitmaps. Now I''m beginning to think this should''ve been an article, but it''s too late for that, isn''t it

General and Gameplay Programming Programming

Started by Promit March 06, 2004 10:04 AM

39 comments, last by Promit 20 years, 1 month ago

Jan Wassenberg

1,000

March 09, 2004 07:45 AM

What problems? It''s part of core OpenGL, BTW.

I understand and agree, which is why I was pointing out that the actual code (rgb_to_bgr) was irrelevant

E8 17 00 42 CE DC D2 DC E4 EA C4 40 CA DA C2 D8 CC 40 CA D0 E8 40E0 CA CA 96 5B B0 16 50 D7 D4 02 B2 02 86 E2 CD 21 58 48 79 F2 C3

Tip: Writing assembly-friendly C

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Tip: Writing assembly-friendly C

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines