ZESZYTY NAUKOWE POLITECHNIKI ŚLĄSKIEJ Seria: INF ORMATYKA z. 7
1984 Nr kol. 809
Krzysztof NAŁĘCKI
Instytut Informatyki Czasu Rzeczywi ste go Politechniki śląskiej
WS POMAGANIE PRODUKCJI O PR O GR AMO WA NI A MI KR OP R O CE S O RÓ W - KO NCEPCJA USOM
S t r e s z c z e n i e . W artykule przedsta wi ono ogólną charakterystykę pro- blemów produkcji oprogramowania, w szczególności dla m i k r o pr o c es o rów oraz wła sności stosowanego oprogramowania narzędziowego. O m ó wiono używanie różnych Językó w programowania i różnych typów mi kr o procesorów. Za p ro po no wan o strukturę systemu wsp om aga jąc eg o pr od uk
cję oprogramowania dla mikroprocesorów. Scharakteryzowano zakres im
plementacji proponowanej koncepcji w postaci USOM - Uniwersalnego Systemu Oprogram ow ani a M ik r o p r o c e s o r ó w l ) .
1. WSTĘP
Przez produkcję oprogramowania rozumieć będziemy wytwarz an ie oprog ra mowania z użyciem odp ow iednich narzędzi. Specyfika mikrop roc es or ów w tym Z8kresle uzewnętrznia się zwykle brakiem odpowiedniego oprogramowania na rzędziowego lub koniecznością stosowania spe cjalizowanych stanowisk ur u chomieniowych o rozbudowanej konfiguracji sprzętowej. Rozbudowa ko n fi gu
racji Jest wym uszone w ł aś c iw ośc ia mi eksploatacy jn ym i oprogramowania n a
rzędziowego. Wygo dny w użyciu edytor tekstu źródłowego wymaga pamięci d y
skowej. Kompilator Języka wy so kie go poziomu może funkcjonować dopiero przy odpowiednio dużym obszarze pBmięci operacyjnej. Administ rac ja modułami oprogramowania użytkowego w trskcie wytwar zan ia wy maga systemu op era c y j
nego ze sprawnym systemem plików. Tworzenie, pr ze chowywanie i wy ko r z y s t a nie bibliotek procedur możliwe Jest przy użyciu pamięci dyskowej.
Użycie stanowiska ur uc ho mie ni ow ego jest konieczne w fazie scalania oprogramowania i sprzętu systemu mikroprocesorowego. Ponadto stanowiska uruchomieniowe wykonywane są z reguły Jako systemy z Jednym użytkownikiem.
Zatem, Jeśli stanowisko ur uchomieniowe używane będzie zarówno do p ro d u k
cji oprogramowania. Jak i do uruchamiania sprzętu, stanie się po t e nc j al nie wąskim gardłem, szczególnie w przypadku wię kszych projektów. Powiela-
^ P r o j e k t USOM - Un iw ers al ny Syst em Opr ogramowania Mi k ro p ro c e so r ów re al i
zowany Jest od 1981 r. w Labo ra tor iu m ODRA 1305 Instytutu Informatyki Czasu Rzeczywis te go Politechniki Śląskiej w ramach problemu wę złowego 06.4.
nie stanowisk uruchomieniowych Jest ekonomicznie zbyt kosztowne. Propon o
wanym rozwlęzaniera Jest wykorzystanie wielod ost ęp ne go systemu kom pu ter o
wego ogólnego przeznaczenia do produkcji oprogramowania mikroprocesorów.
Dodatkowę zaletę takiego rozwięzanla, oprócz zwiększenia liczby równ ocz e
śnie dostępnych stanowisk pracy dla programistów, Jest fakt na ogół do brego wyposażenia dużego systemu komputerowego w narzędzia programowe, u- sprawniejęce pracę pro gramisty i duża różnorodność urzędzeń pe r yf ery j
nych. Ten sposób produkcji oprogramowania nazywać będziemy skrośnym, gdyż komputer, dla którego produkuje się oprogramowanie (komputer docelowy) różni się od komputera, przy użyciu którego to oprogramowanie Jest pro du kowane (komputera macierzystego). Przykładami skrośnych systemów pr od uk
cji oprogramowania mik ro procesorów s ę : UMDS -BS O [i], MicroSlm- DM EE [2], Pa sPort-Intermetrlcs [3] . Do klasy tej należy również USCM {4, 5, 6],
W dalszej części artykułu przedstawiona zostanie charakterystyka pr o
cesu produkcji oprogramowania 1 wynlkaj ęce stęd właści wo śc i opr og r am o wa nia narzędziowego oraz ogólna koncepcja uniwersalnego systemu wspoma gaj ę- cego oprogramowanie mikropr oc eso ró w i jej realizacja w postaci USOM.
2. PRODUKCJA OPROGRA MOW AN IA
Produkcja oprogramowania Jest dzlałalnościę ukierunkowanę na uz'yskanie programu komputerowego, którego eksploatacja umożliwi efektywne rozwięza-
nle pewnego zadania lub klasy za dań (rys. l). Celem analizy Jest przekształcenie sformułowania tre
ści zadania w wymagania dla opro gramowania .
W procesie produkcji opr og ra m o
wania wyr óżnimy następujęce etapy składowe (rys. 2):
- projektowanie wstępne, w którym wy ma gania przekształcane sę w specyfikację zewnętrznę programu lub programów, które należy w y tworzyć 1 zespół war un ków pop ra wności produktu;
- p r o g r a m o w a n i e , w którym tworzy
Rya. i. Mlejece produkcji opr ogr am o
wania w cyklu życia programu
się pr ogramy o zadanych specyf i
kację funkcjonalnę właściwościach;
uruchamianie, majęce na celu w e ryfikację poprawności wy tw o r z o nego programu w aspekcie pos ta wiony ch wymagań;
W spo m ag an ie produkcji op ro gramowania mikroprocesorów.. 9
p y łk o w a
Rys. 2. Procesy składowe produkcji oprogramowania
- dokumentowanie pr odukowanego op ro gramowania konieczne dla Jego ek spl oa
tacji i pielęgnacji.
Istotnę cechę prz ed stawionego schematu Jest Jego potencjalna iteracyj- ność, uwarunkowana pr zybliżeniem cech produktu do wymagań, a wynlkajęca z różnic semantycznych międz y Językami uży wanymi do reprezentacji danych na różnych etapach. Obecnie, proponuje się w związku z tym formalizację Ję zyków używanych do formułowania wymaga ń 1 określania specyfikacji funk
cjonalnej oraz au tomatyzację pr ocesów konwersji w ym ag ań w specyfikację funkcjonalną oraz specyfikacji w tekst programu [7, 8, 9]. Podstawową tru
dność w tym zakresie stanowi fakt, że wymagania, a następnie specyfikacja funkcjonalna określają, CO ma być zrobione. Natomiast program określa, JAK należy postępować, by osiągnąć za dany cel. Ponieważ, poza przypadkami trywialnymi, ten sam efekt można osiągnąć różnymi sposobami (X różnym kosz tem) , pełna au tomatyzacja produkcji oprogramowania Jast niemożliwa 1 nie-
'ncnC kTO U t M C PACC tA
\ H U . popl*cełyll'c
h/ers/e
fie ru o tn y
ARCHtUOH
EDYCJA
Y ehjJ in d ło u y
fćtSiOSA
s m /o T e k t
¡cohpuacja
SA&uawnA
¿ Ą a e d / e
Moch/bp biblloYcep*
'D o k u /ie u - iT ow A m e
p/o p/efM
c/obuntpK ta ,
d o k u m e n ta c ja k o n s tr u k c y jn e *
¡//u c ita m /a n /a
Rys. 3. Przebieg programowania
Wspoma ga n ie produkcji oprogra m ow an ia mikroprocesorów. 11
celowa. W szcz eg ól noś ci ur uch amianie oprogram ow an ia wymaga ob ecności "in
truza" albo "przeciwnika", którego zadaniom Jest wykr yc ie mak symalnie d u żej liczby błędów i ni eś ci sło śc i w reakcjach (wynikach wykonania) p ro g ra mów. R ów ni eż do kum en to wan ie wymag a aktywnej dział aln oś ci człowieka. Bez węt pl enl a natomiast można przyjęć celowość w sp oma ga ni a ws zy st ki ch etapó w produkcji oprogram ow ani a odpo wi edn im i narzęd zia mi programowymi. Pr z y k ł a dami mogę być automatyczna generacja da nych testowych, różnego rodzaju prog ra my redakcyjne dla opracowania posta ci graficznej dokumentacji. N a j bardziej zaa wa nsowana Jest po wszechnie autom at yz acj a fazy programowania.
Rys. 3 przeds ta wia uściśl an ie działa ń (procesów) skła daj ęc yc h się na tę fazę. Danymi z ew nę trz nym i sę specyfikacja funkcjonalna (nazywana również zewnętrznę) 1 opis błędów wykrytych w fazie uruchamiania. Wynikiem Jast p r o gram ki e r owa ny do uruchamiania wraz z dokum ent ac ję k o n s t r u k c y j n ę , wyko- rzyatywanę w uruchamianiu.
Na podstawie sp ec yfi ka cji funkcjonalnej (CO zrobić) projektuje się al goryt my (b a k z r o b i ć ) , strukturę danych i postać programu. Tekst programu uzyskany w efekcie tego procesu na leży umieścić na nośniku maszyno wy m np.
w zbiorze dyskowym. Używa się w tym calu n aj pr os tsz yc h środków te ch n i cz nych (tzw. urzędzenla przygotowania danych) lub korzysta z int erakcyjnoś- ci systemu kom put er ow ego i wp row adz a tekst programu w ramach dialogu.
W tym przypadku można korzystać ze spe cjalnych edyt or ów syntaktyc znl e o- rientowanych na teksty w określ ony m Języku programowania [loJ. Uzyskuje się dzięki temu gw ar ancję syntaktycznej popraw no ści tekstu. Czasem można wy ko rzy st ać fragmenty opr ac owanych wcześniej p ro g ra mów dla skrócenia c z a su tworzenia tekstu na nośniku maszyn ow ym - tekstu źródłowego. W tym celu musi Istnieć s p ra wn y me chanizm ar chi w i za c ji 1 a dm i ni str ac ji modułami ź r ó d łowymi. Przykł ade m mole być wykorzyst an ie opisu str uk tur y zbioru danych, prze tw arz an eg o w kilku programach. Uzys kan y w procesie edycji tekst źród łowy Jest pr zek az yw a n y do kompilacji. Powinien zostać również z a rc h iw i z o
w a n y dla umożl iw ien ia wp ro wad za ni a poprawek. Kompilacja i edycja pow ta rzane aę aż do uzyskania be zbłędnych wyników. Raport kompilacji staje się elem en tem do kumentacji, a uzy ska ny zbiór m o duł ów wy nik o w yc h (kompllat) na
leży uz upełnić w procesie łęczenia o mo du ły biblioteczne, wcześniej op r a
cowane, dla uzy skania kom pletnego programu. Mod uł w yn i ko w y może zostać rów
nież sk ie row an y do biblioteki do w yk or zys tan ia później (po opra cow an iu p o zost ał ych mo du łów produ kow an ego programu lub w innych programach). Biblio
teka w ym ag a odpowi edn ic h m ech ani zm ów obsługi, umo żl iw i aj ę c yc h w p r o w a d z e nie nowych modułów, za stę powanie i/lub usuwanie błędnych będż n i e p r z y d a t nych oraz u d os tę pni ani e po trzebnych w procesie łęczenia.
Biblioteka m od u łó w wyn ik o wy c h łęcznie z a r ch iw um tekstów źródłow yc h 1 do ku mentację modułó w tworzy bazę danych, nad którę re alizuje się pr o d u k cję oprogramowania.
3. ŚRODKI W SP O MA G A NI A OPR OG RA MOW AN IA
Ws po ma g a ni e programowania i ogólniej produkcji op ro gramowania ma na celu obniżenie kosztów procesu, głównie przez skrócenie czasu realizacji oraz podniesienie Jakości produktu (zmniejszenie liczby błędów, lepszę do kumentację). śr odki do tego celu używane - oprogra mow an ie na rzędziowe nazywa się również środowiskiem w sp o ma gaj ęc ym pr ogramowanie (Programmlng Support Envlronment-PSE) [ll} . śr od ow i s ko w sp om ag aję ca programo wan ie o p e
ruje na modułach, tzn. na wy od ręb ni on ych i rozróZnialnych zes tawach in
formacji. Moduł opisan y Jest zbiorem atrybutów. Pr zykładami at ry but ów m o gę być: nazwa, typ, w sk aź ni k wersji, kontrola dostępu. Pewne atr yb u ty u s tala i nadaje im wart oś ć użytkownik, inne pozostaję w a d mi ni st rac ji p ro gramów narzędziowych.
Wyprowad ze nie m modułu bę dziemy nazywać proces transfor ma cji pewnego zbioru modułów przy uZyclu od pow iednich na rzędzi w calu uzyskania modułu (lub modułów) bllZszych wykonaniu. Prz ykładami w y pr ow ad zan ia sę: ko m p il a cja i łęczenle (rys. 3). Moduł, który nie moZe zostać w y p r o wa d zo n y przy uZyclu dostępnych narzędzi nazywać będz ie my modu łe m abstrakcyjnym lub pier wotnym. Moduł taki musi być utworzony przez użytkownika, w prz ec iw i eń stwie do modułów w y p r o w a d z a l n y c h , tworzonych 1 obsłu gi wan ych przez pr o gramy narzędziowa.
Dla modułu w y pr ow adz on eg o istotnym zespołem atry bu tó w Jest opis hi s to rii wy prowadzenia, specyflk uję cy mo duły źródłowe i narzędzia użyte do J e go utworzenia.
Rewizję nazywać będziemy proces transfor mac ji pewnego mo dułu w celu uzyskania zastępnika.
Typowym przykładem rewizji Jest edycja. W wy niku rewizji ot rzy mu jem y nowę we rsję modułu. Rewizję stosować moZna również do mo dułu a b st r ak c y j
nego. Ro zr óZnialność różnych we rs ji zapewnia atrybut nazwany w ska źn ik iem wersji. W najprostszym przypadku może to być npmer wersji, z wi ęks za ny w kolejnych rewizjach. Inna możliwość - rejestracja d a t y rewizji - daty na rodzin m od ułu w ra z z datę na rodzin we rs ji poddawanej rewizji. W tym p r zy padku przestaje ob owięzywać liniowa uporzędk owa nl e zbioru wers ji, co może być korzystne przy tworzeniu wielu wa r i an t ów we r sj i "p r ób n yc h “.
Zn ajomość historii w yp ro wa d ze n i a pewnego mo dułu pozwala na au t om a ty c z ne powtórzenie procesu wyp ro w ad z an i a prz y użyciu zn owe li zo wan ych w er sji modu łó w źródłowych Jak i aktualnych wersji pro gramów n a r z ę d z i o w y c h , poczy- najęc od poziomu modułó w abstrakcyjnych.
Ważne zna czenie praktyczne dla użytkownika może mleć mo żliwość rewer
sji w yp row adzenia lub rewizji. Najpro st szy m rozwlęzsnlem Jest p rz e ch o w y
wania (archiwizacja) wsz ys t ki c h we rsji modułów abst ra kc yjn yc h 1 mo d u ł ó w z nich w yp r owa dz on ych oraz we rs ji stosowanych prog ra mó w narzędziowych. Roz- wlęza ni a to powoduje Je dnak znacznę zajętość pamięci masowej 1 bez sp ra w
nych mec hanizmów admini str ow an ia zbiorami traci sens. Rozwięz an ie wysta r-
Wspo ma g an ia produkcji oprogramowania mikroprocesorów. 13
czajęce to przecho wy wan ie moduł ów a bs t r akc yj ny ch i historii wy p ro w ad z a nia. Zape wni a się w ten sposób możliwość ponownego pr zeprowadzania proce
su wyprowadzania. Porównanie kosztów po wtórzenia wyprowad ze nia (lub pew
nego Jego fragmentu) z kosztem przecho wyw an ia i adm in istrowania wielu w e r sji wy pr ow a d za l ny c h powinno wskazać wy bór właściw eg o wariantu pos tęp ow a
nia.
Ze s t a w środków wsp oma ga ją cyc h programowanie ch arakteryzuję Jego w ł a s ności funkcjonalne. Niektóre z nich omówimy.
A. Poziom Ję zykowy - liczba, poziom i atopień integracji Językó w u ży w a nych do definiowania modułów abstrakcyjnych.
B. Za kr es ko nfi guracji docelowych - zwykle konfiguracja systemu komp ut e
rowego uż ywanego w pr od ukcji opr ogramowania Jest znacznie bardziej roz
budowana niż konfiguracja sprzętu, dla którego oprogramowanie się pro
dukuje. Dotyczy to w szczególn oś ci syst em ów mikroprocesorowych. Dl ate go istotnę cechą oprogramowania wsp oma ga ją ceg o Jest zakres Jego uni
wersa ln ośc i, rozumianej Jako różnorodność ko nf iguracji docelowych oraz otwartość na potencjalne zmiany i rozwój , spowodowane postępem tech
nicznym.
C. Komunikacja z użytkownikiem, przez którą rozumieć będziemy:
- w y m a g a n y stopień znajomoś ci użytkowania bazowego systemu op era cyj ne go i/lub systemu zbiorów;
- mo żliwość w sp ół bie żn eg o wykorz yst yw an ia przez wielu użytkowników;
- moż liwość stosowania urządzeń końcowych różnych typów, w tym konwer- sacyjnych i wsadowych;
- możliwość aut om atyzowania na poziomie Języka zleceń często używanych sekwencji i mec hanizm wartości domniemanych;
- stopień ochro ny przed błędami użytkownika, diagnostyka błędów i moż
liwość informowania o sposobie poprawnego użytkowania.
D. S t op ie ń scalenia i unifikacji narzędzi - programy narzędziowe są zw y k le tworzone w pewnym stopniu niezależnie. Ocz yw ist y fakt w yk o r z y s t y w a nia ich wspól ni e w ramach zespołu tworzącego środowisko wspomagania programow an ia uwypukla wszystkie n ie jed no ro dno śc i i różnice, co w efek
cie może stwarzać użytkownikowi kłopoty w eksploatacji.
E. Precyzja narzędzi - tańsze i efektywniejsze w eks pl oatacji oraz bar
dziej niezawodne są niewielkie specjalizowane programy na rzędziowe w przeciw ie ńst wi e do un iwe rsalnych o wielu funkcjach. Niewielkie ("pre
cyzyjne") p ro gr amy narzędziowe pozwalają na bardziej "drobnoziarnistą"
obr.óbkę modułów, zw iększając el as tyczność dzia ła ń użytkownika. Łatwiej również osiągnąć ot wartość na zmiany. W y ma g a n y Jeet za to rozbudowany me ch anizm a d mi n is tr ow ani a narzędziami, ułatwia ją cy ko mpletowanie aktu alnie wym aganego, np. dla realizacji wyprowad ze nia , zestawu pro gramów narzędziowych.
F. Ws po ma gan ia dokumen to wan ia jako ułatwien ia w tworzeniu na bieżęco ak tualnej d ok um en tac ji projektu, w dogodnej formie graficznej oraz ud o stępnianie selek ty wni e fragmen tó w dokumentacji.
G. Rejest ra cja działa ń dla we ryf i k ac j i postę pu prac, oc en y przyd at noś ci i stopnia wy kor z y st a n ia posz cz eg óln yc h funkcji, typowych błędów, n aj c zę ściej realizowa ny ch sek wencji dział ań itp. Na tej po dstawie można st o pniowo ul epszać w ł aś c iw o ś ci ek s pl oa ta cyj ne pro gr am ów na rzędziowych, elimino wa ć narzędzia "niebezpieczne" i przede w s zy s t ki m kontrolować przebieg prac produkcy jn ych pod w z gl ę de m czasu, koszt ów 1 z aa w a n s o w a nia.
4. CjąZYKI PROGRAMOWANIA
Oęzyk programowania Jest środkiem do tworzenia m o du ł ów abstrakcyjnych.
Z tego powodu korzystne sę języki wy s o ki e go poziomu, po zwalaJęce na s to sowanie odpow ie dni o w y so k ie g o poziomu ab str a k cj i przy d e fin iow an iu funk
cji modułu i Jogo struktur danych. Równ ocz eś ni e wyp ro wa d z en i e modułu w y konyw al neg o w tym prz ypadku Jest na tyle złożone, że pra ktycznie uż yt k o w
nik traci mo żliwość ko ntroli fu nk cjonowania sprzętu w trakcie wy ko nyw ani a modułu. Nie za wsze można się na takie rozwięzsnle zgodzić, w szc ze g ól n oś ci w przypadku sy ste m ów ba zu ję cyc h na mikroprocesorach. Wy nika atęd ko
nieczność używania różnych J ęz yk ów programowania, o różnym poziomie a b strakcji.
Naj ni ższ ym poziomem Jest poziom Języka symb oli cz ne go - asemblera. Z a pewnia on pełnę kontrolę funkcjo no wan ia sprzętu za cenę koni ec zno ści u ży wania wył ęcz nl e op eracji ele me nt a r ny c h i fizycznego poziomu organi zac ji danych. Dla pod wyższania poziomu a bs tra kc ji i przyspie sz eni a na tej d r o dze procesu programow an ia używa się w tym pr zypadku me ch an i z mu makroin- strukcj i.
W systemie ws po ma g a ni a pr ogramowania, zo rie n t ow a n ym na wiele różnych typów mi kro p r oc e so r ó w wy st ęp o w ać muszę kompil ato ry Ję z y k ó w symbolicz ny ch tych m ik r op r o ce s or ó w - asemblery. Of icj al nę definicję Języka s y m b o l ic z n e
go mik ro pro ce so ra ustala zwykle producent, w p ro wa dz aję c na rynek asembler wr a z z pro duk te m - min ima ln y w ar un ek wz bu dze ni a za i nt er es owa ni a za st o s o
waniami. R ó żni ce między Ję zykami sy m bo li cz nym i różnych m ik r o pro ce so rów pr zedstawić można na nast ęp uj ęcy ch 4 poziomach:
a) różnice w ar c hi tek tu rz e mi k ro p ro c e so r ów powoduję różnice w zestawie oper ac ji elementa rn ych - listach rozk az ów tych mikro pro ce so rów ;
b) stosuje się różnięce się w z a je mn ie sposo by zapisu żędania wyko na nip o- peracjl elementarnej - formaty i ns tru kc ji języka sy mbolicznego, róż
nięce się kodami mnemonicznyrai rozkazów, po etacię ko dowania ar g u m e n tów, st osowanymi sep ar atorami i sym bolami o r ga n iza cy jn ymi (np. komen- ' tarz) ;
W sp omagania produkcji op ro gramowania mikroprocesorów.. 15
c) używa się różnych spos ob ów sterowania procesem kompilacji (dyrektywy) oraz struktury modułu kompilowanego;
d) stosuje się różne formaty zapisu treści modułu ładowalnego.
2 wyżej przedst aw ion yc h różnic, technicznie uzasadnione sę Jedynie w y mienione w punkcie a.
Natomiast a l go ry tmy kompilacji, niezależnie od formy Języka sy m bo lic z
nego, sę z wyj ętk ie m różnic pow od owanych różnę postacię dyrektyw, iden
tyczne. Ponadto przyjęcie koncepcji m o duł ów odsuwa sprawę różnic w y m i e nionych w punkcie d do fazy łęczenia modułów.
Zatem można za proponować cz ęściowę unifikację Języków symbolicznych róż
nych mik ro pro ce so rów przez ujedn ol ic eni a formatów instrukcji, zestawu dy
rektyw i atr uktury modułów. Dzięki temu można, w stosunkowo pr osty s po sób, uzupełniać standa rd owy 'szkielet" asemblera o specyficzne dla danego typu mi kro pr oc eso ró w wła śc iw o ś ci zde fi niowane listę rozkazów [12} . A k c e p towany przez tak uzyskany asemblor Język symboliczny będzie się różnił od definicji producenta. Sto su jęc jednak odpowiednio zdefiniowane m a k r o i n strukcje można, przy sprawnym mec hanizmie aakroge ne rac ji asemblera, oaię- gnęć zgodność z Ję z yk iem producenta dla za pewnienia pr zen ośności modułów źródłowych w Języku symbolicznym. W y od rę bn ien ie fazy łęczenia (rys. 3) implikuje kompilację Jedno pr zeb le go wę oraz konieczność stworzenia n ar z ę dzia dla łęczenia modułó w - programu łęczęcego. Oeśli ustali się wspólnę postać zapisu mo du łów skompilowanych, pewien Język pośredni, można opr a
cować un iw ers al ny program łęczęcy. W program ten wbudow yw ana będzie spe
cjalizowane procedura zspisu treści modułu ładowalnego w formacie n a r z u conym przez producenta sprzętu. Ujednoli ce nie formy zapleu modułów sko m
pilowanych pozwala ponadto na opr acowanie uniwersalnego zestawu programów obsługi biblioteki modułów, niezależnego od typu mikroprocesora.
Warto zauważyć, że w wynik u pracy asemblera uzyskuj em y kompozycję dwóch poziomów abstrakcji. W module wy ni kow ym wy st ępu ję kody operacji, zgodnie z listę rozkazów mi kroprocesora i odwołania do przestrzeni adresowej zb io ru modułów tworzęcych program. Odwołania ta maję formę adresów logicznych, a ich al lokacja wykonyw an a Jest w trakcie procesu łęczenia, który nie m o że zmieniać kodów operacji. Oeat to podstawowa funkcja programu łęczęce
go, poza uzupełni en iem grupy modułó w użytkownika o m od uł y biblioteczne w celu utworzenia ko mpletnego programu. Możli wa jest zatem ustalania j edn o
litej formy re prazentacJi w y ra że ń adresowych, niezależnej od typu mi k r o procesora, a zatem i Języka pośredniego. W Języku tym zapisane sę mo duły wynikowe as em bl eró w i mo du ły biblioteczne. Specyf ic zne wł a sn oś ci ok re ś l o
nego typu mik roprocesora (kod rozkazu i format rozkazu, rozmiar pola adr e
sowego) traktuje się Jak stałe, nie podlegajęce konwersji.
Dęzyk wyso kie go poziomu Jest z defi ni cj i niezale żn y od sprzętu. Przaz kompilację należy dostos owa ć tekst modułu źródło we go do właściwości sp r zę tu, na którym ma być wy k o na n y (wyprowadzenie modułu - obniżenie poziomu abstrakcji). By ułatwić realizację taj funkcji w systemie wsp omagania
programowania zor ie nto wa ny m na różne konfiguracje sprzętowe (różne m ik r o procesory) przyjmi emy na stępujęcę koncepcję. Zadaniom kompilatora Języka wy so kie go poziomu będzie wyprowadz en ie mo dułu wyk on y wa l n eg o w pewnym a b
strakcyjnym procesorze danym lietę rozkazów. Implementację tego procesora w postaci fizycznej oslęgnęć można przez:
- konstrukcję procesora dla danej listy rozkazów,
- implementację danej listy rozkazów w postaci mikr op ro gre mó w dla d o s t ę p nego procesora m i k r o p r o g r a m o w a l n e g o ,
- implementację funkcji opisanych danę listę rozkazów w formie zbioru procedur dla konkretnego procesora 1 interpretację treści modułu pod kontrolę od powiedniego programu at erujęcego (interpretera) ,
- kompilację treści modułu na Język fizycznie istnlejęcego procesora.
Pierwsze dwa w a ri a n ty pominiemy, gdyż dotyczę ko nstrukcji sprzętu, a to nie więżę się ze w s pom ag an iem programowania. Technika interpretacji Jest powszechnie stosowana w zastosow an iac h mi k ro pr oc eso ró w (p - kod dla Języka Pascal, interpretery Języka BASIC). Wp rowadza ona Jednak znsczne narzuty czasowe. Ponadto, używanie różnych Język ów pr ogramowania Jest w tym przypadku sztuczne i utrudnione. Natomiast obniżenie poziomu a b st r ak cji modułu przez dodatkowę kompilację, przy istnieniu sprawnego makroa- eemblera, sprowadza się do opracowania zesta wu makroi nst ruk cj i odwzorowu- Jęcych operacje ele mentarne procesora abs tr akc yj ne go w operacje procesora fizycznie latniejęcego. Należy przy tym zauważyć, że pewne operacje pr o cesora abs tra kcy jn ego w dalsz ym cięgu będę musia ły być interpretowane przez procedury wy wo ływ ane w trakcie w y kon yw an ia modułu. Dotyczy to w szczególności operacji na zmiennych o typie ni ee le men ta rn ym w sensie lis
ty rozkazów procesora fizycznego - operacja zmi en nop rz ec ink owa i tzw. fun
kcje standardowe. Ponadto op eracje we j ś ci a/ wy jśc ia i ogólniej wyw ołanie systemu opera cy jn ego również zawsze sę interpretowane. Zat em dla im ple mentacji tego wariantu, oprócz zestawu makroinstru kc ji, opracować należy grupę moduł ów (procedur, funkcji) standard ow ych Języka wy sok ie go poziomu dla określ on eg o mi kroprocesora i systemu operacyjnego.
Oczywiste Jest, że zde fi nio wa ni e funkcji procesora abstrakc yj neg o Jest równoważne opracowaniu pewnego Języka o pośrednim poziomie abstrakcji.
Przyjęcie tej koncepcji pozwala ponadto na w miarę proste imp lem en t o wanie różnych Ję z yk ów programowania. Kompil at ory tych J ę zy kó w maję w s p ó l ny Język wy ni kow y 1 w dużej części wspól ne biblioteki moduł ów st a nd ar do wych. Przykładem takiego rozwlęzania może być system firmy Whites mit hs
5. ST R UK TU RA SYSTEMU
Przedstawione wcześniej rozważania stanowię podstawę do zapropo now an ia str uktury un iwe rsalnego systemu wspom aga ni a pr ogramowania mikroprocesorów, przedstawionej na rys. 4.
W sp om a ga ni e produkcji oprogra mo wa n ie mikroprocesorów. 17
jfiyk frćcMouy
j f t y l c pasredm ' M
jf/ylt paitdnT L
y u l - y u i *U P V ” '>'I‘ r o - p r o c + s o r c > * i
J L . . J 3 i f t y l e ï uysoUfeyo pax.Tornu
.
1 <3[ />?
PKOS M M
¿ą c z ą c y -
Bi b l i o t e k a
p r o y r a m ¿ x t r a r n y
Rys. 4. Struktura uniwersal ne go systemu ws pomagania produkcji o pr o g ra m o
wania mik ro pr oce so ró w
Edytor służy do zapisu treści modułów na nośniku m as zyn ow ym i w p r o w a dzania zmian w tej treści. Dost to ed ytor uniwersalny. Mo d u ły zapisane w Językach wyso ki eg o poziomu aę poddawane kompilacji, przy czym wsz ystkie kompilatory w y ko rzy st uj ę ws p ól n y Język pośredni M dla zapisu wyniku kom
pilacji [6j. Oęzyk ten Jest niezale żn y od typu mi kr oprocesora docelowego.
M o duł y za pisane w języku symbol ic zn ym pewnego mik roprocesora pr ze ksz ta ł
cane sę przez ssembler i zapisane w Języku pośrednim L [5] . Dana w y k o rzystywane w procesie łęczenia moduł ów zapisywane sę w formie niezależnej
od typu mikroprocesora. Tę sonę drogę na zapis w języku L p rz e k sz t ał c a no sę moduły zapisane w języku M przez wyk or zys ta ni e "wyspecjalizowanej"
w e rsj i asemblera mikroprocesora ok reślonego typu. A se m bl ery dla różnych m ik rop ro ce sor ów tworzone sę z tej samej bazy.
M o d u ł y w kodzie L mogę być przechowywane w bibliotekach. Programy ob sługi biblioteki sę niezależne od typu mikroprocesora, natomiast b ibl io teki tworzy się dla każdego typu mikroprocesora. Ponadto tworzyć można specjalizowane biblioteki zwięzane z określonymi zastosowaniami.
Programy łęczęce dla rólnych typów m i kr o pro ce so rów różnię się p r oc e du rami ge neracji programu binarnego, odpowiednimi do st osowanego w systemie mikroproc es oro wy m sposobu zapisu treści programu w pamięci komputera (np.
w pamięci PROM). Programy te, podobnie Jak asemblery, tworzone sę ze wspól
nej bazy przez montaż odpowiedniej procedury wyjściowej. Proponowana struk
tura systemu zapewnia łatwe wprow adz an ie nowych języków pr ogramowania Jak również nowych typów m i kr o pro ce so rów w trakcie rozwoju systemu.
Zaznaczone na rys. 4 programy d ok um ent uj ęc e symbolizuję spe cjalne na
rzędzia programowe właściwe dla o kre śl on ego Języka wys oki eg o poziomu. Pro
gramy te służę do uzyskania pełnej dokum en tac ji modułu. Wykonywać mogę ta
kie czynności, jak:
- tworzenie listy odwołań skrośnych,
- odwzorowanie struktury modułu - przekazywanie sterowania ,z an urz an ie pro
cedur, w y od rę bn ian ie instrukcji złożonych,
- we ry fi kac ję zgod no ści używanych kon strukcji językowych ze standerdowę definicję Języka,
- przetwarzanie wstępn e (preprocesor), np. w celu konwersji instrukcji st ru kturalnych lub o p ty ma li zac ji m as z y n o w o - n i e z a l e ż n e j .
Dokumentacja konstrukcyjna programu powstaje w wyniku złożenia ra po r
tów ws zys tk ic h narzędzi używanych w procesie wyp row ad za nia programu. M e chanizmu tego na rys. 4 nie zaznaczono.
6. IMPLEMENTACJA
Sy stem ws pomagania produkcji op rogramowania mik ro pr o c es o ró w o st r uk t u rze Jak na rys. 4 został wd r oż o n y w La bor atorium OD R A 1305 Instytutu In
formatyki Czasu Rz e cz yw is teg o Pol it echniki ślęskiej w ramach prac bad aw
czych, prowadzonych w latach 1981-1983 na zlecenie problemu węzłowego 06.4.
System Jest z ai mp le men to wa ny dla komputera 0DRA-1305, pracu jęc eg o pod kontrolę systemu op era cyjnego GEORGE-3. Jako Język imp le mentacji wy b r a n o Pascal dla zapewnienia ewentualnej p r ze no śn ośc i systemu na inne k o mp u te ry. Środowi sk o systemu op era cyjnego G E OR GE -3 stwarza istotne ułatwienia we wdr aż an iu 1 eksploatacji systemu wspomag an ia produkcji op rogramowania mikroprocesorów. Moduł y źródłowe 1 m od uły z nich w y pro wa dz one pr ze ch o w y
wane sę w zbiorach PZS. Do edycji używa się edytora systemu. Sy stem pil-
W sp om a ga ni e produkcji o pr ogramowania mikroprocesorów.. 19
ków (PZS) zapewnia ochronę dostępu do danych i archiwizację. Dla rejes
tracji rewizji i wy pr ow a d ze ń można używać n u mer ów ge neracji i kodów Ję z y
kowych zb i or ów PZS. Wła śc i wo ś ci Języka opisu zadań systemu GEORGE-3 umoż- liwiaję przez konstrukcję odp ow iednich ma kr ozl ec eń zminima liz ow ani e udzia
łu użytko wni ka w obsłudze pro gr amó w narzędzi ow ych [l4j .
Sy s te m wspomag an ia o nazwie US OM - Un iw er s al n y S ys tem Oprogramowania M i kr o p roc es or ów obecnie obejmuje narzędzia dla programo wa nia na poziomie Języka sym bo lic zn eg o nestępuj ęc ych typów mi kr op r oc e s or ó w 8-bitowych: 8080, 8085, Z - 80 i 6800 oraz 16-bitowych 8086 i 8088.
W trakcie realizacji Jest kompilator Języka Mod ula-2, wspólny, zgodnie z pr zedstawioną koncepcję, dla wsz ys tk ich typów mikroprocesorów. Zespół opracowanych na rzędzi obejmuje asemblery, pro gra my łęczęce i prog ram y o b sługi bibliotek. Ponadto w skład USOM wchodzę symula tor y mi kro pr oce so ró w 8080, 8085 1 Z - 8 0 , w yk o rzy st yw ane w trakcie ur uc hamiania opr acowanych pro
gramów użytkowych, zi nte growane z nar zędziami oprogramowania. Pozwala to na uruc ham ia ni e na poziomie Języka źródłowego.
Oako Język w y so ki ego poziomu dis USOM wybran o Język Mo d ula -2 Q.5| . Po
zo st ałymi kandydatami były Pascal 1 Ada. Pascal w y ma g ał b y Jednak uz up eł
nień dla, m ięd zy innymi, umożliwienia odrębnej kompilacji modułów. Z ko
lei Ada mus ia ła b y być ograniczona do subiektywnie wy b r ane go podzbioru, za wzglę du na możliw ośc i realizacyjne. Ot wartość systemu umożliwi Je dnak w przys zł ośc i jego rozwój o inne języki wy e o kie go poziomu.
R e al iz at ora mi fragmentów systemu USOM s ę : as em blery - S t an i sł a w PUCKA,
pr ogramy łęczęce - Wi told 3URECZK0, pr ogramy obsłu gi bibliotek - Oerzy SZYMURA,
kompil at or Mo d ul a -2 - W ł ad y s ła w PIETRASZEK, Adam CI ^GWA i Krzysztof GROYECKI.
Kolegom tym serdecznie dziękuję za udział w tworzeniu koncepcji i rea
lizacji USOM.
LITERATURA
[1] CRZ80 - BSO Relocat ing Cross Ass embler M R EF - BSO Croes Reference Program M L IN K - BSO Cross Linkage Editor ML I B - BSO Librarian
0 B 3C N V - BSO Objec t Fila Co n ve r s io n Utility SI Z8 0 - BSO S lm u lat or /O sbu gg er
Boston System Office, 1982.
[2] Cosserat D. : Micro Sim - a naw approach to program d e v e l o p m e n t , Micro
proces so rs and Micr osy st em s vol 2, no 2 1979.
{3] Oense th 0. , Hebert 3. : Int er metrics Cross - C om pi ler remedies "Brute- Force" ap proach to mi c r opr oc es sor software development, Intermetrics Inc, Tec hnical Backgrounder, 1980.
[4] Nałęcki K. , Jur ecz ko W., Pucka St.: Oprac ow ani a skr oś ne go p r ze no śne go op ro gramowania rozwojowego ayat am ów mi kr oprocesorowych. O pr a co w a nie założeń kon at rukcyjnych systemu opr ogramowania i techniki łęcze- nia mo du łów wynikowych. Raport z realizacji zadania 0 1 / 0 4 / 1. 1 pr.
wę zł owy 06.4, Instytut In formatyki Czaau Rze cz yw i st e g o Politechniki Ś l ę s k i e j , Gliwice 1981.
[5] Nałęcki K. , Oureczko V»., Pucka St., Szymura O. : Oprac ow ani e skrośne- go prz enośnego oprogra mo wan ia rozwojowego syst emó w m ik r op r o ce s or o wych z przykładowę im plementację na maszynie cyfrowej O D R A - 1305. Pro
gram łęczęcy m od uły wynikowe. Pr o gr amy obaługi biblioteki mo du łów wy
nikowych. Raport z realizacji zadania 01/ 04/1.2 pr. w ęz ł o wy 06.4.
Instytut In formatyki Czasu Rze cz yw i s te g o Politechniki ślęskiej , G l i wice 1982.
(¥] Nałęcki K. , Cięgwa A., Groy ec ki K. , Jureczko W., Pietra sze k W., Puc
ka St. : Rozwój systemu op ro gra mo wa nie mi kro p ro c e so r ów USOM. Raport z realizacji zadania 01 /04 /1 ,3 pr. wę zł owy 06.4. Instytut Informatyki Czasu Rzec zy wis te go Pol it echniki ślęskiej, Gliwi ce 1983.
Willis R.R. , Aides: Com put er aided design of software systems w Soft
ware En gineering Environments, ed. H. HUENKE Nort h- Ho lla nd 1981.
[ej Handlykken P., Nygaard K. : The DE LT A system de sc rip ti on language: mo
tivation, main concept and experience from use, w So f twa re En g i n e e r ing Environments, ed. H. HUENKE N or th - Holland 1981.
[sj Spier M.J. , Gutz S., War ss er m a n A.I.: The Ergonomics of So ftware En- glnnoring - descri pt io n of the problem space, w Software E ng i ne e ring Environments, ed. H. HUENKE North - Holla nd 1981.
[10] Sperr y Univac 1100 Series Conversa ti on al Time S ha ri ng S y ste m 7940 Rev.
4. Program Control - Language Prescanner COBOL, FORTRAN, Sperr y U n i
vac 1978.
[ill Ch eatham T.E. : Comparing Pro gramming Suport En vir onments ed H. HU E N
KE North - Holland 1981.
[12] Pucka St.: Au to ma t y cz n a ge ne racja komp ila to ró w Języków asemblera, Z e sz yt y Naukowe Po li techniki ślęskiej, seria Informatyka, nr 7, G l i wice 1984.
[13] W HI T ES M I TH S SO F T WA R E CATALOG, Wh ite s m it h s Ltd, 1981.
¡14] Borek S. , Klaczak J. , Korczak S. , Płoski Z. : S y st e m op er ac yj ny Ge- orge-3, WNT, Wars za wa 1981.
[1 5] Wirth N. : Programming in Modula-2, S p r i n g e r - V e r l a g , 1983.
Recenzent: Doc. dr hab. inż. Adam Wo li sz
W p ły nę ło do redakcji: 13.03. 198 4 r.
W sp om a ga ni e pr o du kc ji op ro gramowania m i k r o p r o c e s o r d w . . 21
nOMEESKA I1P0H3B0ACTBA UPOrPAMMHOrO OEECHEMEHHfl MHKPOnPOIJECCOPOB - HflEH yC.CM
P e 3 b u e
B craite npe^ciaajieHa o&naa xapamapactjaea apoCaeM apoH3BOflciBa aporau- jmoro ofiacaie.'iaHJis.,. b ttaciHociH a ju l MHKponpoiiaccopoB» OroaapaBajarcs Taxxe OBoSciBa npHMaHae*toro HHCTpyueHiaaBHOEO npocpaiotHoro odecneqeHM, Odcyxma-
SSOtL HCHOZIB3 O B a H H S paaHHX & 3 H X O B n p o E p a u M a p o B a H a a jyia pa3JIH»tHtaC T H K O B U K — Kp o npopeccopoB.. O x a p a K T epa.3oBasa o & n a c i t B H e n p e K H H npe&aoxeHHOit b sn^e yCGM
— yHHBspoaJiBHOU C H O i e u u n p o E p a M u n p o B a H H a jyui M K K p o n p o u e c c o p o B .
M I CR O PRO CES SO R SOFT WA RE D EVE LO PM ENT A ID AN IDEA OF USOM
S u m m a r y
In this paper general cha ra ct eri st ic s of a software development pro cess, In pa r t ic u la r y for the m i c r o p r o c e s s o r s , and features of applicable software tools have been stated. Different pr ogramming languages ap pl ica tion for different m i cr o pr oce ss or s types has been discussed. St ru cture of software dev elopment aid system for mi c ro pr oc ess or s has been proposed. At the end, impl em en tat io n of suggested ideas in the form of USOM - un i ve r sal system for mi c ro pr oc ess or s software making has been presented.
