🚀 go-pugleaf

U¿ytkownik "Kamil" napisa³:

Ta procedura dzia³a b³êdnie dla niektórych danych wej¶ciowych.
Pryczyny nie znalaz³em. Mo¿e komu¶ uda siê znale¼æ b³±d?

[code]

 push edi
 push esi
 push ebx
 push ebp

 mov esi, odarg1
 mov edi, odkarg2
 mov ebx, odwynik
 mov ecx, 20

 mov eax, pam [esi]
 sub eax, pam [edi]
 mov pam [ebx], eax

odejmujemy:

 mov eax, pam [esi+4]
 sbb eax, pam [edi+4]
 mov pam [ebx+4], eax

 jc arg1_mniejszy_od_arg2

 add esi, 4
 add edi, 4
 add ebx, 4

 loop odejmujemy


arg1_mniejszy_od_arg2:

 pop ebp
 pop ebx
 pop esi
 pop edi

 mov eax, 'aw'
 jmp _do_ret_od2

_do_ret_od2:

   ret

[/code]

Pozdrawiam

W dniu 06.09.2013 03:57, Kamil pisze:
> Witam
>
> Na stronie Bogdana jest min. procedura odejmowania:
>
>
> mov eax, [arg1]
> sub eax, [arg2]     ; odejmujemy 2 pierwsze czê¶ci
> mov [wynik], eax    ; i zapisujemy wynik
>                     ; flaga CF mówi, czy by³a po¿yczka
>
> mov eax, [arg1+4]
> sbb eax, [arg2+4]   ; odejmujemy razem z po¿yczk? (CF),
>                     ; je¶li w poprzednim odejmowaniu
>                     ; musieli?my co? po¿yczaæ
>
> mov [wynik+4], eax  ; wynik: [arg1+4]-[arg2+4]-po¿yczka
>                     ; z pierwszego odejmowania
>                     ; CF teraz zawiera po¿yczkê z SBB
>                     ; podobnie reszta dzia³ania:
>
> mov eax, [arg1+8]
> sbb eax, [arg2+8]
> mov [wynik+8], eax
>
> mov eax, [arg1+12]
> sbb eax, [arg2+12]
> mov [wynik+12], eax
>
> jc arg1_mniejszy_od_arg2
>
> Moja implementacja wygl±da tak:
>
> odejmij PROC
>
> push esi
> push edi
> push ebx
> push ebp
>
>
> mov eax, [arg1]
> sub eax, [arg2]     ; odejmujemy 2 pierwsze czê¶ci
> mov [wynik], eax    ; i zapisujemy wynik
>                     ; flaga CF mówi, czy by³a po¿yczka
>
> mov eax, [arg1+4]
> sbb eax, [arg2+4]   ; odejmujemy razem z po¿yczk? (CF),
>                     ; je¶li w poprzednim odejmowaniu
>                     ; musieli?my co? po¿yczaæ
>
> mov [wynik+4], eax  ; wynik: [arg1+4]-[arg2+4]-po¿yczka
>                     ; z pierwszego odejmowania
>                     ; CF teraz zawiera po¿yczkê z SBB
>                     ; podobnie reszta dzia³ania:
>
> mov eax, [arg1+8]
> sbb eax, [arg2+8]
> mov [wynik+8], eax
>
> mov eax, [arg1+12]
> sbb eax, [arg2+12]
> mov [wynik+12], eax
>
> jc arg1_mniejszy_od_arg2
>
> arg1_mniejszy_od_arg2:
>
> pop ebp
> pop ebx
> pop edi
> pop esi
>
>   ret
>
> odejmij endp
>
> mam nastêpuj±ce pytania:
>
> - Co sie stanie w razie wyst±pienia sytuacji spe³ni±cej warunek skoku jc?

 Nic. To jest "informacja dla autora", ¿e gdyby chcia³ tê sytuacjê
obs³u¿yæ, to mo¿e zrobiæ to w ten sposób.

>  Czy linia  mov [wynik+12], eax siê wykona?

 Tak, bo jest przed skokiem.

> Jaki bêdzie wynik?

 Ten sam. Konkretnie - ujemny.

