|
DataMuseum.dkPresents historical artifacts from the history of: Bogika Butler |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about Bogika Butler Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 14208 (0x3780)
Types: TextFile
Names: »INTRO2.BAK«
└─⟦9dfa17898⟧ Bits:30009789/_.ft.Ibm2.50007352.imd Mogens Pelles Zilog 80,000 / EOS projekt
└─⟦this⟧ »INTRO2.BAK«
└─⟦bfec2519f⟧ Bits:30009789/_.ft.Ibm2.50007346.imd Mogens Pelles Zilog 80,000 / EOS projekt
└─⟦this⟧ »INTRO2.BAK«
Indledning.
Denne tekst redegører for et programmelsystem, som udvikles
til Metanics EOS-baserede operativsystem for en Z80.000 baseret
datamat. Systemet omfatter de funktioner, som almindeligvis udføres
af assembler, linker og loader, og er også på traditionel vis opdelt
i disse programmer. Desuden indgår nytteprogrammer til vedligeholdelse
af linkerens objektkode-biblioteker.
Det er et overordnet ønske at fremstille en række oversættere til
systemet, og assembler-funktionen udformes således, at den kan indgå som
bagende i disse oversættere og på denne måde genbruges. Da andre
assemblere for Z80.000 allerede er kommercielt tilgængelige, er dette
dens primære funktion. De omtalte oversættere skal også konstrueres
(eller modificeres), men betragtes som tilgrænsende systemer. Desuden
ønskes på længere sigt en "stand alone" assembler, som kan danne maskinkode
fra symbolsk maskinsprog.
Linkeren er udskilt fra assembleren af den sædvanlige årsag - at
oversættelse af delprogrammer muliggøres. Linkerens funktion er at samle
de objektmoduler, som assembleren danner, til større enheder, samt at
resolvere deres indbyrdes referencer og referencer til moduler, som henligger
i bibliotek. Herunder skal modulernes binding til virtuelle adresser kunne
ændres (relokering/flytning). Linkeren skal kunne acceptere sine egne
uddata som inddata (objektmoduler), men skal muligvis desuden kunne danne
særlige loadmoduler som inddata til loaderen.
Loader-funktionen - at indlæse loadmoduler til indre lager, foretage
den forrnødne lageradministration og igangsætte udførelse af programmet
i loadmodulet - udføres i EOS-baserede systemer af objektkataloger. Disse
forefindes i det konkrete tilfælde som færdige enheder fra NCR's hånd,
men netop grænsefladerne til loadmodulerne skal muligvis modificeres. Denne
opgaves løsning må afvente, at materialet fra NCR leveres.
Systemets komponenter og grænsefladerne mellem dem er skitseret i
fig. 1.
Fig. 1.
A-koden er en indkodet intern repræsentation af symbolsk maskinsprog, og
er dermed baseret på klartekstversionen af det symbolske maskinsprog. Derfor
indledes i afsnit 1 med at præcisere klartekstrepræsentationen af det symbolske
maskinsprog, hvorpå A-koden defineres i afsnit 2.
I afsnit 3 redegøres for udskriftens format.
I afsnit 4 redegøres for objektkodens format.
I afsnit 5 redegøres for de nødvendige informationer for at danne
objektkode og udskrift, samt disses organisering i tabeller.
I afsnit 6 redegøres for programstruktur.
Afklaringen af de fremadrettede referencer udføres ved 2 passager
fremfor ved "backpatching", og der skal derfor defineres en mellemkode
(A-kode), som sidste passage læser, ligesom de fornødne tabelinformationer
skal klarlægges.
"Stand-alone" assembleren (som oversætter fra symbolskk maskinsprog)
skal desuden kunne danne en udskrift, som indeholder såvel den symbolske
maskinkode som den numeriske. Det er ligeledes ønskeligt, at oversættere,
som oversætter fra højniveausprog, udover deres sædvanlige udskrifter
kan danne en udskrift i symbolsk maskinsprog til brug ved afprøvning
af oversætterne.
Da assembleren skal kunne indgå som sluttrin efter en oversættelse
fra højniveau-sprog, indrettes den til at læse sine inddata i en særligt
indkodet intern repræsentation (A-kode). På denne måde undgås, at oversætterne
skal danne uddata i form af klartekst, som derpå møjsommeligt skal underkastes
leksikalsk analyse. Da oversættere kan detektere såvel syntaktiske som
semantiske fejl i deres inddata og tillige kan danne korrekt uddata, som
er inddata til assembleren, undlades analyse af alle forhold, som kan
garanteres korrekte af det foregående program. Således forsvinder leksikalsk,
syntaktisk og semantisk analyse fra assembleren, som følgelig kun foretager
adresseberegning og tildeling, samt generering af objektkode og symbolsk
programudskrift. En assembler af denne form, kan naturligvis ikke håndtere
symbolsk maskinsprog i klartekst. Omsætningen fra klartekst til A-kode
betragtes som oversættelse (fra lavniveausprog), og til denne opgave
fremstilles en oversætter, som på linie med højniveausprogsoversætterne
benytter sig af assemblersluttrinnet.
1. Klartekst symbolsk maskinsprog.
Klartekstrepræsentationen af det symbolske maskinsprog (kaldet
klarteksten) er baseret på Zilogs assemblerssprog for Z8.000 cpuen og på de
instruktionskoder, som allerede er oplyst i dokumentationen af Z80.000.
Enkelte aspekter er dog stadig ikke afklarede, og denne afklaring vil ikke
finde sted før den endelige dokumentation foreligger. Det drejer sig om
følgende:
1) Notationen for adresseringsmåden BX med offset.
2) Notationen for registermasker.
3) Regler for hvilke flag, der kan manipuleres.
4) Præcis angivelse af, hvilke styreregistre, der findes, og hvorledes
de betegnes.
Klarteksten kan skrives i næsten frit format. Det vil sige, at de leksikalske
elementer kan starte i en vilkårlig position på linien, men bemærk, at
linieskift er et leksikalsk element. De leksikalske elementer kan skrives
med store og små bogstaver blandet, men kun brugerdefinerede symboler vil
blive gengivet på denne måde i udskriften.
Alle brugerdefinerede symboler tilskrives en type. Denne kan være en af
følgende:
1) tal
2) kompakt adresse
3) lineær adresse
4) segmenteret adresse
5) tegnstreng
Af tabel 1 fremgår, hvilke operationer, der kan udføres på operander af de
enkelte typer, og af fortegnelserne over instruktioner (tabel 3) og
direktiver (tabel 4) fremgår disses krav til parametrenes typer. Operatorernes
indbyrdes præcedens ved evaluering fremgår af tabel 2.
Specielle er operatorerne "+" og "-", der kan operere på samtlige 5
typer (dog kun tegnstrenge af længden netop een), og direktivet "DB", der
tillader paramtre enten af typen tal eller tegnstreng (vilkårlig længde)
i enhver position. Bortset fra disse er parametres og operanders typer
entydigt bestemt ved instruktionen, direktivet eller operatoren.
Operator 1. Operand 2. Operand Resultat
------------------------------------------------------------------------------
+ (dyadisk) tal tal tal
segmenteret tal segmenteret 1)
kompakt tal kompakt 1)
lineær tal lineær 1)
- (dyadisk) tal tal tal
segmenteret tal segmenteret
kompakt tal kompakt
lineær tal lineær
* tal tal tal
/ tal tal tal
MOD tal tal tal
AND tal tal tal
OR tal tal tal
XOR tal tal tal
SHL tal tal tal
SHR tal tal tal
+ (monadisk) tal - tal
- (monadisk) tal - tal
SGM segmenteret - tal
kompakt - tal
lineær - tal
OFS segmenteret - tal
kompakt - tal
lineær - tal
CPT tal - kompakt
LIN tal - lineær
SGMOFS tal tal segmenteret
Noter:
1) Da dyadisk + er kommutativ, kan der (selvfølgelig) byttes om på 1. og 2.
operand.
------------------------------------------------------------------------------
Tabel 1. Operatorer og operandtypers sammenhæng.
------------------------------------------------------------------------------
Operatorerne med højeste præcedensniveau (3) evalueres først.
1) +, -, OR, XOR (* +, - er dyadiske operatorer *)
2) *, /, MOD, AND, SHL, SHR
3) +, -, SGM, OFS, CPT, LIN, NOT (* +, - er monadiske operatorer *)
------------------------------------------------------------------------------
Tabel 2. Operatorpræcedens.
Klarteksten er udformet ud fra bl.a. det synspunkt, at definition af
brugersymboler kun bør finde sted i etiketfeltet. Således udelades
direktiverne byte, word og long, der hver definerer en række symboler angivet
som operander. Princippet gennemføres imidlertid ikke konsekvent, idet
import-direktiverne medtages i deres traditionelle form: Med symbbolliste i
operandfeltet.
I det følgende redegøres for klartekstens syntaktiske regler. Disse
afspejler ikke begrænsningerne i typerne anvendelser, som er beskrevet
ovenfor.
<program> ::= <statement> <statement list>
<statement list> ::= NIL ! <statement> <statement list>
<statement> ::= <label field> <operation field> <comment field> <CR> <LF>
<comment field> ::= NIL ! ; <comment>
<comment> ::= NIL ! <ASCII sequence>
<label field> ::= NIL ! <identifier> :
<operation field> ::= NIL ! <operation> <operand field>
<operation> ::= . <directive> ! <instruction> ! <macro call>
<directive> ::=
<instruction> ::=
<macro call> ::= <identifier>
<operand field> ::= NIL ! <operand> <operand list>
<operand list> ::= NIL ! , <operand> <operand list>
<operand> ::= <expression> !
<mask> !
<condition code> !
<flags> !
<interrupts>
<control register>
# <expression> !
<register> !
@ <register> !
<expression> ( <register> ) !
<register> ( # <expression> ) !
<register> ( <register> ) !
(* Z80.000 BX *)
<expression> ::= <subexpression> <opexp> !
"<<" <expression> ">>" <subexpression> !
<opexp> ::= NIL ! <dyadic opr> <subexpression> <opexp>
<subexpression> ::= <monadic opr> <subexpression> !
( <expression> ) !
<identifier> !
<literal> !
<string constant>
<dyadic opr> ::= + ! - ! * ! / ! MOD ! AND ! OR ! XOR ! SHL ! SHR
<monadic opr> ::= + ! - ! SGM ! OFS ! CPT ! LIN ! NOT
<mask> ::=
<interrupts> ::= VI ! NVI
<condition code> ::= NIL !
F ! T
Z ! NZ !
C ! NC !
PL ! MI !
NE ! EQ !
OV ! NOV !
PE ! PO !
GE ! LT !
GT ! LE !
UGE ! ULT !
UGT ! ULE
<flags> ::= C ! Z ! S ! P ! V
<register> ::= <byte register> ! <word register> !
<long register> ! <quad register> !
<byte register> ::= RH0 ! RL0 ! RH1 ! RL1 ! RH2 ! RL2 ! RH3 ! RL3 !
RH4 ! RL4 ! RH5 ! RL5 ! RH6 ! RL6 ! RH7 ! RL7
<word register> ::= R0 ! R1 ! R2 ! R3 ! R4 ! R5 ! R6 ! R7 !
R8 ! R9 ! R10 ! R11 ! R12 ! R13 ! R14 ! R15
<long register> ::= RR0 ! RR2 ! RR4 ! RR6 ! RR8 ! RR10 ! RR12 ! RR14 !
RR16 ! RR18 ! RR20 ! RR22 ! RR24 ! RR26 ! RR28 ! RR30
<quad register> ::= RQ0 ! RQ4 ! RQ8 ! RQ12 ! RQ16 ! RQ20 ! RQ24 ! RQ28
<control register> ::= PS ! PC ! FCW ! PSAP ! NSP ! OSP ! HICR ! SCCL !
SITTD ! SDTTD ! NITTD ! NDTTD !
PSAPSEG ! PSAPOFF ! NSPSEG ! NSPOFF (* Z8001,Z8002 *)
<string constant> ::= ' <ASCII sequence> '
---------------------------------------------------------------------------------
<identifier> ::= <alfa> (<alfa> ! <num>)*
<literal> ::= (NIL ! % ) (num)+
<ASCII sequence> ::= (<alfa> ! <num> ! <spec>)*
<num> ::= 0 ! 1 ! 2 ! 3 ! 4 ! 5 ! 6 ! 7 ! 8 ! 9 !
A ! B ! C ! D ! E ! F
<alfa> ::= A ! B ! C ! D ! E ! F ! G ! H ! I ! J !
K ! L ! M ! N ! O ! P ! Q ! R ! S ! T !
U ! V ! W ! X ! Y ! Z !
a ! b ! c ! d ! e ! f ! g ! h ! i ! j !
k ! l ! m ! n ! o ! p ! q ! r ! s ! t !
u ! v ! w ! x ! y ! z ! _ ! $
<spec> ::= "!" ! " ! # ! % ! & ! ' ! ( ! ) !
= ! ^ ! - ! @ ! * ! : ! + ! ; ! < ! > ! ? !
, ! . ! / ! Æ ! Ø ! Å ! æ ! ø ! å
---------------------------------------------------------------------------------
Tabel 3. Instruktioner
Tabel 4. Direktiver
2. A-kodens udformning.
3. Udskriftsformat.
En af assemblerens funktioner er at generere en udskrift. Da de fleste
højniveausprogsoversættere må forventes selv at danne en udskrift, som
reflekterer højnniveausproget, vil assemblerens udskrift fortrinsvis blive
benyttet ved afprøvning af oversættere, ved særlige anvendelser af oversættere
og ved overrsættelse af assamblerprogrammer fra klartekst, hvor man ønsker at
objektkoden fremkommer i udskriften. Da assemblerens hovedformål er at fungere som
sluttrin for oversættere bør information om udskriften ikke give et væsentligt
bidrag til A-kodens fylde, og det er derfor valgt at danne formaterede
symbolske maskinsprogsudskrifter.«eof»