[SharpMZ] Breakpointy v emu - aneb navrhujeme novy programovaci jazyk s vlastnim operacnim systemem :)

[Michal Hucik - ORDOZ]

Predpokladam, ze mas na mysli logovani jako jednu z moznych akci 
breakpointu - ci spise lepsi oznaceni by bylo "udalosti". Mohlo by se 
tam definovat neco jako format a params, ktere by se pak v bezpecne 
podobe predaly do fprintf(). V pripade takoveho logovani by se asi 
urcite hodilo mit k dispozici i variable s uplynulym casem emulace - 
udrzuju v gdg unsigned int ve kterem je celkovy pocet vykonanych snimku 
a samozrejme je k dispozici i pocet vykonanych gdg taktu v ramci 
aktualniho snimku. Tim si lze udelat predstavu o tom jak jsou od sebe ty 
udalosti casove vzdaleny, coz muze byt take uzitecne.

Logovani by mohla byt mozna kapitola sama o sobe ... Parkrat jsem to 
pouzival predevsim k ladeni emu. Vetsinou mi stacilo od pruchodu urcitou 
adresou zacit logovat na kazdem radku obsah regPC. Ve slozitejsich 
pripadech jsem obcas logoval komplet disassemblovany vystup i s obsahem 
registru. Takovehle logy ovsem behem chvilky docela slusne rostou 
(zvlaste kdyz jsou v txt podobe) a k jejich analyze si pak vetsinou 
musim napsat treba nejake perl scripty. Takovy masivni log je ale asi uz 
dost specificky a mozna bude lepsi, kdyz si jej proste kazdy dle svych 
konkretnich potreb nakompiluje rovnou do programu.

ad datove breakpointy:
Mam predstavu, ze breakpointy budou vyhodnocovany za kazdou vykonanou 
instrukci, coz znamena, ze budou reagovat na to co se stalo - nikoliv na 
to, co se prave chysta stat. Pokud bych chtel podle datoveho breakpointu 
najit napr. misto, ktere mi prepisuje zasobnik, nebo misto ktere mi 
zapisuje do portu 0xCE nejakou hodnotu, tak se bud budu muset spokojit s 
vykonanim breakpointu bezprostredne po teto udalosti. To se navic trochu 
komplikuje tim, ze kdyz napr. v danou chvili jeste prijde interrupt, tak 
tim nasledujicim radkem bude az prvni instrukce v prerusovaci rutine, 
coz bude trochu zavadejici.

K tomu, aby se tohle nejak hezky vyresilo by jsme asi museli do 
umulatoru zabudovat pred kazdou instrukci nejakou predikci toho co se 
stane a nebo implementovat nejaky rollback, ktery nas vrati o par gdg 
taktu zpet pokud byla identifikovana nase udalost.

Na druhou stranu tento problem se asi tyka jen akce "STOP". Pokud by 
jsme tu udalost chteli jen zalogovat, tak k tomu mame v danou chvili 
vsechny potrebne informace a do logu by jsme umeli zapsat adresu na 
ktere se vyskytovala nami hledana instrukce.

Rozhodne s tim vsim bude jeste hodne veselo :)

Michal

Dne 1.10.2015 v 9:43 Hynek Sladky napsal(a):
> To bude pekne slozity stroj :-)
>
> Pro ruzne analyzy by se jako akce mohlo hodit logovani do souboru bez
> zastaveni programu.
>
> Take by se mohl hodit datovy breakpoint: pri zapisu nebo cteni konkretni
> adresy nebo portu, pripadne pokud by slo rozlisit, zda to je 8- nebo
> 16-bitovy pristup H/L bytu (v pripade pameti).
>
> Pro ladeni aplikaci by se mohl hodit breakpoint na pristup do urcene
> oblasti pameti nebo naopak mimo urcenou oblast pameti (preteceni/podteceni).
>
> Hynek Sladky
>
>
> Dne 1.10.2015 9:08, Michal Hucik - ORDOZ napsal(a):
>> Adresa:
>>
>> Zakladni breakpoint je urceny konkretni adresou na ktere dojde k zastaveni.
>>
>> Akce:
>>
>> Nejbeznejsi akci breakpointu by melo byt STOP. Dalsimi moznostmi je
>> vykonani nejake sequence operaci: prirazeni obsahu registru, variables,
>> pameti, ci nastaveni periferii.
>>
>>
> _______________________________________________
> SharpMZ mailing list
> SharpMZ na mail.ordoz.com
> http://mail.ordoz.com/mailman/listinfo/sharpmz
>