Weird optimization

[brew]

Code Select Expand


15003510   33D2             XOR EDX,EDX
15003512   56               PUSH ESI
15003513   8910             MOV DWORD PTR DS:[EAX],EDX
15003515   8950 04          MOV DWORD PTR DS:[EAX+4],EDX
15003518   8950 08          MOV DWORD PTR DS:[EAX+8],EDX
1500351B   8950 0C          MOV DWORD PTR DS:[EAX+C],EDX
1500351E   8950 10          MOV DWORD PTR DS:[EAX+10],EDX
15003521   8D48 1C          LEA ECX,DWORD PTR DS:[EAX+1C]
15003524   BE 10000000      MOV ESI,10
15003529   8DA424 00000000  LEA ESP,DWORD PTR SS:[ESP]
15003530   8951 F8          MOV DWORD PTR DS:[ECX-8],EDX
15003533   8951 FC          MOV DWORD PTR DS:[ECX-4],EDX
15003536   8911             MOV DWORD PTR DS:[ECX],EDX
15003538   8951 04          MOV DWORD PTR DS:[ECX+4],EDX
1500353B   8951 08          MOV DWORD PTR DS:[ECX+8],EDX
1500353E   83C1 14          ADD ECX,14
15003541   4E               DEC ESI
15003542  ^75 EC            JNZ SHORT Storm.15003530
15003544   8990 54010000    MOV DWORD PTR DS:[EAX+154],EDX
1500354A   8990 58010000    MOV DWORD PTR DS:[EAX+158],EDX
15003550   8990 5C010000    MOV DWORD PTR DS:[EAX+15C],EDX
15003556   8990 60010000    MOV DWORD PTR DS:[EAX+160],EDX
1500355C   8990 64010000    MOV DWORD PTR DS:[EAX+164],EDX
15003562   5E               POP ESI
15003563   C3               RETN

?wtf?
obviously it clears w/e eax is..

called by

Code Select Expand



void *SBigNew(void *parameter1) {
                      /*size,      filename,             line #, default*/
   if (SMemAlloc(168, "Starcraft\Storm\Source\SBig.cpp", 0x051D, 0)) {
      Storm3510(eax);
      *(parameter1) = eax;
      return eax;
   } else {
      *(parameter1) = 0;
      return 0;
   }
}


But what the hell? I just don't get it. Why is it clearing all of that if the default value is already 0? Not to mention the manner in which it's done...

[iago]

The default value isn't 0, it's whatever was at that address before. I'm not sure that SMemAlloc initializes it to 0 (I guessed it did originally, but I may have been wrong). Or, even if it does, the function may not assume that the buffer is initialized, so it initializes it itself just to make sure. Functions can't always assume clean input.

And for the reason, it's likely because that's the fastest way. Looping is slow because the processor can't read ahead as easily, so unrolling it like that is faster.

It may also meant that it's not an array, but a structure. So the original code could have been:
struct1->var1 = 0;
struct1->var2 = 0;
struct1->var3 = 0;
struct1->var4 = 0;
.........

[brew]

But there is some form of a loop in the middle (note the jnz) that sets the values to 0 in 20 byte blocks...
and it looks like they could've just used their SMemZero function there.
it's an unnecessary call to some odd little function that seems to create more trouble then it saves. I think the blizzard programmer responsible for implementing this was high or something when he wrote it. Or maybe they were just bored. I'm sorry for making such a big deal out of this, it just looks so odd..

[MyndFyre]

Likely, the Blizzard programmer didn't write it in assembly.  There was probably something lost or gained in the translation.  I think that process is called "compiling".

[MrRaza]

Likely, the Blizzard programmer didn't write it in assembly.  There was probably something lost or gained in the translation.  I think that process is called "compiling".

lol

[MyndFyre]

Likely, the Blizzard programmer didn't write it in assembly.  There was probably something lost or gained in the translation.  I think that process is called "compiling".

lol

Although I appreciate knowing that I made you laugh, it was kind of a little after the fact....