ZESZYTY NAUKOWE POLITECHNIKI ŚLĄSKIEJ 1993
Seria: IN F O R M A T Y K A z. 22 N r kol. 1195
D ariusz Z O N E N B E R G
In s ty tu t Inform atyki Teoretycznej i Stosowanej Polskiej A kadem ii N auk
E M U L A T O R U K Ł A D O W Y — O B S E R W A C J A D A N Y C H D O A N A L I Z Y Z A C H O W A Ń
S Y S T E M Ó W C Z A S U R Z E C Z Y W I S T E G O
S treszczenie. W opracow aniu przedstaw iono m etody urucham iania op ro g ram o w an ia system ów m ikroprocesorow ych pod kątem s tru k tu r danych rezydujących w pam ięci operacyjnej. Z ostały przedstaw ione przeprow adzane za pom ocą e m u la to ra układow ego m e to d y detekcji zm ian w pam ięci, pow stałych n a skutek d ziała n ia p ro gram u. Ja k o konkluzja został zaproponowany przykładow y, wzorowany n a języku Pascal, język opisu procesu śledzenia i prezentacji danych system u m ikroproceso
rowego, urucham ianego z a pom ocą em u lato ra układowego.
IN-CIRCUIT EM ULATOR — DATA OBSERVATION FOR BEHAVIORAL ANALYSIS OF REAL TIM E SYSTEMS
Sum m ary. T h e a rtic le presents m icroprocessor system software debugging te chniques ta k in g into account d a ta stru ctu res residing in o perating memory. P re se n te d are m eth o d s of detectin g of d a ta m odifications in o p erating m em ory d u rin g p ro g ram execution th a t can be perform ed using an IC E (In-C ircuit E m u la to r).
T h e conclusion of th e p a p e r is an exam ple P«sea/-like language for describing th e tra c in g and p rese n tatio n of th e d a ta of th e m icroprocessor system debugged w ith an IC E.
EM ULATEUR M ATERIEL — OBSERVATION DES DONNEES PO U R L ’ANALYSE DES COMPORTEM ENTS DE ¡SYSTEMES TEM PS REEL
R ésum é. Nous présentons les m éthodes de m e ttre au p o int un logiciel conçu p o u r les systèm es m icroprocesseurs, com pte te n u des stru c tu re s d e données résidentes en m ém oire interne. Les m éthodes de détection de ch angem ents de m ém oire, faits p a r les p rogram m es sont discutées. D ans la su ite u n langage de ty p e P ascal est proposé p o u r la description d u processus d ’observation e t p rése n ta tio n des données dans u n systèm e m icroprocesseur é ta n t mis en m a rc h e à l ’aid e de l ’em u lateu r m atériel.
1. W p r o w a d z e n i e
J e d n ą z głównych dziedzin zastosow ania m ikroprocesorów je st k o n stru k cja sterow ników , używ anych zarówno w przem yśle, ja k i przedm iotach codziennego u ż y tk u . Jako oprogram ow anie tego ty p u urządzeń używ a się często m ałych w ielozadaniow ych system ów czasu rzeczyw istego. P ozw alają one n a szybkie tworzenie oprogram ow ania sterow nika p ra cującego w czasie rzeczyw istym , łatw ą pielęgnację uprzednio zdekom ponow anego n a wiele z a d ań oprogram ow ania oraz możliwość prostego oszacowania czasów reakcji sterow nika n a zm iany w otoczeniu. N iedogodnością w konstruow aniu oprogram ow ania te j klasy (nie
koniecznie oparteg o n a ją d rz e wielozadaniow ym ) je śt konieczność stosow ania złożonych te ch n ik u ru ch a m ian ia w czasie rzeczyw istym , kiedy to typow e program y urucham iające lu b sy m u lato ry procesorów n ie ,są w sta n ie sp ro stać wymogom program isty. S y tu a c ja ta pow oduje konieczność tw orzenia złożonych narzędzi uruchom ieniow ych, um ożliw iających z jednej stro n y efektyw ne śledzenie realizacji oprogram ow ania czasu rzeczyw istego, a z drugiej w stę p n ą obróbkę śledzonych zdarzeń oraz ich ergonom iczną p rezentację. Je d n y m z podstaw ow ych obszarów d la w spom nianych działań je st obserw acja i p re z e n ta c ja danych.
S pośród w spółczesnych środków uruch am ian ia oprogram ow ania czasu rzeczyw istego do najbardziej efektyw nych należą em ulatory układow e m ikroprocesorów , p ełniące funk
cję zarówno debuggerów, ja k i analizatorów m agistrali. O pisy ich możliwości funkcjonal
nych m o żn a znaleźć w pozycjach [1], [2], [3], [4] oraz [5].
O becnie gdy oprogram ow anie czasu rzeczywistego zw ykle je st o p a rte n a system ach czasu rzeczyw istego oraz często pisane je st w językach wyższego poziom u, ja k Ada, M odula-S, C lub języki specjalizowane, coraz większej wagi n ab iera obserw acja złożo
nych s tr u k tu r danych tego oprogram ow ania. P rzykładow e, rozw inięte rozw iązania tego
E m u la to r układow y — obserw acja danych. 35
problem u d la debuggera system u M S-D O S n ap o ty k a się w o sta tn ic h w ersjach debuggerów zarów no firm y M icrosoft [6], ja k i innych producentów o program ow ania narzędziowego.
W p rzy p ad k u em ulatorów układowych możliwość obserw acji o toczenia logicznego m i
kroprocesora je s t rozw iązyw ana jako gotowy zestaw zleceń w yśw ietlających sta n zaso
bów [2] lub ja k o zestaw m akroinstrukcji, um ożliw iających tw orzenie k rótkich program ów w yśw ietlających inform ację w żądanym form acie w edług bieżącego sta n u m ikroprocesora.
To drugie rozw iązanie napotykam y w pro d u k tach firm y In te l ([1], [3]) i n a nim był rów
nież wzorowany język em ulatora E T D S /2 -P G , k tó ry będzie u ż y ty w poniższym tekście do ilu stracji przykładów [5].
W celu w yłącznej wizualizacji danych p rzy d a tn e są rów nież em u lato ry pam ięci, po
zw alające n a dostęp tylko do pam ięci operacyjnej procesora, ale ze w zględu n a o g ra n icz o n y zakres ich stosow ania nie będ ą one w poniższym tekście analizow ane.
2. O p rogram ow an ie czasu r z e c z y w iste g o
D la większości procesorów prawdziwe je st założenie, że znając sta n zasobów, do k tó ry ch procesor m a dostęp, m ożna w sposób determ inistyczny określić jego zachow a
nie w kolejnych i przyszłych przedziałach czasowych. Z asobam i są:
• pam ięć kodu program u procesora;
.• pam ięć danych program u;
• reje stry procesora;
• łącze m aszyny cyfrowej z jej otoczeniem (porty, u rząd zen ia zew nętrzne itp .).
N iezależnie od operacji wykonywanych przez procesor, zawsze m ogą zm ienić się dane n a łączu z o toczenia i zawsze m ożna wyznaczyć skończony okres, w k tó ry m są one u sta lone. W ta k im p rzypadku należy założyć, że prawidłowo przygotow any kod oprogram o
w ania zaw iera w sobie określoną, determ inistyczną reakcję n a tego ty p u zdarzenie. Z atem przew idyw alność zachowań procesora w stosunku do danych z o toczenia zaw iera się, w istocie, w popraw ności kodu program u. O pierając się n a ta k ich przesłankach, m ożna sfor
m ułow ać kilka poniższych założeń:
1. S tan procesora, realizującego dane oprogram ow anie, określa zbiór w szystkich przy
szłych determ inistycznych zachowań, jednoznacznie w yznaczonych przez kod, dane i rejestry procesora.
2. S tan procesora realizującego dan e oprogram ow anie będzie o d tą d nazyw any s ta nem oprogram ow ania, zgodnie z p u n k te m w idzenia p rogram isty, że projektow ane i urucham iane je s t oprogram ow anie, a sam procesor je s t co p raw d a nieodzowny, ale niezależny od program isty.
3. Zgodnie z powyższym i p u n k ta m i s ta n oprogram ow ania je s t jednoznacznie określony przez kod program u, jego d an e i rejestry .procesora.
Poniższe opracow anie sk u p ia się n a m ikroprocesorach, d la któ ry ch używ ane są em u
la to ry układow e w celu uruchom ienia oprogram ow ania w w arunkach pracy w realnym otoczeniu i rzeczyw istych uzależnieniach czasowych. S ą to z reguły procesory o stosun
kowo prostej architekturze, zgodnej z m odelem p rocesora zaproponow anym przez von N eu m a n a (np. rodziny 8048, 8051, 80S0, 80(x)S6, 80(x)96, 6502, 6800, 6S0x0 i wiele innych), zatem powyższe definicje dotyczą również tej klasy procesorów .
W określeniu sta n u system u przetw arzającego d an e ja k o oprogram ow ania sterującego dan y m kontrolerem w ystarczające są następujące zasoby:
• pam ięć zaw ierająca oprogram ow anie;
• d an e w pam ięci operacyjnej;
• zaw artość rejestrów procesora (w tym licznika p rogram u).
Z aw artość pam ięci program u je st z reguły s ta ła i znana. P ro g ra m ista urucham iający oprogram ow anie je s t z reguły zainteresow any tym , w ja k i sposób je s t wykonywany jego p ro g ra m i inform ację o ty m uzyskuje n a p odstaw ie zm ian zachodzących w danych (pam ięć o p era cy jn a i rejestry).
A nalizując pracę system u operacyjnego p ro g ra m ista przekonuje się, że większość czasu sy stem spędza n a oczekiwaniu n a określone zdarzenia. C zęść czasu system u je st zużyw ana n a operacje zw iązane z o bsługą zegara czasu rzeczyw istego, a w czasie przetw arzania i p rze sy łan ia danych sterow anie często przechodzi do ją d r a sy stem u . Jego s tru k tu ra może być nie znana, jeśli w ykorzystyw any je s t jakiś system kom ercjalny. Pow oduje to, że często m iejsce, w którym znajduje się realizowany przez procesor kod, niewiele mówi o stanie całego oprogram ow ania. Z kolei śledzenie poszczególnych cykli realizacji kodu- zaw iera z b y t wiele nieistotnych dla p rogram isty inform acji, u tru d n ia jąc y ch tylko rozeznanie stanu oprogram ow ania.
W jednoprocesorow ych system ach operacyjnych (a ta k i tu analizujem y) każdy proces p o sia d a w łasny zestaw rejestrów , przechowyw any z reguły w pam ięci operacyjnej, jeśli d any proces nie je st aktywny. Z akładając, iż:
E m u lato r układow y — obserw acja danych. 37 1. oprogram ow anie używ a rejestrów tylko do p rze tw arzan ia danych, a wyniki przetw a
rzania zawsze przechowywane s ą w pam ięci,
2. procesor posiada tylko jeden pro sty zestaw rejestrów , więc jeśli w środowisku sy
stem u operacyjnego utw orzono kilka procesów, to w szystkie ich dane, łącznie z zaw artością rejestrów rezydują w pam ięci operacyjnej (co istotnie m a m iejsce dla większości procesorów i system ów ),
możemy w ysunąć wniosek, że śledząc zm iany zachodzące w danych ulokowanych w pa
mięci operacyjnej p rogram ista m oże w yciągnąć najw ażniejsze wnioski dotyczące sposobu p rzetw arzania inform acji przez oprogram ow anie. Isto tn ie — dośw iadczenia z system am i operacyjnym i dla procesorów popularnych w Polsce rodzin S0S0/85/ZS0 i 8086 oraz an a
liza procesorów rodzin 6800, 6S000, 6502 sk ła n ia do przyjęcia powyższego wniosku, cho
ciaż d la ich wersji z pam ięcią n o tatn ik o w ą w ew nątrż procesora m ogą następow ać opóźnie
n ia pom iędzy zm ianą danej w pam ięci, a rzeczyw istym d ostępem do pam ięci n a zew nątrz procesora. Nie je st on n ato m ia st praw dziw y d la w ielu m ikrokom puterów jednoukłado- wych — m a ją one często p roste możliwości, ale rozbudow aną stru k tu rę rejestrów , co czasem pow oduje, że pam ięć operacy jn a n a zew n ątrz procesora jest po prostu zbędna.
W stru k tu rac h znanych system ów operacyjnych czasu rzeczywistego m ożna wyróżnić kilka klas danych, które są z reguły przechow yw ane w pam ięci. Ich szczegółowa realizacja zależ}' od konkretnego system u operacyjnego, z o s ta n ą więc one podane tylko ogólnie, aby dać pogląd n a charakter obiektów w pam ięci operacyjnej procesora. Przyjm ijm y zatem następujący ich podział:
1. D eskryptory procesów oraz dane organizacyjne procesów (zawartość rejestrów , stan procesów, sta tu s kom unikacji z ją d re m system u).
2. Dane lokalne procesów — sta ty c zn e i d ynam iczne (stos).
3. Bufory kom unikatów, za pom ocą k tó ry ch n astęp u je w ym iana inform acji pom iędzy procesam i — zarządza nimi sy stem operacyjny.
4. Semafory zapew niające synchronizację poszczególnych procesów.
5. Kolejki procesów, oczekujących n a określone zdarzenie, i komunikątów.
6. D ane ew entualych p rocedur kom unikacyjnych (np. konsoli, dysków, sieci) — w pew nych system ach (np. wzorowanych n a ją d r z e sy stem u U N IX) nie zw iązane z żadnym procesem , a isto tn e d la sta n u oprogram ow ania.
W szystkie powyższe dane są zw ykle ulokow ane w pam ięci operacyjnej m ikroprocesora, a ich szczegółowa realizacja zależy od system u operacyjnego. D la m ałych systemów op era
cyjnych czasu rzeczyw istego n ie w szystkie elem enty m uszą być zaim plem entow ane.
3. N a r z ę d z i a a n a l i z y i d o s t ę p u d o d a n y c h
P osiadając narzędzie w p o sta c i em u la to ra układow ego lub em ulatora pam ięci ope
racyjnej pro g ram ista, w y k o rzy stu jący je w celach uruchom ieniow ych, może w określony sposób śledzić zm iany zachodzące w danych procesora. N asuw ają się do w ykorzystania następujące ogólne m e to d y śledzenia dostępu do danych:
1. Sprzętow a d etek cja poszczególnych cykli m agistrali procesora z a pom ocą em u la to ra układowego. A naliza cykli zap isu p o d k ą te m dostępu do pam ięci w interesujących użytkow nika obszarach.
/ 2. D eklaracja przez u żytkow nika pam ięci em ulowanej oraz sprzętow a detekcja zapisu
do interesujących obszarów pam ięci.
3. D etekcja rozkazów przydzielających i zw alniających pam ięć danych dynam icznych (stos) n a p o trze b y p ro g ra m u , um ożliw iająca śledzenie lokalnych danych dy n am i
cznych. D etekcja d o stęp u do ta k wyliczonego obszaru danych dynam icznych m oże być realizow ana m e to d ą 1 lub 2.
Przj'jm ijm y, uniezależniając się o d k onkretnej realizacji sprzętow ej, że s ta rt detekcji następuje w em ulatorze po w yw ołaniu p rocedury o następ u jący n nagłówku:
procedurę DetectDataWrite(Reiation : string);
(* Gdzie parametr Relation zawiera łańcuch określający za pomocą umownej zmiennej $ADDRESS, jaki obszar adresowy podlega detekcji zapisu, np.:
1) '$ADDRESS >= 0 AND $ADDRESS <= $FFF’ - przedział od 0 do FFF(hex)
2) ’ ($ADDRESS >= 0 AND $ADDRESS <= $3FF) OR $ADDRESS > SFE000' - przedział od 0 do 3FF(hex) lub adresy wieksze od FE000(hex)
*)
E m u la to r układow y — obserw acja danych. 39 W konkretnej realizacji em u lato ra, przykładow o R T D S /2 -P C , powyższe relacje b ęd ą m ia ły odpow iednio n a s tę p u ją c ą postać:
1) 1C wrm irg 0:0 0:FFF any
2) 1C wrm irg 0:0 0:3FF any 2C wrm at> F000:E000 any
D otychczas opisano sposoby spraw dzania, czy dane system u nie uległy zm ianie. K o
lejnym w ażnym zadaniem je s t dostęp do nich od strony em ulatora i ich w izualizacja.
G łów nym problem em d o stęp u do danych je st konieczność zachowania tr y b u pracy oprogram ow ania w czasie rzeczyw istym . W iąże się to z aktualnością danych; podczas p o b ie ra n ia danych otoczenie urucham ianego p ro to ty p u m oże się zm ienić, a dostęp do danych od stro n y e m u la to ra pow inien zapew nić odczyt jej nowej w artości przed kolejną jej zm ianą. M ożna pokazać, że p raw dopodobna je s t sytuacja, gdy dane zm ieniają się w pew nych sy tu acjach ta k szybko, że em u lato r m usi mieć w yłączność w dostępie do nich, aby wychwycić zm iany. Z drugiej stro n y w yłączność w dostępie m oże w strzym yw ać p racę em ulowanego system u.
D ru g im 'p ro b le m em m oże być zb y t du ża częstość zm ian w danych, pow odująca nie
m ożność n ad ą że n ia z w izualizacją przez oprogram ow anie em ulatora. Spowoduje to prze
p ełnienie buforów p am iętają cy c h kolejne zm iany lub u tra tę inform acji o części zm ian.
K olejne znane m e to d y d o stęp u do danych emulowanego proto ty p u są następujące:
a ) B R A K D O S T Ę P U W C Z A S I E R Z E C Z Y W I S T Y M - D ostęp poprzez kanał kom unikacyjny e m u la to ra układowego. M etoda ta angażuje emulowany procesor — istn ieje w ięc niebezpieczeństw o, że otoczenie procesora zmieni się w czasie d ostępu do danych. K onieczne je s t zam rożenie pracy emulowanego p ro to ty p u , a iiie zawsze je s t możliwe zam rożenie jego otoczenia oraz niektórych scalonych kontrolerów karty procesora. Traci się w te n sposób w arunki pracy w czasie rzeczyw istym , ale dla niektórych prac je s t to rozw iązanie zadowalające. Użycie tej m etody nie stw arza problem ów w kw estii n ad ą ż a n ia z w izualizacją danych, gdyż p ra c a oprogram ow ania p ro to ty p u je s t w strzy m an a.
b ) D O S T Ę P D O P Ł A T U P A M I Ę C I — D ostęp do danych poprzez pam ięć em ulo
w aną dw ubram ow ą. W czasie odczytu zm ienionych danych em ulator układow y lub pam ięci w ym aga n a k ró tk i okres wyłączności dostępu (forsowany sygnał W A IT lub szybka pam ięć z p rze p lo tem czasowym ). P roblem em przy użyciu tej m eto d y m oże być k w estia ich w izualizacji (czy op ro g ram o w an icem u lato ra nadąży) oraz kw estia
ich ak tualności (czy śledzony obszar danych nie zm ieni się pow tórnie). P ró b a za
m ra ż a n ia pam ięci n a czas jej odczytu i w izualizacji m oże jed n ak spowodow ać u tr a tę w arunków pracy w czasie rzeczyw istym .
c) D O S T Ę P D O K O L E J K I Z M O D Y F I K O W A N Y C H D A N Y C H — Zapis m o dyfikow anych danych do bufora w prost z m agistrali, w cyklach zapisu do p a m ięci. R ozw iązanie to w ym aga odpow iednio dużej pojem ności pam ięci u k ła d u , k tó ry będzie d an e odczytyw ał i kolejkował. Rozw iązanie to grozi u tr a t ą ciągłości inform a
cji o zm ian ach danych, gdy oprogram ow anie em u lato ra nie n adąży z opróżnianiem b ufora odczy tan y ch w artości lub gdy oprogram ow anie em u lato ra nie n ad ą ży z ich w izualizacją, n a to m ia st nie grozi u tr a tą warunków pracy w czasie rzeczyw istym .
N iezależnie od konkretnej sprzętow o-program ow ej realizacji dostępu do danych em ulo
wanego p ro to ty p u załóżm y, że m am y zdefiniow aną procedurę d ostępu do danych o n a stę p u ją cy m nagłówku:
function GetMem (Address : integer) : Byte;
pozw alającą po w ykryciu zm iany danych n a odczyt nowych danych z kolejnych bajtów pam ięci o p eracy jn ej. Założono, że problem u tra ty warunków pracy w czasie rzeczyw istym je s t rozw iązany n a poziom ie realizacji poszczególnych procedur lub przez o p era to ra , p rz y gotow ującego eksperym ent. W celu uogólnienia m etody odczytu m ożna założyć, że dla ja k najm niejszej ingerencji w pracę p ro to ty p u funkcja GetMem o d czytuje tylko zm ienione w artości, n a to m ia st w artości nie zm ienione są odczytyw ane w podręcznej pam ięci bufo
rowej, k tó ra zaw iera interesujący nas obszar. Został on przepisany przed rozpoczęciem śledzenia dan y ch w czasie rzeczyw istym do bufora p ro ce d u rą o następ u jący m nagłówku:
procedurę Buffer (BAddress, EAddress : integer);
gdzie parametry BAddress i EAddress wskazują kolejno na początek i koniec buforowa
nego obszaru.
4. S p o s ó b o p i s u ś l e d z e n i a d a n y c h
Posługując się zadeklarow anjm ii, w irtualnym i funkcjam i m ożna zaproponow ać p rzy kładow y język a u to m aty zu ją cy funkcje śledzenia sta n u urucham ianego oprogram ow ania w środow isku danego system u operacyjnego czasu rzeczywistego. O gólna za sa d a polega
E m u la to r układow y — obserw acja danych. 41 n a rozszerzeniu konstrukcji napotkanej ju ż w niektórych program ach urucham iających ( debuggerach) — tzw .. W atchP oint (n a przykład debugger C odeView, debuggery opro
gram o w an ia B o rlan d a lub R T D S /2 - P C ). Zakładając, że je st d o stę p n a ta b lic a adresów i nazw sym bolicznych urucham ianego oprogram ow ania, a za te m nazw y u ż y te poniżej b ęd ą zgodne z nazw am i użytym i w kodzie źródłow ym urucham ianego oprogram ow ania, m ożna zaproponow ać podstaw ow e m o d u ły języka deklaracji śladow ania danych. A by uprościć jego czytelność, podstaw ow a sk ła d n ia będzie zgodna z językiem Pascal, zdefiniowanym ja k w pozycji [4], n ato m ia st elem enty zorientowane n a problem zo stan ą opisane poniżej.
Załóżm y, że d la celów śladow ania zm ian utw orzym y kilka m odułów definiujących ko
lejno sta le d la śladow ania, dane do śledzenia i dane do w yśw ietlania. Załóżm y również, że p o uruchom ieniu zadeklarow anych m odułów śledzenie zostanie zainicjow ane, a następnie p ro g ra m w dan y m języku będzie kolejno oczekiwał n a zm ianę danych i w yśw ietlał, ocze
kiw ał — w yśw ietlał aż do czasu, gdy użytkownik przerw ie jego pracę. W te d y definicja poszczególnych m odułów m oże mifeć poniższą postać.
1. M oduł definicji (D E F — E N D D E F ).
Moduł ten zaczyna się od słowa kluczowego DEF i kończy słowem kluczowym ENDDEF.
Pow inien on zaw ierać deklarację pam ięci, w której rezy d u ją dane urucham ianego oprogram ow ania, o postaci
MEMORY = (<adres-poczatkovry>, <adres-koncowy>)
przykładow o
MEMORY = ($200, $1FFF)
co d eklaruje adresy fizyczne używanego obszaru lub
MEMORY = (_Data, _EData)
definiujące obszar wg symboli używanych przez kod źródłow y lub kom pilator u ru cham ianego oprogram ow ania. D eklaracja ta m oże służyć do deklaracji sprzętowego buforow ania danych funkcją B u f f e r . N astępnym elem entem opisyw anego m odułu p ow inna być dek laracja s tru k tu r danych, użytych w oprogram ow aniu. Przykładow o:
type QUEUE = record (* Kolejka *) Start : integer; (* Adres początku kolejki *) End : integer; (* Adres końca kolejki *) end;
type QUEUE_ITEM = record (* Element kolejki *) Previous : integer; (* Adres poprzedniego el. *) Next : integer; (* Adres następnego e l . *) Buffer : integer; (* Adres bufora danych *) end
N ależy zauważyć, że w powyższych przy k ład ach założono, że d a n a zaw ierająca ad
res m a ta k ą sa m ą długość, ja k d an a zaw ierająca liczbę całkow itą. Założenie to nie zaw sze je st praw dziwe i w tedy należałoby utw orzyć now e ty p y danych łu b wyko
rzy sta ć znane w P ascalu ty p y wskaźnikowe. T u taj je d n a k , d la uproszczenia zapisu, założenie to je st do przyjęcia.
O sta tn im elem entem m o d u łu deklaracji p ow inna być d e k la ra c ja sam ych śledzonych danych. Przykładowo:
var FreeMessages : QUEUE; (* Kolejki komunikatów *) Messages : QUEUE;
(* Pula komunikatów *) Message : array [0..100] of QUEUE.ITEM;
CurrProcess : integer (* Bieżący proces *)
W ykorzystanie funkcji Buffer m ogłoby być realizow ane n a p odstaw ie powyższych deklaracji danych, k tó re podlegają obserw acji. W ybór sposobu użycia tej funkcji zależałby oczywiście od konkretnej im plem entacji języka, n a to m ia st powyżej została w prow adzona jaw n a deklaracja buforow anej pam ięci, aby uw ypuklić te n problem . 2. D efinicja śledzonydi danych (DATA — EN DD A TA ). M oże o n a m ieć n astęp u jącą
p rzykładow ą postać:
E m u lato r układow y — obserw acja danych. 43
DATA
Message[0].Previous
ENDDATA
3. Definicja w yśw ietlanych danych oraz sposobu ich w yśw ietlenia (D ISP — END- D ISP).
P rzy realizacji tego m o d u łu załóżm y, że d la p o trze b ję zy k a Pascal, n a który potem dany język opisu śledzonych danych będzie tłum aczony, zrealizowano procedurę o n astępującym nagłówku:
procedure WaitAccess; (* Oczekiwanie na zmiany śledzonych danych
* )
oraz że w deklarowanym języku istnieje standardowa procedura ADDR(), dostarcza
jąca wartość adresu danej. Należy założyć również istnienie standardowej procedury FINISHQ, przerywającej pracę programu śledzenia danych.
Przykładowa deklaracja modułu może mieć następującą postać:
DISP
tmp’ : integer;
if (Message[0].Previous = 0) then begin
if (FreeMessages.Start = ADDR(Message[0]) ) then begin
write('Komunikat w kolejce WOLNYCH');
writeln(', proces = CurrProcess);
end else
if (Messages.Start = ADDR(Message[0]) ) then begin
write( 'Komunikat w kolejce ZAJ/ETYCH’);
writeln(’, proces = CurrProcess);
end else
begin
write(’Komunikat w /żadnej kolejce');
writeln(’, proces = CurrProcess);
FINISHO;
end end else
begin
tmp := ADDR(Message[0]);
repeat
tmp := tmp.Previous until tmp.Previous = 0;
if (FreeMessages.Start = ADDR(tmp) ) then begin
write(’Komunikat w kolejce WOLNYCH’);
writeln(’, proces = ’, CurrProcess);
end else
if (Messages.Start = ADDR(tmp) ) then begin
write('Komunikat w kolejce ZAJ/ETYCH’);
writeln(’, proces = ’, CurrProcess);
FINISHO;
end else
begin
write('Komunikat w /żadnej kolejce’);
writeln(’, proces = ’, CurrProcess);
end end
ENDDISP
E m ulator układow y — obserw acja dany cli. 45 A nalizując pow yższą p rzykładow ą definicję ję zy k a dostrzegam y, że dla pełnej realizacji jego funkcji konieczna je s t im p lem e n ta cja kilku podstaw owych cech w oprogram ow aniu
em ulatora. S ą to kolejno:
1. Możliwość tw orzenia program ów lub m akroinstrukcji składających się z wielu zleceń em ulatora. Powinno być m ożliwe przechow yw anie ich treści w plikach oraz param e- tryzow anie ich w yw ołań w celu tw orzenia proceduy. Ogólnie biorąc pow inno być m ożliwe w ydzielenie języka zleceń danego em ulatora.
2. Możliwość deklaracji zm iennych lokalnych języka zleceń em ulatora.
3. Istn ien ie w dan y m języku zleceń em u lato ra stru k tu raln y ch instrukcji warunkowej i p ętli. M inim alna w ersja n ie stru k tu ra ln a w inna zawierać co najm niej instrukcję w arunku, in stru k c ję skoku i możliwość deklaracji etykiety.
4. Możliwość detekcji d ostępu do danych w czasie rzeczywistym , co je st z reguły fu n k cją w budow aną w większość współczesnych konstrukcji emulatorów.
5. Możliwość o d cz y tu danych bez u tra ty try b u pracy w czasie rzeczywistym. Pow yższa cecha em u lato ra z reguły w y m ag a realizacji określonych modułów sprzętow ych. Ja k o cecha k o n stru k cy jn a je s t is to tn a tylko w pew nych sytuacjach i nie zawsze posiada sw ą sprzętow ą realizację. P roblem y sprzętow e i program ow e związane z jej realizacją zo stały ju ż opisane w rozdziale 3.
5. P r z y k ł a d : A n a l i z a k o l e j k i k o m u n i k a t ó w
Załóżmy, że m am y n astęp u jący problem . W naszym oprogram ow aniu używam y dwóch kolejek kom unikatów . W jednej przechow yw ane są wolne bufory (FreeMessages), w d ru giej inform acje, np. dan e z pom iarów (M essages). Stw ierdzono, że n a skutek błędnego d ziałania oprogram ow ania gubione są bufory kom unikatów . O rganizacja kolejek kom uni
katów je s t taka, że s tr u k tu r a kolejki wskazuje n a pierw szy i o statn i elem ent, n ato m ia st elem ent kolejki w skazuje n a poprzedni i n astępny w kolejce. Jeśli element jest o sta tn i lub pierwszy, to odpow iedni wskaźnik (ten k tó ry nie m a n a co wskazywać) je st równy 0.
Aby odnaleźć m iejsce odpow iedzialne za te n błąd, wybierzemy dowolny bufor ko
m unikatu, np. o num erze ”0” i spróbujem y prześledzić jego los. Użyte zo stan ą do tego przykładow e definicje m odułów proponow anego języka. Zestawione m oduły b ęd ą m iały poniższą, przykładow ą postać:
DEF
MEMORY = ($200, $1FFF)
type QUEUE = record (* Kolejka *) Start : integer; (* Adres początku kolejki *) End : integer; (* Adres końca kolejki *) end;
type QUEUE_ITEM = record (* Element kolejki *) Previous : integer; (* Adres poprzedniego el. *) Next : integer; (* Adres następnego el. *) Buffer : integer; (* Adres bufora danych *) end;
var FreeMessages : QUEUE; (* Kolejki komunikatów *) Messages : QUEUE;
(* Pula komunikatów *) Message : array [0..100] of QUEUE.ITEM;
CurrProcess : integer; (* Bieżący proces *)
ENDDEF
DATA
Message[0].Previous
ENDDATA
DISP
tmp : integer;
if (Message[0].Previous = 0) then begin
E m u la to r układow y — obserw acja d a n y c h .. 47 if (FreeMessages.Start = ADDR(Message[0]) ) then
begin
write('Komunikat w kolejce WOLNYCH');
writeln(’, proces = CurrProcess);
end else
if (Messages.Start = ADDR(Message[0]) ) then begin
write('Komunikat w kolejce ZAJĘTYCH’);
writeln(’, proces = CurrProcess);
end else
begin
write (’Komunikat w żadnej kolejce’);
writeln(’, proces = ’ , CurrProcess);
FINISHO;
end end else
begin
tmp := ADDR(Message[0]) ; repeat
tmp ;= tmp.Previous until tmp.Previous = 0;
if (FreeMessages.Start = ADDR(tmp) ) then begin
write('Komunikat w kolejce WOLNYCH’);
writeln(’, proces = CurrProcess);
end else
if (Messages.Start = ADDR(tmp) ) then begin
write('Komunikat w kolejce ZAJĘTYCH’);
writeln(’, proces = CurrProcess);
end else
begin
write('Komunikat w żadnej kolejce');
writelnC’, proces = ', CurrProceśs);
FINISHO;
end end
ENDDISP
P ro g ram wynikowy w języku Pascal, w ygenerowany n a p o d sta w ie tablicy adresów oraz pow yższy te k st p rogram u, powinien m ieć n a s tę p u ją c ą postać:
Program TraceData;
const (* Moduł DEF *)
FreeMessage = ; (* Wartości nie podane sa znane z tablicy symboli programu - sa to adresy danych uruchamianego prog
ramu
*) Messages = ; Message = ; CurrProcess = ;
Start = 0; (* Pola rekordów - odległość od po
czątku *)
End = 4 ; (* Dlugosc adresu - zalozone 4 bajty *) Previous = 0;
Next = 4;
MessageO = Message + 0 * 12; (* Pozycja 0 w tablicy *)
var (* Dane robocze *)
Finish, tmp : integer;
function GetInt(Addr : integer) : integer;
(* Procedura pobiera z zadanego adresu dana 32-bitowa, która
* jest adresem innej danej lub liczba całkowita.
*
* Zakłada sie organizacje danych jak INTELa.
*)
begin
Getlnt := GetMem(Addr) + GetMem(Addr+l)*256 + GetMem(Addr+2)*256*256+
GetMem(Addr+3)*256*256*256 end;
begin
Buffer($200, $1FFF); (* zlecenie MEMORY *)
(* Moduł DATA *)
DetectData('$ADDRESS = MessageO + Previous');
PutCPU; (* Start emulowanego prototypu *)
(* Moduł DISR *)
Finish = 0;
while (Finish = 0) do begin
WaitAccess;
if (Getlnt(MessageO+Previous) = 0) then begin
if (Getlnt(FreeMessages+Start) = MessageO) then begin
write(’Komunikat w kolejce WOLNYCH’);
writełn(', proces = ’, Getlnt(CurrProcess) ) ; end
else
E m u la to r układow y — obserw acja d a n y c h .. . 4 9
if (GetInt(Kessages+Start) = HessageO) then begin
vrite(’Konunikat w kolejce ZAJĘTYCH’);
sriteln(’, proces = Getlnt(CurrProcess));
end else
begin
write(’Konunikat w żadnej kolejce’);
•srritelnC’» proces = ’, Getlnt(CnrrProcess));
Finish = 1;
end end else
begin
tap := HessageO;
repeat
tap := Getlnt(tnp+Previons) until Getlnt(tnp+Previous) = 0;
if (Getlnt(Free.Messages+Start) = tap) then begin
vrite(’Konunikat v kolejce WOLNYCH’) ;
writeln(’, proces = ’, Getlnt(CurxProcess)) ; end
else
if (GetInt(Kessages+Start) = tap) then begin
srite(’Konunikat w kolejce ZAJĘTYCH’);
vritelnC’, proces = ’, Getlnt(CurrProcess)) ; end
else begin
vrite(’Koannikat w żadnej kolejce’);
sriteln(’, proces = ’, Getlnt(CurrProcess));
Finish = 1;
end end
E m u la to r układow y — obserw acja danych. 51
end
e n d .
D la konkretnego em u lato ra (tu taj R T D S /2 -P C ) po o d cz y ta n iu tablicy sym boli, plik realizujący powyższy algorytm (w ram ach konstrukcyjnych możliwości em ulatora) będzie m ia ł n a s tęp u jącą postać.
*
* Moduł DEF
*
XN End = 4 XN Next = 4
XN MessageO = Message
XN MessageO = MessageO + 0*12
*
* Buforowanie w RTDS2-PC jest automatyczne, ale nie
* dostosowane do optymalizacji dostępu do danych.
*
*
* Moduł DATA
*
2C wrm AT= MessageO any BR C2 A D
*
* Moduł DISP
* : DISP
G
:petla_G
*
* Opisywany emulator nie posiada modułow sprzetowo-
* programowych, pozwalających na dostęp do danych w sposob
* inny niz przez kanał komunikacyjny emulatora.
*
;if $G0 .goto petla_G
*
* Dla uproszczenia zapisu algorytmu zakłada sie dostęp
* automatyczny do slow 32-bitowych słowem kluczowym ’dword'
* oraz dane 32-bitowe identyczne z adresem.
*
•if (dword MessageO) .goto IF1
•if ¡(dword FreeMessages == MessageO) .goto IF01
df CurrProcess Komunikat w kolejce WOLNYCH, proces = V/,d
•goto ENDIF :IF01
•if ¡(dword Messages == MessageO) .goto IF02
df CurrProcess Komunikat w kolejce ZAJĘTYCH , proces = \'/.d .goto ENDIF
: IF02
df CurrProcess Komunikat w żadnej kolejce, proces = \‘/,d
■goto FINISH : IF1
XN tmp = MessageO :REPEAT
XN tmpl = tmp
XN tmpl = tmpl + Previous XN tmp = dword tmpl
¡UNTIL
XN tmpl = tmp
XN tmpl = tmpl + Previous XN tmpl = dword tmpl
•if ¡tmpl .goto REPEAT
•if ¡(dword FreeMessages == MessageO) .goto IF11
df CurrProcess Komunikat w kolejce WOLNYCH, proces = \‘/,d
■goto ENDIF .:IF11
E m u lato r układowy — obserw acja danych. 53
.if !(dword Messages == MessageO) .goto IF12
df CurrProcess Komunikat w kolejce ZAJĘTYCH , proces = \‘/.d .goto ENDIF
: IF12
df CurrProcess Komunikat w żadnej kolejce, proces = \'/,d .goto FINISH
:ENDIF
•goto DISP
¡FINISH
6. W n i o s k i
Użycie ogólnej, publikacyjnej wersji języka Pascal i jej au to m aty czn a translacja na specjalizowany, skonstruow any d la innych p o trze b , języ k je s t pożądana; zapis tego algo
ry tm u od razu w języku em ulatora, zorientow anym n a ergonom iczność pracy z konsoli, je st skomplikowany.
A naliza powyższego p rzy k ła d u nasuw a wniosek, że śledzenie danych oprogram o wania je s t silnie zależne od kom pilatora, w k tó ry m oprogram ow anie ‘ o zostało napisane. Do
tyczy to zarówno sposobu generacji adresów , rozm iaru danych, ja k i notacji ich nazw.
Idealnym rozw iązaniem je s t użytkow anie w łasnych kom pilatorów , np. IN T E L oferuje em ulatory swych procesorów w raz z system em operacyjnym i kom pilatoram i. Ogólnie biorąc, śledzenie s tru k tu r danych generowanych przez k o m pilator języka program ow ania wym aga zasad ich organizacji n a poziom ie fizycznym i kodu źródłowego.
Niezależnie od przyjętego założenia o dostępie do danych bez w strzym yw ania pracy emulowanego pro to ty p u , rozw iązania zapew niające p ostulow aną ciągłość pracy w czasie rzeczyw istym są rzadko spotykane. W ybierając określony ty p em ulatora dla im plem en
tacji n a nim proponowanego języ k a opisu, śledzenia i wizualizacji danych, należałoby zrezygnować z ciągłej pracy w czasie rzeczyw istym albo z powodu braku odpowiednich m odułów sprzętow ych, albo ze względu n a zagrożenie u tr a ty danych.
P rzedstaw iona powyżej propozycja określonego użytkow ania em ulatorów układo
wych do u rucham iania system ów czasu rzeczyw istego je s t, ja k ju ż powiedziano, logi
cznym przedłużeniem znanej w wielu debuggerach obserw acji danych deklarowanych jako W atchP oint (p u n k t obserw acji). Istn ie ją również procesory np. S03S6 i 80486, m a
ją ce ju ż tę możliwość w budow aną w ich a rc h itek tu rę . Sprzętow o-program ow a jej re a lizacja przy użyciu e m u la to ra układow ego lub em u lato ra pam ięci pozw ala u rucham iać oprogram ow anie w w arunkach czasu rzeczyw istego, jed n ak złożoność danych sk ła n ia do definicji określonego języ k a, k tó ry pozw oliłby decydow ać o reakcji n a określone stany obserwowanego system u. N ap o ty k a n e w spółcześnie konstrukcje em ulatorów z reguły nie pozw alają n a p e łn ą im p lem en tację tego języka b ez u tra ty try b u pracy w czasie rze
czyw istym em ulow anego p ro to ty p u , chociaż k o m ponenty tych konstrukcji w p ełn i to um ożliwiają. N ależy oczekiwać, że dalszy rozwój oprogram ow ania sterowników m ikro
procesorow ych w językach wyższego poziom u spow oduje rozwój kolejnych konfiguracji sprzętow o-program ow ych em ulatorów , przy stający ch w większym stopniu do postulow a
nych w pow yższym opracow aniu wymogów.
L IT E R A T U R A
[1] Intel — "IC E -8 6 A /IC E -8 8 A M IC R O S Y S T E M IN -C IR C U IT EM U LA TO R O P E R A T IN G IN S T R U C T IO N F O R ISIS-II U SE R S ” , Intel 1982.
[2] M ic ro te c — ’’M IC E -II U sers G uide” , M icrotec 19S6.
[3] Intel — "IC E -1 9 6 P C U ser G uide” , Intel 1987.
[4] D ariusz Z onenberg — ’’E m u la to r układow y m ikroprocesorów jako narzędzie u rucho
mieniowe w ujęciu p ro g ram isty czn y m .” , W ydaw nictw o S IG M A -N O T , m ies. IN F O RM A TY K A n r 2, W arszaw a 1992.
[5] M E R A -E lzab — ’’R T D S /2 -P C . D o k u m en tac ja użytkow a.” , M E R A -E lzab Zabrze 1989.
[6] M icrosoft C orp. — ’’M icrosoft CodeV iew — W indow O riented D ebugger for the M S-D O S O p eratin g S y stem ” , M icrosoft 19S7.
[7] Per B rinch H ansen — ’’P od staw y system ów operacyjnych” , W ydawnictwa Naukow o-Techniczne, W arszaw a 1979.
R ecenzent: Prof. dr. hab. inż. Andrzej Grzywak
W płynęło do R edakcji 28 lis to p a d a 1991 r.
E m u lato r układow y — obserw acja danych. 55
A bstract.
T h e artic le p rese n ted real tim e m icroprocessor system software as changes in d a ta s tru c tu re s p erform ed d uring alghoritm execution. N ext, th e possibilities were described of d a ta tra c in g in a real tim e environm ent th a t can b e achieved using know n featu res of con tem p o rary IC E s. A fter a p relim inary p roblem presentation, an exam ple d escription language was p rese n ted for d a ta tra c in g and presen tatio n of m icroprocessor system s de
bugged using an IC E . T h e language was P cscef-like because of PascaVs read ab ility an d p opularity. A sim ple debugging task was discussed to illu strate th e language’s ap p lica
tion. T h e exam ple language was used to describe th e debugging task and afterw ards it was tra n sla te d in to a real R T D S /2 -P C IC E language. Conclusions points to close conne
ctions betw een th e ta sk s of softw are debugging an d program m ing language com pilers as a directive for IC E softw are developm ent. IC E design features necessary for th e p rese n ted applicatio n a re a w ere also indicated.
