🚀 go-pugleaf

W dniu 05.07.2011 18:01, Remek pisze:
> Użytkownik "Bogdan (bogdro)" napisał:
> 
>>> Podzieliłem to na dwordy, aby było lepiej widoczne. Liczby są
> przypadkowe,
>>> ale obrazują problem. jak zrobić, aby było dobrze?
> 
>> Po każdym JA dodajesz "JNE nie_obl_reszt". Aby "iść dalej" w
>> porównywaniu, na starszych pozycjach nie może być różnicy. W ten
>> sposób dla tych dwóch liczb, porównywanie skończy się po pierwszym
>> kroku, ale pierwszy skok JA nie zostanie wykonany. Jeśli miałbyś liczby:
>>
>> wejście = 0A9F 0F8C 33C4
>> wynikmn = 0A9F 2F8C 33C4
> 
>> to po pierwszym porównaniu nie zostaje wykonany ani JA, ani JNE i
>> porównywane są kolejne DWORDy, co doprowadzi do prawidłowej
>> odpowiedzi.
> 
> To sprawdzenie mam w procedurze pierwiastkowania dużych liczb. Wygląda to
> tak:
> 
> ========================================
> 
> mnoz_dalej:
> 
>  call mnozenie
>  jc  obl_reszt  ; to zabezpiecza program przed nieskończoną pętlą
> 
>  mov eax, dword ptr [wynikmn+4]
>  cmp eax, dword ptr [wejscie+4]
>  ja  obl_reszt
>  jb  mnoz_dalej
> 
>  mov eax, dword ptr [wynikmn]
>  cmp eax, dword ptr [wejscie]
>  ja  obl_reszt
> 
>   .........
> 
> ==========================================
> 
> I to działa z wyjątkiem przypadku kiedy oba dwordy są sobie równe :) Co
> wtedy? Sprawdzę tak:
> 
> ========================================
> 
> mnoz_dalej:
> 
>  call mnozenie
>  jc  obl_reszt  ; to zabezpiecza program przed nieskończoną pętlą
> 
>  mov eax, dword ptr [wynikmn+4]
>  cmp eax, dword ptr [wejscie+4]
>  ja  obl_reszt
>  jb  mnoz_dalej
> 
>  mov eax, dword ptr [wynikmn]
>  cmp eax, dword ptr [wejscie]
>  ja  obl_reszt
> 
>  jmp obl_reszt
>   .........
> 
> ==========================================
> 
> Czy to wystarczy?

 Prawdopodobnie tak. Jeśli wynik mnożenia jest równy wejściowej
liczbie, to "obl_reszt" (co pewnie oznacza obliczanie reszty) powinno
zapewne zwrócić zero, więc powinno być dobrze. Ale mogę czegoś nie
wiedzieć, więc przetestuj choć dla jednego przypadku.

> Przepraszam za trucie d..., ale ja nie potrafię analizować
> kodu "na sucho", a przećwiczenie wszystkich reakcji programu na dane
> wejściowe to robota dla jakiegoś programu, nie dla człowieka.

 Po to właśnie robi się testy :) Ale nie takie, że ktoś wpisuje coś do
programu (choć te też), tylko raczej podstawia się dane i uruchamia
procedury "ręcznie".

> Mam
> kalkulator, który bez zarzutu działał przez dwa lata. Przypadkiem okazało
> się, że wynik dzielenia 704/4 to zero??? Błąd w procedurze. Młodszy bajt
> jest równy zero i cmp bajt, 0 powodowało wyjście z pętli. Paranoja. Trzeba
> było odwrócić procedurę i sprawdzać od najstarszego bajtu.

 Zdarza się. I w bardziej, i w mniej profesjonalnych programach.

>> nie napisałem tego w kursie, a raczej
>> powinienem był. W najbliższym czasie się poprawię.
> 
> Bez przesady :) Nie da się przewidzieć i opisać wszystkich zastosowań. Coś
> jednak można wspomnieć.

 Już wspomniałem :)

-- 
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): miniurl.pl/bogdro-soft