Forum

From PMD 85 Infoserver

Jump to: navigation, search
:: back to start of topic :: back to topic list ::
Message
Author  Author ::  Roman Bórik
Posted  Posted ::  2014-03-17 07:45:36 PM
Subject  Subject ::  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é.
 
Message
Author  Author ::  Libor L.A.
Posted  Posted ::  2014-03-18 05:33:04 AM
Subject  Subject ::  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ěď.
 
Message
Author  Author ::  Roman Bórik
Posted  Posted ::  2014-03-18 08:37:14 AM
Subject  Subject ::  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.
 
Message
Author  Author ::  Martin Bórik
Posted  Posted ::  2014-03-18 08:31:31 AM
Subject  Subject ::  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íš? :)
 
Message
Author  Author ::  Libor L.A.
Posted  Posted ::  2014-03-18 05:14:23 PM
Subject  Subject ::  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.
 
Message
Author  Author ::  Busy
Posted  Posted ::  2014-03-21 10:02:05 AM
Subject  Subject ::  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 :)
:: back to start of topic :: back to topic list ::