⟦ed9dfc4e7⟧

TextFile

$#venstre240
$#højre1680
$#indryk120
$#linieafstand10
$#h/f-venstre216
$#h/f-højre1704
$#h/f-linieafstand10
$#hoved-højde60
$#fod-højde40
$#lige-margen0
$#sidenummer1
$#hovedav METANIC Aps.
$#hovedam ^FOBJEKTMODULER^f
$#hovedah Side #
$#hovedbv LGJ
$#hovedbm
$#hovedbh 1985.04.22
$#hovedcv V1.0
$#hovedcm
$#hovedch
$#hoveddm ______________________________________________________________
$#formatter
I det følgende diskuteres hvorvidt et modul bør kunne rumme
flere sektioner pr. segment. Dernæst angives strukturen for
objektmoduler (oplæg til), og endelig angives kommando-
^-^-sprogets udformning.

Først lidt terminologi:

Et segment er i denne forbindelse et adresserum, hvis ind^-hold
relokeres særskilt.

En sektion er en tekststump, som skal placeres i et segment,
og som forefindes tekstuelt samlet. Sektioner hørende til
samme segment relokeres ud fra samme oprindelsespunkt
(eng: origin).

Et modul er en enhed, som lader sig oversætte/assemblere
særskilt. Et module kan (i princippet) omfatte vilkårligt
mange segmenter.

     I symbolsk maskinkode SKAL (jvf. AC) det være muligt at
angive flere (end 1) sektioner hørende til samme segment i
et modul. Om dette også skal være muligt i objektkodesprog^-et,
kommer ud på et med, om det skal være assembler eller linker,
der samler sektionerne segmentvis.
     Hvis linkeren baseres på resumeinformation om objekt^-modulernes
indhold samlet i disses hoveder, kan den nøjes med 1 passage
over teksten. Er resumeinformationen derimod spredt i modulet, må
linkeren gennemføre 2 passager.
     Assembleren vil oplagt blive udformet i to passager, og
kan da på simpel vis opbygge en sektionstabel og således udskrive
den ønskede resumeinformation forrest i objekt-modulerne. Dette
taler for at holde resumeinformationen sam^-let i objektmodulerne
frem for at placere den sammen med den del, som resumeres.
Men assembleren kan lige så godt samle sektioner i segmenter og
udskrive disse som hele enheder, som den kan samle
resumeinformationen og udskrive denne sam^-let, så hvis ingen andre
oversættere med væsentligt ud^-bytte kan udformes til at danne
sektionsopdelte objektmodul^-er, må konklusionen være at objektmoduler
ikke skal sek^-tionsop^-deles.
     Et andet spørgsmål er, hvorvidt relokeringsinformation^-en skal
holdes særskilt eller blandes med det egentlige ^-^-tekstbillede.
Herom kan kort siges, at hvis de blandes, må linkeren fjerne
relokeringsinformationen på et tidspunkt og derpå komprimere
billedet. Holdes de adskilt, kan linkeren nøjes med at foretage
"in situ" opdateringer af billedet, hvor der skal relokeres eller
importeres. Dette har den for^-del, at en kopiering (under
komprimeringen) undgås. Desuden kan man benytte blok-i/o under
ind- og udlæsning. Derfor bør de holdes adskilt.





Objektmoduler.

Her benyttes metasymbolerne  ::=  !  <    >   >+   >*  og  >@.
::= og <  > er som i sædvanlig BNF, medens <  >+ og <  >* betegner
^-^-lister med henholdsvis mindst et element og mindst nul ^-^-elementer af den
angivne type. <  >@ betegner netop et ^-^-element af den an^-givne
type eller den tomme streng. Valg mellem alternativer betegnes med !.

Det følgende er lidt uformelt. Der er ikke taget hensyn til pakning
og "padding".

$#kopier
1 <object file> ::= <object module>+
2 <object module> ::= <om-head><om-image><om-import>
                      <om-export><om-rld>
3 <om-head> ::= <id rec><name><size rec><#segments>
                <segm. descr.>*
4 <id rec> ::= <format><org><sys><date>
5 <format> ::= i32
5 <org> ::= i16
5 <sys> ::= i16
5 <date> ::= i32
4 <name> ::= <symbol>
4 <size rec> ::= <sz-head><sz-image><sz-import><sz-export>
                 <sz-rld>
5 <sz-head> ::= i32
5 <sz-image> ::= i32
5 <sz-import> ::= i32
5 <sz-export> ::= i32
5 <sz-rld> ::= i32
4 <#segments> ::= i32
4 <segm. descr.> ::= <sd-size><nullification>
                     <relocatability>
5 <sd-size> ::= i32
5 <nullification>  ::= bit
5 <relocatability> ::= bit
3 <om-image> ::= <relocation unit>*
4 <relocation unit> ::= i16
3 <om-import> ::= <#imported><esd rec>*
4 <#imported> ::= i32
4 <esd rec> ::= <es-kind><es-item><es-name>
3 <om-export> ::= <#exported><esd rec>*
4 <#exported> ::= i32
5 <es-kind> ::= <es-kind-1><es-kind-2>
6 <es-kind-1> ::= 8 ! 16 ! 32
6 <es-kind-2> ::= import ! absolute ! relocatable
5 <es-item> ::= i32
5 <es-name> ::= <symbol>
3 <om-rld> ::= <relocation indicator>*
4 <relocation indicator> ::= bit
6 <symbol> ::= string

$#formatter

$#ny-side
Kommandosprog.

$#kopier
<command> ::= <option list><file list>
<option list> ::= <map option>@ <target option>@
<map option> ::= /MAP <file name spec>@ <map extent>@
<file name spec> ::= =<file name>
<file name> ::= string
<map extent> ::= /BRIEF ! /FULL
<target option> ::= /OBJ <file name spec>@
                  ! /EXE <file name spec>@
                  ! /NOTARGET
<file list> ::= <file name><file list tail>*
<file list tail> ::= , <file name>

$#formatter
I denne forbindelse er det ligegyldigt, om kommandoen skri^-^-ves på samme
linie som kommandoen, der aktiverer linkeren eller den næste. Det er også
ligegyldigt, hvilke symboler der benyttes som terminaler. I stedet for de
anførte kan man f.eks. vælge at benytte UNIX's(R) "incomprehensible style".

Kort om semantikken:
     Som "default" for alle uddatafilnavne benyttes navnet på første inddatafil.
Angives variantkoden /MAP dannes en "memory map"-udskrift i filen med
det angivne navn. "Default extension" er map. /BRIEF og /FULL angiver
detaillerigdommen i udskriften. "Default" er /BRIEF.
     Angives variantkoden /OBJ dannes en objektfil med det angivne navn.
"Default extension" er obj. Angives /EXE dan^-nes et "loadmodule"
i en fil med det angivne navn. "default extension" er exe. Angives
variantkoden /NOTARGET dannes ingen egentlig uddatafil, men "map"-udskriften
kan dannes afhængigt af variantkoden /MAP.
     Fillisten <file list> angiver navnene på de objekt^-filer, hvis indhold
ønskes sammenkædet.
«eof»
DataMuseum.dk

Bogika Butler

⟦ed9dfc4e7⟧ TextFile

Derivation

TextFile
