Server Help

[Cyan~Fire]

Trying to read the ASM Ekted posted here. And I'll have a few questions which I'll post them here.

First: I see xor with the same register as both operands a lot. My best guess is that this is some more efficient way of doing mov eax,0. Am I right?
_________________
This help is informational only. No representation is made or warranty given as to its content. User assumes all risk of use. Cyan~Fire assumes no responsibility for any loss or delay resulting from such use.
Wise men STILL seek Him.

[Bak]

It's not faster, just a different way of doing it.
_________________
SubSpace Discretion: A Third Generation SubSpace Client

[Cyan~Fire]

Then why do it? It's a little easier to read the other way...

[Dr Brain]

Job security
_________________
Hyperspace Owner

Smong> so long as 99% deaths feel lame it will always be hyperspace to me

[Mr Ekted]

On the Pentium, MOV EAX, 0 and XOR EAX,EAX are 0.5 clocks latency and 0.5 clocks throughput. However, the former is 6 bytes long, and the latter is 2. Job security.
_________________
4,691 irradiated haggis!

[Cyan~Fire]

Ok, thanks.

Second:

Code: Show/Hide :0041BEF9 8D0480            lea eax, dword[eax+4*eax] :0041BEFC 8D0480            lea eax, dword[eax+4*eax]

WTF? I realize this is probably some ASM newbie "Hah! He doesn't recognize that!" thing... but WTF?

[Bak]

lea = load effective address

put an address somewhere... not the memory itself... you can do math using leal, as it is doing in this case

[Cyan~Fire]

So you're saying it's basically just the equivalent of imul 25?

[Mr Ekted]

Ya you can do all sorts of multiplies using chains of LEA ops. The throughput of MUL is 5 cycles since it must function on arbitrary data. The throughput of LEA is 0.5 cycles since it works in very constrained ways.

[CypherJF]

ya okay i feel dumb lol... i haven't learned ASM :/
_________________
Performance is often the art of cheating carefully. - James Gosling

[Cyan~Fire]

OK, thanks again to both of you.

Third: Now I have a questions about random numbers in SS. I remember reading somewhere that the key for the keystream is always negative. Now looking at catid's SS_HEAVY_PRNG (which, he says, is used to generate the keystream), the seed is stored unsigned. How does this work?

Fourth:

Code: Show/Hide :0041BEEF 99                cdq    :0041BEF0 F7F9              idiv ecx     ; } :0041BEF2 8BC2              mov eax, edx ; } modulus

What is that cdq doing there? I read that cdq will extend the sign bit of eax through edx but edx is clobbered by the idiv right after, so nothing is really done....... right?

Oh, and cyph, why you really should feel dumb is because you tried to derail my precious!

[Mr Ekted]

IDIV uses the 2 registers EDX:EAX as the source.

[Cyan~Fire]

Oh, haha, didn't see that in the docs. Maybe it would help if I had 32-bit docs instead of 16-bit ones. Does anybody have a good opcode list for 32-bit ASM?

[Mr Ekted]

http://developer.intel.com/design/Pentium4/documentation.htm

Search for "Manuals".

[Cyan~Fire]

Jeez, P4 has way too many opcodes. But, uhhh, thanks.

OK, fifth, about the prng:

Code: Show/Hide :0041BF34 3BCD              cmp ecx, ebp :0041BF36 8BF1              mov esi, ecx :0041BF38 7F06              jg 0041BF40 :0041BF3A 8DB1FFFFFF7F      lea esi, dword[ecx+7FFFFFFF]

The transformation of the seed occurs in ecx before it's finally stored in esi.
Here's catid's code:

Code: Show/Hide if (s > 0x7fffffff) s += 0x7fffffff;

How does that ASM translate to that C?

[Bak]

Code: Show/Hide :0041BF34 3BCD              cmp ecx, ebp :0041BF36 8BF1              mov esi, ecx :0041BF38 7F06              jg 0041BF40 :0041BF3A 8DB1FFFFFF7F      lea esi, dword[ecx+7FFFFFFF]

if (ebp > ecx)
{
esi = ecx
goto 0041BF40
}
else
{
ecx = esi
esi = ecx + 0x7FFFFFFF
}


my order might be wrong cause I know gdb's assembly order is different from microsoft's.

ekted, what program do you use to produce assembly

[Cyan~Fire]

