fjrp2, how does that work for multiple digits?
Posted on 2002-05-31 13:56:54 by bitRAKE

Nexo, what assembler do you use?
movzx eax, [[b]b,[/b] esi-1]

I am use assembler with modified TASM Ideal mode syntax :)
Posted on 2002-06-01 07:30:00 by Nexo


adtodw proc pString:LPSTR

; Convert sign decimal string into dword value

option PROLOGUE:NONE
option EPILOGUE:NONE

push esi

xor eax, eax
mov esi, [esp + sizeof DWORD * 2]
xor ecx, ecx
mov al, [esi]
xor edx, edx
cmp al, "-" ; sign ?
jne @F
inc esi
not edx
jmp @F

adtodw_loop:
inc esi ; next char
lea ecx, [ecx + ecx*4] ; * 5
lea ecx, [eax + ecx*2] ; ecx = ecx*10 + eax
@@:
mov al, [esi]
sub al, "0"
jns adtodw_loop ; loop if not end of string

lea eax, [edx + ecx]
pop esi
xor eax, edx

ret sizeof DWORD

option PROLOGUE:PROLOGUEDEF
option EPILOGUE:EPILOGUEDEF

adtodw endp


Works a bit faster then Svin's version (for my PIII).
10% - 23% for big numbers (sign-dependent)
37% for small
And two bytes smaller ;-)
Posted on 2002-06-02 07:36:59 by Four-F
Talking of faster \ slower percentage,
the test programm should follow.
Posted on 2002-06-02 09:16:28 by The Svin
Sorry, did mistake in result correction.
With right correction beter performance:
22% - 65% (sign/value-dependent) on PIII
Posted on 2002-06-03 04:27:50 by Four-F
I checked it.
The only noticeble difference in your version is prolog. And the prolog is identical to my previous version.
No about why I chenged it and why you can not mesure the effect with your test.
I did it to remove branching it prolog to main loop.
You can not see effect of it simply cause you call it numerouse time passing the same string.
After second call it will be predicted.
To estimate effect you need before each call replace digit symbol in string to "-" and next time back to digit and so with replace it each time before call, then it would seem more accurate.
Now about range of result depening on string length.
Simple see persentage of all possibilities to array of possibilities with current length.
If you know math you can see relation and so it's funny even mention of 1 or 2 digit length strings :)
If you need fast proc for strings upto 4 digits in critical part of your proc - never use either yours or mine version. There are mucth faster way to do it.
atodw for even possible cases
that means realation in billions in favor to long strings.
Posted on 2002-06-03 05:37:39 by The Svin
To bitRAKE,
I?m sorry couldn?t read your question before, took a long holiday ;)
You can "manipulate" four digits at a time with this:


MOV EAX, "1234"
SUB EAX,030303030h
invoke DecToHex ;From any math lib ;)

That?s it; it works fine and VERY FAST for multiples of 4
The remainer digits can be displayed using the other.

By the way, (and this is just a personal thought) I have recently found a quote by you:

"Water is guided down the stream by the banks. Over great periods of time the stream may change the banks and hence it's own path. In short time, through great destruction the stream may change it's course, but new banks will guide the stream."

What do you exacyly mean?


Regards,
Posted on 2002-06-04 11:29:39 by slop

To bitRAKE, by the way, (and this is just a personal thought) I have recently found a quote by you:

"Water is guided down the stream by the banks. Over great periods of time the stream may change the banks and hence it's own path. In short time, through great destruction the stream may change it's course, but new banks will guide the stream."

What do you exacyly mean?
Sorry, I have missed this question before now. The statement is a metaphor. I seek answers in nature and the universe as they have been here long before us. It might help to read the original discussion, or maybe not. ;) Imagine yourself as the water and life as the stream - we work so hard to change the course sometimes. Don't get me wrong - I'm not talking about fate - I don't believe in fate, but I do know there was much here before me.
Posted on 2002-09-21 11:23:41 by bitRAKE
Thank you bitRAKE,

I also forgot all about it.
But you had almost answered me back in an e-mail about your view of life.

Very interesting thread that started it all btw.

As I have always said, if you write a virus, make it perform cool actions (like improving the speed of your system, eliminating redundant code, cleaning the resources rapidly...) so that if you get caught, no legal action can be taken against you... (hey they should even thank you for that)
I also agree with Maverick's idea of let's call them 'profilaxis', which means protection, the same that you take measures against hard disc crashes etc
(yes, and talking about hard-disc krashes, I'm an expert here... ;) )

So let?s let water be water, and let's splash the living fun of it all (imho)
Posted on 2002-09-23 12:21:36 by slop
xor ecx,ecx
mov edx,10
lea ebx,NumberBuffer
mov cl,byte ptr
atoi: sub cl,30
mul edx
add eax,ecx
inc ebx
mov cl,byte ptr
cmp cl,0
jne atoi
mov Number,eax

Can I use this code above to convert ascii to int,please?NumberBuffer point to a ascii string,and result in eax.
thaaaaaanx!!
Posted on 2002-09-24 07:56:56 by smartcurl
smartcurl your code will fail for any number greater than 9.

The reason being:
mul edx returns a 64 bit value in eax:edx, this means that the result of the first multiply will result in edx being zero (assuming that eax is zero, which isn't in the code, but would be sensible). Hence on the second itteration of the loop, you would be multiplying eax by 0, resulting in zero.

In order to solve the problem, bring the mov edx, 10 within the loop, or replace the mul with


lea eax, eax*4 + eax
add eax, eax

This should be faster anyway!

Also for performance reasons, replace the mov cl, with movzx ecx, BYTE PTR .
This will avoid partial register stalls on the P6 core (Pentium pro, P2, and P3).

Mirno
Posted on 2002-09-24 11:41:52 by Mirno
I will try your suggestion.Thank you!:alright:
Posted on 2002-09-24 19:27:49 by smartcurl
After I change my code, the compiler say:"invalid use of register".Maybe you want to say is this:
lea eax,
add eax, eax
Posted on 2002-09-24 19:51:48 by smartcurl