⟦e365b10d7⟧

TextFile


1. Indledning.

     I det følgende beskrives udviklingen af en assembler i forbindelse
med Metanics Z80.000 datamat med et EOS-baseret styresystem. Planen er,
at assembleren skal fungere som bindeled mellem oversættere og linker, og
den skal således hovedsageligt udføre følgende opgaver:

     1) Adressetildeling og beregning.
     2) Konveretere symboler til maskinkode.
     3) Danne en udskrift af programtekst og maskinkode.

Med sin placering mellem oversættere og linker har assembleren to hoved-
grænseflader som vist på fig. 1. I de følgende to afsnit 1.1 og 1.2 gives
en kort beskrivelse af, hvad der forventes at befinde sig på den anden
side af hver af de to grænseflader. I afsnit 2 gennemgås overvejelserne
bag denne opdeling, og opdellingen af assembleren i passager berøres.
     I afsnit 3 beskrives klartekstrepræsentationen af symbolsk maskinsprog
for målmaskinerne (Z80.000 og Z8.000), fordi denne danner grundlaget for
mellemkoden, der beskrives i afsnit 4.


1.1. Oversættere.

     Oversætterne er en slags preprocessorer for assembleren. Da der til
styresystemet skal udvikles oversættere til en række sprog, og disse alle
skal producere ikke-fortolket kode, er det (økonomisk) hensigtsmæssigt, at
de kan have et fælles sluttrin, som foretager de sidste omformninger fra
mellemformer til ren maskinkode. Med valget af symbolsk maskinsprog som
fælles mellemform, svarer disse omformninger netop til assembelerens funktion.
Hertil kommer dog en række modifikationer:

    1) Det er uøkonomisk, at en oversætter danner symbolsk maskinsprog
       i en tekstlig form, som derpå må underkastes leksikalsk analyse.
    2) Det er uøkonomisk, at foretage syntaktisk og semantisk analyse af
       information, som kan garanteres korrekt af et andet program.

Af disse årsager er det valgt, at lade informationen, der udveksles mellem
oversættere og assembler være en kompakt indkodet intern repræsentation af
symbolsk maskkinsprog, som dette forekommer i klartekst.
     Det er imidlertid et klart ønske, at det skal være muligt at skrive
programmer i symbolsk maskinsprog, og en af oversætterne må derfor kunne
omsætte fra dette til den benyttede mellemkode. For at alle dele af sådanne
programmer kan analyseres og garanteres korrekte, må en oversætter fra
symbolsk maskinsprog foretage eventuelle makroekspansioner og betingelses-
reduktioner, og oversætteren må derfor omfatte en symboltabel. Det skal
asembleren også, og de to vil derfor i nogen grad udføre det samme arbejde.
     Assembleren skal kunne generere en udskrift, uanset hvilken oversætter
dens input stammer fra. Udskrifterne forventes hovedsageligt at blive brugt
ved oversættelse af programmer skrevet i symbolsk maskkinsprog. Dette skyldes
at oversættere til højniveausprog gerne selv danner en udskrift, som er
baseret på højniveaukildeteksten. Mellemkoden udformes derfor, så det er
muligt at rekonstruere symbolsk maskinsprog ud fra denne.




1.2. Linkeren.

     Linkeren sammenkæder objektmoduler med hinanden og med biblioteks-
moduler og danner derved andre objektmoduler, som med en loader kan ind-
læses i datamaten og udføres. Objektmodulerne, der består af sektioner,
har adgang til at referere til symboler, der er erklæret i andre moduler
ellerr i biblioteker. Ethvert objektmodul skal derfor ledsages af en
fortegnels over, hvilke symboler det im- og exporterer. Ligeledes skal
det angives, hvilke adresser, der skal ændres i modulet, hvis dette
flyttes i det virtuelle adresserum. Et objektmodul består da af følgende:


     1) En identifikation og en indholdsfortegnelse.
     2) En fortegnelse over importerede symboler og disses typer.
     3) En fortegnelse over exporterede symboler og disses typer.
     4) En række navngivne sektioner, som alle er nævnt i indholds-
        fortegnelsen, og hvis indbyrdes referencer er resolveret.
     5) En fortegnelse over hvilke adresser, der skal ændres, hvis
        en sektion flyttes i det virtuelle adresserum.

2. Assemblerens opbygning.

     Assembleren skal tildele symbolerne adresser og gøre det muligt at
referere til symboler, som endnu ikke er defineret. For at kunne gøre dette
uden "backpatching", udformes assembleren med to passager. Den første
passage benyttes til at scanne mellemkodefilen for at finde alle symbol-
erklæringer og opbygge en tabel over disse. Under anden passage indsættes
de fundne adresser og udskriften samt objektkoden dannes.
     Langt hovedparten af arbejdet foregår således i anden passage, og
første passage er nærmest udartet. Dette er en konsekvens af, at al
analyse (leksikalsk, syntaktisk og semantisk) er udskilt og placeret i
oversætterne. Et alternativ ville være, at indkorporere assemblerens
første passage som en del af hver oversætter, men dette vil (bortset fra
vedligeholdelsesproblemer) have den ulempe, symboltabellen skal være
tilgængelig fra begge sider af grænsefladen, hvorved dens implementation
gøres vanskeligt foranderlig. Indbygges hele assembleren i hver oversætter,
undgås dette problem, men vedligeholdelsesproblemerne forbliver. De består
i, at man skal ændre alle de programmer, de fælles moduler indgår i, hvis
disse moduler ændres.
     Prisen for at undgå disse problemer er, at symboltabellen skal skrives
i en fil, hvorfra den igen skal læses. Herved bruges tid og plads, og der
opnås ingen øget fleksibilitet derved, fordi der ikke kan rettes i mellemkoden.
     Vi vælger at skrive symboltabellen i mellemkodefilen, fordi vi derved
kan udvikle assembler og oversættere uafhængigt af hinanden og desuden derved
forventer at opnå mindre programmer og - som nævnt - færre vedligeholdelses-
problemer.


«eof»
DataMuseum.dk

Bogika Butler

⟦e365b10d7⟧ TextFile

Derivation

TextFile
