; input number in ecx
mov eax, 0x4EC4EC4F
mul ecx
shr edx, 3
imul eax, edx, 26
sub ecx, eax

; ecx = last digit, do stuff with it

mov ecx, edx  ; next input

; now loop until ecx = 0    

    mov     eax,274
        mov     ebx,0x4ec4ec4f
        xor     edx,edx
        mul     ebx
        shr     edx,3
        mov     ecx,edx   ;first digit
        mov     eax,edx
        mov     ebx,26
        mul     ebx
        mov     esi,274
        sub     esi,eax   ;second digit    

Multiplying the result by the divisor and the subtracting from original number is an universal method of obtaining the remainder, no matter what algorithm was used to divide. However, even in case of division through multiplication by a "magic" number it is possible, at least in some cases, to have remainder obtained directly from the main algorithm. See what I wrote about my alternative approach to these techniques.

... slower than a regular DIV .... not any better than a regular DIV

fasmnewbie wrote:

... slower than a regular DIV .... not any better than a regular DIV

"slower" depends upon the system being used. Some systems may be faster, some slower, some the same.

"better" is a subjective term. Different people will interpret that differently. Maybe you can qualify in which way you suggest it is better. For readability? For "speed"? For ease of programming? For fewer instruction bytes? Something else?

Multiplying the result by the divisor and the subtracting from original number is an universal method of obtaining the remainder, no matter what algorithm was used to divide. However, even in case of division through multiplication by a "magic" number it is possible, at least in some cases, to have remainder obtained directly from the main algorithm. See what I wrote about my alternative approach to these techniques.

Ofc you can always start from the back digits, if you focus your algorithm that way. But by doing so, you're making your algoritm even slower than a regular DIV. It is pointless. It involves 3 MULS even before you get to the next iteration. If you're doing it from the back, just use a DIV ;D

It's 2 muls, but I have a hard time understanding how div can be "faster"

According to Agner (for my CPU), mul/imul have like 3 clock cycle latency, and div is like 22-29 (for 32-bit number, for 64-bit numbers it's even more). 2 serial muls would have combined 6 clock cycle latency which is still far from 22, even if you add the sub (1 clock cycle).

Ali.A wrote:

and honestly i dont wanna create a c/c++ program and reverse engineer it to find what function is that.

I just call printf with the hex formatting string.
https://stackoverflow.com/questions/3649026/how-to-display-hexadecimal-numbers-in-c

say i have a string in my file: 4001FC8 as a hex.

converting from base16 to 10 is difficult to me. (ive no idea too)

; input:  ESI pointer to string buffer
; output: EAX

HexToDword:
    push ebx esi
    xor ebx, ebx
    cld
    .loop:
    lodsb
    test al, al
    je .return
    sub al, '0'
    cmp al, 10
    jl @F
    sub al, 7
    @@:
    shl ebx, 4
    or bl, al
    jmp .loop
    .return:
    mov eax, ebx
    pop esi ebx
    ret
    

i think my main problem with consoles are:
displaying and clearing the console screen.

; data section    
    dwCoord dw 40,10

; data section 
    dwCoord dd 0x000A0028

; data section 
    dwCoord:
     x dw 40
     y dw 10
    

; code section
    invoke SetConsoleCursorPosition, dword [hOut], dword [dwCoord]
    

    sub al, '0'    ; subtract 48 from the char
    cmp al, 10     ; see if it was a digit 0-9 and not a letter (assume A-F)
    jl @F          ; jump if it was a digit
    sub al, 7      ; convert char to letter
    @@: 
    shl ebx, 4     ; get space for next nibble
    or bl, al      ; store the nibble