Forum

Z PMD 85 Infoserver

:: späť na zoznam tém ::
Správa
Autor  Autor ::  Libor L.A.
Poslaná  Poslaná ::  17.03.2014 18:18:31
Predmet  Predmet ::  Chybné trasování RST1 s následnou pseudoinstrukcí DB
Ahoj,

když v debugeru pod verzí PMD-85/2A trasuji sekvence PMD BASICu, tak pokud se pokusím trasovat instrukci RST1 s následným datovým bajtem (ten si RST1 použije pro test a přeskočí jej) tak při trasování klávesou F7 je vše OK ale při trasování klávesou F8 (trasování bez vnoření - krok přes) to skočí někam do BIOSu (adresa skoku se různí). Konkrétně jsem si nastavil breakpoint na adresu 22C8h a tam po pár bajtech na adrese 22DAh je ono místo, kde to zhavaruje. Zkuste si ten breakpoint nastavit a zadat třeba DIM A$(3) a pak DLOAD 02;A$(0).

Při prvním stisku F8 a pokusu při překročení té instrukce RST1 mi to zdánlivě nic nedělá a při druhém to někam neřízeně skočí. Co s tím?
 
Správa
Autor  Autor ::  Roman Bórik
Poslaná  Poslaná ::  17.03.2014 19:45:36
Predmet  Predmet ::  Re: Chybné trasování RST1 s následnou pseudoinstrukcí DB
It is not a bug, it is feature...

Pri stlačení F8 (Krok cez) sa nastaví "interný break-point" na adresu za aktuálnu inštrukciu a ak sa jedná o CALL alebo RST, tak sa procesor prakticky normálne pustí ďalej. "Návrat" do debuggera sa prevedie po narazení na adresu interného break-pointu.
Keďže ale RST 1 posúva pôvodnú návratovú adresu o 1 ďalej (preskok očakávaného znaku v BASICovom riadku), tak sa vlastne preskočí aj nastavený interný break-point a procesor beží ďalej.
Robiť sa s tým nedá asi nič, pretože debugger nemôže vedieť, že práve volaná rutina využíva nejaké dáta za samotnou inštrukciou CALL/RST a návrat z rutiny je až za týmito dátami.

Pripúšťam, že Tebou popísané chovanie je mätúce aj kvôli tomu, že okno debuggera zostane zobrazené, aj keď procesor už nie je zastavený. Môžem tam dať skrývanie okna debuggera pri stlačení F8 a vykonávaní CALL/RST, len neviem, či to nebude rušivé.
 
Správa
Autor  Autor ::  Libor L.A.
Poslaná  Poslaná ::  18.03.2014 05:33:04
Predmet  Predmet ::  Re: Chybné trasování RST1 s následnou pseudoinstrukcí DB
I tak se mi to moc nezdá, protože ten falešný bajt za instrukcí RST1 lze v jednom případě interpretovat jako DAD H (kód pravé kulaté závorky) a přesto to na tomto kódu zhavaruje. No nic, teď už to vím, dnes odpoledne další pokus o pochopení a komentář dvojice DLOAD/DSAVE.

Díky za odpověď.
 
Správa
Autor  Autor ::  Roman Bórik
Poslaná  Poslaná ::  18.03.2014 08:37:14
Predmet  Predmet ::  Re: Chybné trasování RST1 s následnou pseudoinstrukcí DB
Ale tu vôbec nejde o to, čo sa nachádza za (v tomto prípade) RST 1. Skrátka, aby sa debugger zastavil za emulovanou inštrukciou, tak sa musí do PC dostať adresa, ktorá je za touto inštrukciou. Ale keďže emulovaná inštrukcia CALL/RST neprevedie návrat na očakávanú adresu, tak sa tam ani nezastaví.

Napadá mi, že by sa toto dalo riešiť iným spôsobom. Ak by sa vykonávala inštrukcia CALL/RST, tak by sa odpamätala hodnota SP a po vykonaní každého RET by sa testovalo, či sa SP dostalo na pôvodnú hodnotu. Ak áno, debugger by sa zastavil po návrate na danom mieste.
 
Správa
Autor  Autor ::  Martin Bórik
Poslaná  Poslaná ::  18.03.2014 08:31:31
Predmet  Predmet ::  Re: Chybné trasování RST1 s následnou pseudoinstrukcí DB
Odjakživa, vo všetkých debuggeroch, na všetkých platformách funkcia "Step Over" fungovala takto. Veď samotné "Step Over" presne popisuje, ČO sa udeje. Je jedno či je tam DAD x, alebo čokoľvek iné, keď sa na to miesto ukazovateľ PC nikdy nedostane, nemyslíš? :)
 
Správa
Autor  Autor ::  Libor L.A.
Poslaná  Poslaná ::  18.03.2014 17:14:23
Predmet  Predmet ::  Re: Chybné trasování RST1 s následnou pseudoinstrukcí DB
To jak se chová debuger při trasování RST1 mi Roman vysvětlil, to chápu, a popsané vysvětlení přesně sedí na to, co se mi stalo.

Ale i když debuger nenašel tu svou interní zarážku a program tedy běžel, reagoval debuger na stisk F8 a po jeho stisku se zastavil o kus dál v programu (to už běhal program ve smyčce čekání na bajt z MGF). Ty interní zarážky se mi jakoby nakotily na adresách 889x a program se při každém stisku F8 zastavil na některé z těchto adres. A tam se určitě zarážka kvůli RST1 nevkládala.

Ale v zásadě o nic nejde, tohle asi nikomu vadit nebude. Ten kdo to potřebuje, ten přijde na to, kde je zakopaný pes a obejde to jinak. Ale přimlouval bych se za "zhasnutí" okna debugeru v tomto případě, jak psal Roman výše.
 
Správa
Autor  Autor ::  Busy
Poslaná  Poslaná ::  21.03.2014 10:02:05
Predmet  Predmet ::  Re: Chybné trasování RST1 s následnou pseudoinstrukcí DB
Ja osobne sa priklanam za ponechanie okna debuggera s tym ze funkcia step-over by sa vykonavania prave tym testovanim SP po kazdom RET-e.

Je mi jasne, ze step-over sa odjakziva a vzdy robil breakpointom za instrukciou (aj MRS debuger ho tak robi) ale zase treba sa na to pozriet tak, ze pri debugovani v realnom systeme, kde je procesor fyzicka suciastka, to asi inak ani nejde, kdezto ked mame procesor emulovany, mame ho vo svojej plnej moci a mozeme si jeho internu funkcionalitu rozsirovat ako chceme.

Popripade by sa uzivatel pomocou dvoch zaskrtavatok mohol sam rozhodnut ci chce okno zhasinat a aky sposob vykonavania step-over chce mat :)
:: späť na zoznam tém ::