ascii adder

[zedd151]

oh - well, if it runs well on your machine, i will finish the code
i am using an older P4 model CPU

My computer is a piece of  ^%$*^$#%#*^ also.

Interested to see the numbers from your machine using the same testbed.

My computer could be generating false results. It seems ok for side by side comparison though.

Not sure if the numbers actually represent actual cycles, though.

If your interested, the fast algo is attached to the first post of the thread, among other places.

As for my 'fast' algo, it seems about as fast as it can be. using the call to StrLen only offered slight improvement over using the macro. I tried unrolling the macro, but not much improvement.

All in all, I am satisfied with it.

It was a good experience. Thank you for some of your ideas, and different approaches to consider.

It was a nice little exercise.

zedd

[dedndave]

try this one
notice that the result may not be left-justified in the buffer
but, the result address is returned in EAX

Code: [Select]

AddAscii PROTO :LPSTR,:LPSTR,:LPSTR

Code: [Select]

;***********************************************************************************************

        ALIGN   16

AddAscii PROC USES EBX ESI EDI lpszVal1:LPSTR,lpszVal2:LPSTR,lpszResult:LPSTR

;Call With: lpszVal1   = address of first ASCII decimal input string
;           lpszVal2   = address of second ASCII decimal input string
;           lpszResult = address of result buffer (assumed to be large enough)
;
;  Returns: EAX        = address of result string
;
;Also Uses: EBX, ESI, EDI, EBP are preserved

;--------------------------------

        .DATA
        ALIGN   4

AddAscTable db 60h,62h,64h,66h,68h,6Ah,6Ch,6Eh,70h,72h
            db 61h,63h,65h,67h,69h,6Bh,6Dh,6Fh,71h,73h

;--------------------------------

        .CODE

    mov     edi,lpszVal1
    mov     esi,lpszVal2
    INVOKE  StrLen,edi
    xchg    eax,ebx
    INVOKE  StrLen,esi
    mov     edx,lpszResult                  ;EDX = base address of result buffer
    .if eax<ebx
        xchg    eax,ebx                     ;EDI,EBX = address,length of shorter input
        xchg    esi,edi                     ;ESI,EAX = address,length of longer input
    .endif
    add     edx,eax                         ;EDX = address of last result byte
    lea     esi,[esi+eax-1]                 ;ESI = address of last input byte (longer)
    xor     ecx,ecx                         ;ECX = 0
    sub     eax,ebx                         ;EAX = length difference (ripple carry count) (clears CF)
    mov byte ptr [edx+1],cl                 ;null terminate result
    push    eax                             ;save ripple carry count
    mov     eax,ecx                         ;EAX = 0
    lea     edi,[edi+ebx-1]                 ;EDI = address of last input byte (shorter)
    .repeat
        mov     cl,[esi]
        dec     esi
        adc     cl,[edi]
        dec     edi
        mov     al,AddAscTable[ecx-60h]
        shr     eax,1
        dec     ebx
        mov     [edx],al
        lea     edx,[edx-1]
    .until ZERO?
    pop     ecx                             ;recall ripple carry count
    rcl     ebx,1                           ;EBX has the last carry bit
    .while (ecx) && (ebx)
        mov     al,[esi]
        inc     al
        dec     esi
        .if al==3Ah
            mov     al,30h
        .else
            mov     bl,bh
        .endif
        mov     [edx],al
        dec     ecx
        lea     edx,[edx-1]
    .endw
    .while ecx
        mov     al,[esi]
        dec     esi
        mov     [edx],al
        dec     ecx
        lea     edx,[edx-1]
    .endw
    lea     eax,[edx+1]
    ret

AddAscii ENDP

;***********************************************************************************************

[zedd151]

here ya go, dave..

Code: [Select]


dave AddAscii new
4951
4860
4860
4898
4882

Press any key to continue ...


[dedndave]

well, that went to shit - lol
let me see if i can improve the last parts

[zedd151]

let me see if i can improve the last parts

That's ok dave. I'm done with it.

You can still try, though.

Next Topic:

Ascii Subtractor.

After that, Ascii Multiplier! (The divider will be a lot of work, dunno if I'd even attempt it)

[rrr314159]

Could you set up my original algo - the faster one - in your testbed for better comparison?

- I hope I did it right used ascii_adder_4, got about 2100 cycles (varies +/- 100). Whereas using your adder_counts, it gets about 1600 (+/- 10). I already knew your (actually dedndave's, I believe) method is more stable (mine is made for on-the-fly performance analysis instead of stability, so is useful in its own way) but it seems your counter also gives a lower number, by about 25%. Fortunately they're both consistent so can still be used for comparison purposes. Anyway, my algo appears a bit slower (about 2400, after some fixes). But it's so different I can't immediately put it into your count algo. If I find the time I'll make it of the same form (a proc which accepts 3 inputs); seems worth the trouble for me to get on board with everyone else's approach - not just for this project, but for the future also. Let you know how it comes out.

[zedd151]

. But it's so different I can't immediately put it into your count algo.

I had the same problem. Very different coding styles. Not that there is anything wrong with that.

Let you know how it comes out.

Sounds good. Was a fun little project, wasn't it?

[dedndave]

here's what i recommend....

create a routine that converts large ascii decimal strings into large binary integers (aka arbitrary integers)
create another routine that converts large integers into strings
well - we already have that one - Ding Dong Cafe - lol

now, write routines that add, subtract, multiply, and divide arbitrary integers

if you just want to add 2 strings together,  working directly on ascii may be ok
but, if you want to do more manipulation than just one operation, binary routines will be considerably faster

convert the string(s) to binary
do the math
convert the result back to a string

[dedndave]

a routine that converts large ascii strings to integers could be done using the Ling Long Kai Fang method (Horner's Rule)

[zedd151]

....convert the string(s) to binary
do the math
convert the result back to a string

I know that.  :P

It was just a litle coding exercise. Subtraction, I magine will be pretty much the same.
Multiplication will be more complex. Division, forget it using the Ascii methods.

Better idea, buy a decent calculator or math software. :P

Yeah, I know you like your 'Moo Goo Guy Pan' procedures.  :lol:

[dedndave]

well, there are "BigNum" libraries out there
most of them are limited to 256 or 512 bits of precision, though

if you want fast, learn to use the FPU and SSE floats
even though they are limited in both precision and range, multiple-precision routines can be developed to extend them

for example, an 80-bit FPU real has 64 bits of binary precision
but, if i carry a single value in two 80-bit reals, it can have 128 bits of precision
and - math will be much faster than discrete integer math

[dedndave]

a single value, then, might be expressed as two reals (A and B)

N = B *2⁶⁴ + A

[zedd151]

well, there are "BigNum" libraries out there

Absolutely.

if you want fast, learn to use the FPU and SSE floats

I tried once or twice learning FPU, but it's a different animal than I am used to.

- math will be much faster than discrete integer math

Undoubtedly.

Was a fun project though.  8)

[dedndave]

the FPU isn't that bad   

you just have to learn to keep track of values on the FPU stack, is all

the FPU is like an 8-shooter, with a rotating cylinder
the "top of stack" is the one in the barrell at the time - lol

[zedd151]

the FPU is like an 8-shooter,

You frighten me.  :lol:

 From time to time, I do look at Raymonds FPU tutes.

But this old brain is no longer a very absorbent sponge.

More like a sponge that was squeezed too often.  :P