> - co siê stanie kiedy ju¿ w peerwszych argumentach bêdzie  arg1 < arg2

 Nic. Liczby bêd± siê dalej odejmowaæ, tylko flaga CF bêdzie
gdzieniegdzie ustawiona.

> - cfzy jc nie powinno byæ po ka¿dym odejmowaniu?

 Nie. Sytuacja ustawienia flagi CF jest obs³ugiwana przez zastosowanie
instrukcji SBB (odejmowanie "z po¿yczk±") zamiast SUB, czyli zwyk³ego
odejmowania.


--
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org   www.TorProject.org   Soft(EN): tinyurl.com/bogdro-soft

W dniu 06.09.2013 08:04, Kamil pisze:
> U¿ytkownik "Kamil" napisa³:
>
> Ta procedura dzia³a b³êdnie dla niektórych danych wej¶ciowych.

 Czym otrzymany wynik ró¿ni siê od oczekiwanego?

> Pryczyny nie znalaz³em. Mo¿e komu¶ uda siê znale¼æ b³±d?
>
> [code]
>
> push edi
> push esi
> push ebx
> push ebp
>
> mov esi, odarg1
> mov edi, odkarg2
> mov ebx, odwynik
> mov ecx, 20
>
> mov eax, pam [esi]
> sub eax, pam [edi]
> mov pam [ebx], eax

 Bez definicji "pam" mo¿e byæ trudno to zinterpretowaæ.


> odejmujemy:
>
> mov eax, pam [esi+4]
> sbb eax, pam [edi+4]
> mov pam [ebx+4], eax
>
> jc arg1_mniejszy_od_arg2
>
> add esi, 4
> add edi, 4
> add ebx, 4
>
> loop odejmujemy

 Wiesz, ¿e odejmujesz 21 "czwórek", prawda? ECX = 20, ale pozycjê [0]
obs³ugujesz przed pêtl±, a w pêtli obs³ugujesz pozycje [4], [8], [12],
..., [80], czyli ³±cznie bajty na offsetach od 0 do 83 w³±cznie.

> arg1_mniejszy_od_arg2:
>
> pop ebp
> pop ebx
> pop esi
> pop edi
>
> mov eax, 'aw'
> jmp _do_ret_od2
>
> _do_ret_od2:
>
>   ret
>
> [/code]
>
> Pozdrawiam
>


--
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org   www.TorProject.org   Soft(EN): tinyurl.com/bogdro-soft

U¿ytkownik "Bogdan (bogdro)" napisa³:

>> Ta procedura dzia³a b³êdnie dla niektórych danych wej¶ciowych.

> Czym otrzymany wynik ró¿ni siê od oczekiwanego?

Dla np. 633825300114114700748351602688 wynik dzielenia wynosi
554597137599850363154807652352

>> Pryczyny nie znalaz³em. Mo¿e komu¶ uda siê znale¼æ b³±d?

> Bez definicji "pam" mo¿e byæ trudno to zinterpretowaæ.

Przepraszam za przeoczenie. "pam" equ dword ptr


>> mov eax, pam [esi+4]
>> sbb eax, pam [edi+4]
>> mov pam [ebx+4], eax
>>
>> jc arg1_mniejszy_od_arg2
>>
>> add esi, 4
>> add edi, 4
>> add ebx, 4

>> loop odejmujemy

> Wiesz, ¿e odejmujesz 21 "czwórek", prawda? ECX = 20, ale pozycjê [0]
> obs³ugujesz przed pêtl±, a w pêtli obs³ugujesz pozycje [4], [8], [12],
> ..., [80], czyli ³±cznie bajty na offsetach od 0 do 83 w³±cznie.

To akurat jest jasne. Wydaje siê, ¿e jeden b³±d znalaz³em. Otó¿ je¶li po sbb
zostanie ustawiona flaga to linijki

    add esi, 4
    add edi, 4
    add ebx, 4

j± skasuj±. Ma byæ tak:

    pushf

    add esi, 4
    add edi, 4
    add ebx, 4

    popf

Okazuje siê, ¿e "skaracanie" tekstu ¼ród³owego procedur jest ryzykowne.
Lepiej stosowaæ je w pe³nym rozwiniêciu wg. Twoich tutoriali. Wtedy nie ma
problemów.

Pozdrawiam