⟦d02128b53⟧

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
$#hovedah 1986.05.21
$#hovedbv LGJ
$#hovedbm
$#hovedbh Side #
$#hoveddm ______________________________________________________________
$#formatter


NOTER vedrørende tekniske spørgsmål diskuteret på møde
mel^-lem AC og LGJ den 1986.05.20 Englandsvej.

På mødet diskuteredes følgende 8 tekniske spørgsmål:

$#kopier
1    IO. Drivobjekter, sprog, afbrydelser. (AC)
2    subsegmentargumenter.                 (AC)
3    Processkrift under EPU-operationer.   (AC)
4    EPU-undtagelser (exceptions).         (AC)
5    2 typer faldlemme (traps).            (AC)
6    Sidetabeller.                         (AC)
7    Materielforudsætninger (målmaskine).  (LGJ)
8    Kerneindhopskonventioner.             (LGJ)
$#formatter



Ad 1 IO. Drivobjekter, sprog, afbrydelser. (AC)

     Dette emne berørtes løseligt, men ingen beslutninger
blev taget. Spørgsmålet venter næmere afklaring, når en
mere udtømmende forståelse af NCR's implementation er opnået.

Ad 2 subsegmentargumenter.                 (AC)

     AC fremlagde en ide. Denne refereres af AC i separat
dokument.

Ad 3 Processkrift under EPU-operationer.   (AC)
$#
og 4 EPU-undtagelser (exceptions).         (AC)

     AC besluttede, at version 1 af kernen ikke behøver
at kunne håndtere EPU-enheder - hverken faktiske eller
emuleri^-ng af disse. Når emnet igen tages op, skal der
fremstilles 2 typer af kernen: 1 for faktisk EPU og en
for emuleret EPU.

Ad 5 2 typer faldlemme (traps).            (AC)

     Under et salgsmøde hos Bruel & Kjær havde MP og AC
fået oplyst, at man hos B&K skelnede mellem 2 typer
undtagelser.

$#kopier
   enkeltobjektrelaterede undtagelser
        (f.eks. overflow trap).
   ikke-enkeltobjektrelaterede undtagelser
        (f.eks. ur-afbrydelse).
$#formatter

     De enkeltobjektrelaterede undtagelser frembyder et
im^-plementationsproblem, idet de kan skulle behandles på
for^-skellige måder afhængigt af hvilket objekt, de er knyttet
til, medens den anden gruppe undtagelser altid behandles på
samme måde. Tre løsningsmetoder blev opregnet og AC valgte en.

$#liste 120
$#punkt 1
Der benyttes ialt en tabel for undtagelsesvektorer (i Z80.000 kaldet PSA),
og ved kontekstskift ændres de enkeltobjektrelaterede undtagelsesvektorer,
således at de udpeger den rette undtagelsesrutiner.

$#punkt 2
Der benyttes en tabel for undtagelsesvektorer per ob^-jekt, og ved
kontekstskift ændres dt register, der ud^-peger tabellen. Denne løsning er
muligvis ^-^-Z80.000-specifik og i alle fald meget lagerpladskrævende.

$#punkt 3
Den valgte løsningsmetode. Der benyttes i alt en tabel for
undtagelsesvektorer, og når en enkeltobjektrelate^-ret undtagelse indtræffer
(hvilket antages at ske ^-^-sjældent) overlades det til den pågældende
undtagelses^-rutine ved hjælp af kernevariable/tabeller at kalde en procedure
i det rette objekt.
$#liste 0

Ad 6 Sidetabeller.                         (AC)

     AC påbegyndte fremlæggelse af en ide. Denne refereres
af AC i separat dokument.

Ad 7 Materielforudsætninger (målmaskine).  (LGJ)

     Der hersker stadig usikkerhed om, hvilken maskine