Looking further up in the code, it seems ebp is set to zero. So, I've basically figured this out:

Code: Show/Hide    /*    cmp ecx, ebp    mov esi, ecx    jg 0041BF40    lea esi, dword[ecx+7FFFFFFF]    */    seed = nseed;    if (nseed <= 0)       seed += 0x7FFFFFFF;

But one small question remains. 0x7FFFFFFF is the highest possible positive dword, so catid's code adds that number to the seed if it's less than 0 but it seems it's really if the seed's less than or equal to 0. Anybody see where I'm going wrong?

[Mr Ekted]

Powerbot's implementation uses <= 0.

[Cyan~Fire]

Oh, alright, cool. I'll talk to Catid about that sometime.

Sixth:

Code: Show/Hide //   :0041BF40    a = seed;    /*    cdq    xor eax, edx    sub eax, edx    and eax, 00000003    xor eax, edx    */    d = (a < 0) ? 0xFFFFFFFF : 0;   //cdq    a ^= d;    a -= d;    a &= 1;    a ^= d;    /*    mov ebx,eax    ...    sub ebx,edx    neg ebx    ...    sbb ebx,ebx    */    b = (a - d == 0) ? -1 : 0;    b &= 17;   //get 000X000X

Now edx is either -1 or 0, depending on whether eax is negative. But now in the above PRNG code, the seed was always return positive. Am I missing something? Is most of the above code actually useless?

[Mr Ekted]

The C code is trying to mimic what the ASM is doing line-for-line. I believe this RNG (from VIE) is only good for 31 bits, so the output is modified so the upper bit is always 0. This is a translation I made of it, but do not use:

Code: Show/Hide DWORD ssRNG (DWORD seed) { DWORD s; s = (DWORD)(((__int64)seed * 0x834E0B5F) >> 48); s += s >> 31; s = ((seed % 0x1F31D) * 16807) - (s * 2836) + 123; if (!s || s > 0x7fffffff)  // (LONG)s <= 0    s += 0x7fffffff; return (s); }

[Cyan~Fire]

Well this is what I had (and still have):

Code: Show/Hide inline int SS_prng(int seed) {    int nseed, temp;    /*    mov eax, esi   ; esi = seed    mov ecx, 0001F31D    cdq    idiv ecx      ; }    mov eax, edx   ; } modulus    shl eax, 03    sub eax, edx    lea eax, dword[eax+4*eax]    lea eax, dword[eax+4*eax]    shl eax, 04    add eax, edx    lea eax, dword[eax+2*eax]    lea ecx, dword[edx+2*eax]    */    nseed = (seed % DIV_C) * 16807;    /*    mov eax, 834E0B5F    imul esi    add edx, esi    sar edx, 10    mov eax, edx    shr eax, 1F    add edx, eax    lea eax, dword[edx+8*edx]    shl eax, 03    sub eax, edx    lea eax, dword[eax+4*eax]    shl eax, 1    sub eax, edx    shl eax, 02    sub ecx, eax    */    temp = IMULHIDWORD(MULT_C, seed) + seed;    temp = (temp >> 16) + (temp >> 31);   //aka the sign bit    nseed -= (temp * 2836);    nseed += 123;    /*    cmp ecx, ebp   ;above, ebp = 0    mov esi, ecx    jg 0041BF40    lea esi, dword[ecx+7FFFFFFF]    */    seed = nseed;    if (nseed <= 0)       seed += 0x7FFFFFFF;    return seed; }

Looks basically the same, except uses asm's imul instead of __int64. But that's actually kinda irrelevant.

What I was trying to ask is that if the left-most bit is always 0, then the return is always positive, right? Thus, cdq'ing the seed and then xor'ing it by edx is never going to modify it. edx will always be 0. Am I right? I'm trying to make something to test it right now...

[Cyan~Fire]

Here's my test prog, using the same SS_prng func I pasted earlier. Only output was "Done.".

[Mr Ekted]

Using signed type for seed instead of unsigned can affect the results of operations. Are you sure it matches the output of the origional ASM for a large number of different seeds??

[Cyan~Fire]

This didn't show anything wrong. I couldn't use the original ASM because MSVC++ didn't like it.

[Cyan~Fire]

Code: Show/Hide :0041C2AF 64890D00000000    mov dword fs:[00000000], ecx

OK, can anybody explain what that means?