^-^-systemet skal udvikles til. For tiden overvejes at skifte
fra Z80.000 til M68.000 eller NS32.000 eller muligvis til en
oem-maskine (f.eks. IBM PC). Oem-maskiner anses dog ikke for
at være et realistisk alternativ.
     Følgende antagelser skulle imidlertid ifølge AC være
så sikre, at kerneændringer kan baseres på dem:

$#liste 120
$#punkt a)
Maskinen vil have sidedelt lager. Residente objekter er
derfor unødvendige.

$#punkt b)
Kernen vil kunne arbejde i det virtuelle adresserum.
Datastrukturer behøver derfor ikke at forefindes på
sammenhængende sider i det fysiske adresserum.

$#punkt c)
Afbrydelser er ikke tidskritiske. Der benyttes perifere
Z80'ere eller andre mekanismer til at styre og mellem^-bufre
data fra de ydre enheder. Afbrydelsesrutiner be^-høver derfor
ikke at kunne afbrydes, og kernen behøver følgelig kun at
skelne to procesprioriteter: En for almindelige processer
og en for afbrydelsesrutiner. -- Der er dog et problem her
i forbindelse med undtagelser under afbrydelsesbehandling.

$#punkt d)
Der kommer kun få afbrydelser til den centrale CPU.

Ad 8 Kerneindhopskonventioner.             (LGJ)

     Kerneindhopskonventioner. Disse var ikke forhånds^-fastlagt
af AC ligesom heller ikke Metanic Pascals pro^-cedurekaldskonventioner
var det. LGJ skitserede en me^-tode, som man enedes om kunne
benyttes som udgangs^-punkt.
     Kernen udformes som et pascalprogram, der eks^-porterer
en procedure på yderste niveau. I den normale driftssituation
fungerer denne procedure som undtagel^-sesrutine for system
call trap (dette er vist Z80.000 specifikt), hvorfor dens
indhopsadresse skal skrives i undtagelsesvektortabellen.
Når et objekt ønsker at ^-^-kalde kernen, må det først placere
kernekaldsparametre^-ne forskriftsmæssigt og derpå generere
en "system call trap". Når undtagelsesrutinen derpå bliver
aktiveret, må den først afgøre parametrenes position og
derpå ind^-lemme dem i sit virtuelle adresserum ved opdatering
af memory management tabeller/registre. Dernæst kan den
afhængigt af de givne parametre udføre den ønskede ^-^-funktion,
placere sit resultat forskriftsmæssigt og udføre en IRET
instruktion (return from interrupt), hvorved den
kernekaldende kontekst igen aktiveres,
     Den forskriftsmæssige placering af kernekaldspara^-metre
og resultater af kerneoperationer er ikke fast^-lagt. Det
bemærkedes dog, at

$#liste 120
$#punkt 1)
eftersom der ikke er nogen (principiel) øvre grænse for
omfanget af sådanne paramtere, kan de ikke placeres
udelukkende i registre, men må placeres i lageret på en
adresse, som kunne udpeges af et register på samme måde
som i NCR's implementation.
$#punkt 2)
NCR's implementation benytter ikke SP-registeret til
dette, og at man således opnår frihed til at placere parametre
udenfor stakken.
$#punkt 3)
resultaterne, der har fast omfang, returneres gennem
registre.
$#liste 0

     Ved initialisering af systemet kaldes hovedprogrammet
af materiellets "boot strap loader", hvorfor en konvention
for benyttelse af indhopsadresse må vedtages. Hovedprogram^-met
foretager den fornødne initialisering og kalder derpå det
brugerdefinerede initial-objekt (objektkataloget) ganske
som i NCR's implementation.
     Hvor vidt initialisering af materiellet (i Z80.000
^-^-f.eks. HICR) skal udføres af kernen, "boot strappen" eller
eventuelt et særligt trin mellem disse henstår uafklaret.

«eof»
DataMuseum.dk

Bogika Butler

⟦d02128b53⟧ TextFile

Derivation

TextFile
