prof.dr.ir. A.J. van de Go o r & ir. H.A.Span je rsbe rg BIBLIOTHEEK TU Delft P 2118 5305
111I111111111
23513c
8743332
© A.J. van de Goor & H.A. Spanj ersberg Eerste druk 1985
Delftse Uitgevers Maatschappij b.v.
P.O.Box 2851, 2601 CW Delft, The Netherlands Tel. 015-123725
Alle rechten voorbehouden. Niets uit deze uitgave mag worden verveelvoudigd,
opgeslagen in een geautomatiseerd gegevensbestand, of openbaar gemaakt, in enige vorm of op enige wijze, hetzij electronisch, mechanisch, door fotokopie ën, opnamen ofop enige andere manier, zonder voorafgaande schriftelijke toestemming van de uitgever. All rights reserved. No partofthis publication may bereprodu ced ,stor ed in aretrieval sy stem , or transm itted, in any form or by any means, elec tro nic , mechan ical, pho to -copying, recording, orotherw ise, witho u t theprior written perm ission ofthe publishe r. ISBN 9065620257
-3
Voorwoord
Com pu t erarchitect u ur is een meer-dimensionaal begrip. Vaak wordt het gebruikt in relatie tot de uitrusting van digitale systemen. Dit boekwerk behandelt computer-architectuurals raakvlaktussen de hardware en de software. Het poogt een achter-grond en verklaring te geven voor instructie-sets, adresseringsvormen,datatypen, interruptsystemen , enzo voortsvan traditionele computers. Daarnaast worden kwa-liteitscriteria als orthogonaliteit, voorspelbaarheid,enzovoorts waaraan een go ed e architectuurmoet voldoen behandeld;deze worden bij de behandelde voorbeelden als toetsgebruikt. De gevolgde methodiek is toepasbaar op vele gebieden buiten dat van de computerarchitectuur.
De behandelde stof is voorzien van voorbeelden uit diverse bestaande architecturen om bepaalde concepten te illustreren. Als voorkennis wordt enig inzich t in de PDP-I I of vergelijkbare architectuur verondersteld en enige achtergrond in programmeer-talen.
De geboden stof is ontstaan uit het college Co mpu t erarchit ect u ur aan deTechnische Hogeschool te Delft en is geschiktvo or TH-studenten in hun latere studiejaren en voor HTS-studenten in hun laatste jaar.Gezien de uitgebreidheid van de materie is besloten de stof in twee delen te splitsen. In het tweede deel zullen de volgende aspecten aan de orde komen: invoer/uitvoer, geheugenbeheer, foutendetectie en -afhandeling en nog enkele trends zoals module-en multiprocessoronderst eu ning. Een woord van waardering aan de medewerkers van de VSSD mag niet ont breke n . Zij zijn er in korte tijd in geslaagd de vele vaak handgeschreven en moeilijk leesbare concepten om te zetten in cameraklare pagina's.
Voor opbouwende kritiek en suggesties hebben de auteurs een open oor; zij zullen deze met belangstelling afwachten, zodat deze in een hopelijk noodzakelijke herdruk verwerk t kunnen worden.
n
Delft,december 1984 A.J. van de Goor
H.A. Spanjersberg
Inhoud
1. Begrippen en definitie s 11 1.1.0ntwerpniveaus 11 1.1.1.Architectuur 11 1.1.2. Uitrusting 11 1.1.3.Realisatie 131.2 . Redenen voor indeli ng in niveaus 15
- , 1.2.1. Verdeling van he t werk 15
1.2 .2. Eenheid van concept 16
1.3. Do elstelling en midd elen 16
1.3.1. Architectu ur 16
1.3.2. Uitrusting 17
1.3.3 .Realisatie 17
1A. Onderlinge beïn vlo eding van de ontwerpniveau s 18
l.S. Kenmerken van een goede architectuur 18
1.5.1. Conse quen theid 19
1.5 .2 . Orthogo naliteit 20
1.5 .3 . Eigenheid 20
1.504. Spaarz aam heid 21
1.5.5. Volledigheid 21
1.5.6.Evenwichtigh cid 22
1.5.7. Transparantie 22
1.5.8 . Algemeenheid 22
1.5 .9 . Openheid 23
1.6. Arc hitectu urst ro mingen 23
1.6.1 .Program m atuur-georièn teerde architectu ren 23 1.6 .2 . Apparatuur-georiënteerdearchitectuur 24
1.6.3 . Neu traal 24
1.604. Speciale toepassingen 25
1.7. Invloed van programm eert alen op de archi t ectuuren omgekeerd 25
1.7 .1. Interpre tati e ve talen 27
1.7.2 . Compilatie -talen 27
1.8. Architectuur een uitdaging 28
1.8.1.Econo misch aspec t 28
1.8.2 . Ontwik keling elektronisc he bouwsten en 29
1.8.3.Hoger niveau talen 29
2. Machineniveaus 31
2.1. Verschillende taalniveaus in bestaande machines 31 2.2. Overgang van een hoger naar een lager taalniveau 33
2.2.1. Vertale n 33
2.2 .2 .Interpret eren 35
2.2.3. Mengvorm van interp rete ren en vertalen 36 2.3 . Gebruik van overgangen tussen taalniveaus in traditionele machines 37 204. Implementatie van nieuwe niveaus, virtuele machines 37 2.5. Grensvlak tussen hardware en software en de keuze van machine- 38
6
2.6. Portabiliteit van programmatuur 2.6 .1. Universele prog ram meertaal 2.6.2.Directe meth ode
2.6.3. Uncol 2.6.4. Em ulatie
2.6 .5. Zelf- virtualiseren d systee m 3. Representatie van gegevens
3.1. Vorm van alledaagsegegevens 3.1.1. Getallen 3.1.2. Symb ol en 3.2 . Scalaire datatypen 3.2.1. Integers 3.2.2 .Decima le getalle n 3.2.3. Booleans 3.2.4. Karakters
3.2.5.Gebroken getallen t'reats '} 3.3. Gestructureerde datatypen 3.3.1. Sets 3.3.2. Karakter-strings 3.3.3. Vect or en en arrays 3.3.4. Records 3.3.5. Access-ty pe
3.4. Procedure-& functie-parameters 3.4.1. Call by reference
3.4.2.Call by value 3.4.3. Call by result 3.4.4.Dummy argum enten 3.4.5. Call by name 3.5. Data-allocatie
3.5.1. Statisch e data-allocatie 3.5.2 .Dynamisch e data-allocatie 4. Machinetalen
4.1. Frequentiemetingen
4.2. Vormen van machine-instructies 4.2.1. Vast aan tal operanden
4.2.1.1. Vast aantal operanden en vaste instructielengte 4.2.1.2. Vast aantal operanden en variabele instructielengte 4.2.2. Vast aan tal operanden
4.3. Instructiecomponenten
4.3.1. Specificatie van het datatype
4.3.1.1. Datatype-specificatie in opecde-ruim te 4.3.1.2.Datatype-sp ecificatie in operand-ruimte 4.3.1.3.Datatype-specificatie in de data-ruimte 4.3.2 .Datastructuur-specificatie
4.3.2.1. Datastructuur-specificatie in de opcode-ruimte 4.3.2 .2. Specifi catie van datastructuur in op eran d-ru im te
41 41 42 43 44 45 47 47 48 48 49 51 52 55 56 59 65 65 66 67 71 73 76 77 78 78 78 78 79 79 80 87 87 93 96 96 99 100 lal 102 102 103 106 109 109 112
4.3.2 .3 . Datastructuur -specificatie in de data-ruimte 112 4.3.3. Specificatie van de dataru imte en dataloc atie 113 4.3.4.Specif icatie van de waarde n van de data 113 4.3.4.1. Waardespecificatie in de opcode -ruimte 114 4.3.4.2. Waardespecificatie in de opera n d-ruimte 114 4.3.4.3. Waardespecificatie in de data-ru imte 115
4.3.5 .Specifi catie van de opcode 115
4.3.5.1. Opecde-specificatie in de opecde-ruimte 115 4.3.5.2. Opco de-specificatie in de ope ran d-ruim te 116 4.3.5.3.Opcode-specificatie in de data-ruimte 118 4.4. Indirect-specificatie van instructie-componenten 118 4.4.1. Indirecte dataty pe- en datastructuur-sp ecificat ie 118 4.4.1.1.Dataty pe-en datastru ctuur-sp ecificati e viade operan d -ruimte 118 4.4.1.2.Data typ e-specificatie en datastruc tu ur-spec if icatie via de 120
data-ruimte
4.4.2. Indirecte ope ran d spec if icatie 120
4.4.3. Indirecte opco de-spec ific atie 121
4.4.4.Indirect e instructie-specificatie 122
4.5. Onderlinge afhankelijkheid van instructie-componenten 122 4.5 .1.Ontkoppeling van dataty pe en ope rand-leng te 123 4.5.2. Un ifo rm ite it en onaf ha n ke lijk heid van ope ran d-specifica tie 123 4.5.3. Variabele gro otte van een displacem ent 123
4.5.4. Sam engest eld e operande n 124
5. Adressering 127
5.1. Algemene eigenschappen van adressering 127
5.1 .1 . A dresresolu tie 127
5.1.2.Byte- en wo ord volgorde 128
5.2. Adresruimten 129
5.3 . Onmiddellijke adressering van data 132
5.4. Absolute adressering van data 133
5.5. Relatieve adressering van data 134
5.6. Adressering met 'pointers' 136
5.7. Adressering van array-elementen 137
5.8. Stacks 139
5.9. Parameter adressering 141
5.9.1. Parameteradressering bij statische allocatie 141 5.9.2. Parameter adressering bij dynamisch e allocatie 142
5.9.3.Nebula-parameteradressering 143
5.10 .Displays 144
5.11. Instructie adressering 145
5.11.1. Condition elespronginstructies 145
5.11.2. 'Loop vsprongins truc tie 147
5.11.3.Instru cties voor deaanroep van procedures en su brou tine s 148
5.12. Compacte operandspecificaties 148
5.12.1. Impliciete operande n 149
5.12.2.Regist ers 149
8
5.12.4. Relatieveadressering 5.12.5. Poolin g
5.12.6. Overzi cht VAX-]] operand-vorme n 5.13. Voorbeelden van operand-specificaties
6. Operaties op data 6.1. Operatie-typen 6.2. Data handling
6.2.1. 'Data mo ve-o perat ies 6.2.1.1. Enkelvo u dige 'mo ve ' 6.2.1.2.Meervoudige 'mo ve '
6.2.1.3.De 'exchange 'en 'swap'operaties 6.2.2. Formaattran sf ormatie
6.2.2.1. Schuif-op erati es 6.2.2.2 .Bitveld operaties 6.2.3. Codetransformatie
6.2.3.1.Codetransformatie via een tabel 6.2.3.2.Formaattransformatie
6.3. Logische operaties 6.3.1. Aantal ope rande n 6.3.2. Aan tal ope raties 6.3.3 . Afge leide resultaten
6.4. Arithmetiek op getallen met vaste komma 6.4.1. Vaste datalengt e en vaste-ko m m aaritmetie k 6.4.1.1. Optellen en aftr ekken
6.4.1.2. Vermen igvuldigen 6.4.1.3. Delen
6.4.2. Aritmetiek op integersmet variabele lengte 6.5. Aritmetiek voor getallen met drijvende komma
6.5.1. Optellen en aftr ekken
6.5.1.1. Algori tme voor effectieve op telling 6.5.1.2.Algoritm e vooreffectieve aftrekking 6.5.1.3. Guard digit
6.5.2. Vermenigvuldigen en delen 6.5.3. Dubbele precisie
6.5.4.Extrema
6.5.4. 1.Maximum en minimum exponent 6.5.4.2 .Aantal significante digits
6.5.4.3.Nul-representatie 6.6. Conditionele aritmetiek 6.7. Complexe operaties 7. Instructievolgorde 7.1 . Lineaire volgorde 7.1.1. Functionele afhankelijkheid 7.1.2. Lokatiebepaling 7.2. Beslissingen
7.2.1. Vergelijkingvan twee groothe de n
150 15 1 151 152 155 155 159 160 160 161 163 164 165 172 172 173 175 176 177 178 178 179 180 181 184 186 188 190 191 191 193 193 194 195 195 195 196 196 197 197 199 199 200 203 204 205
7.2.1.1. Vergelij king van een ite m met nul
7.2.2 . Niet-gerangsc h ik te vergeli jk ing met N groo the de n 7.2.3. Gerangschikte vergelij k ing met N grooth ed en 7.2.3 .1 . 'R ange -vcrgelijking
7.3. Conditie-codes 7.3 .1. Het testen 7.3.2.Het selec teren
7.3.3. Het uit vo eren van deactie 7.3 A. Architec tu ur-al te rnatieven 7 A. Conditioneleacties
7 A.I. A dres-sp ecifi catie
704.2 .Keu z e uit aantal vervolgwegen 704.3 .Activerin g
70404.Condition ele instructies 7.5. Iteratie
7.5 .1 .'For'-statem ent 7.5.2. 'Do-while loop' 7.5.3. 'Do-untilloop ' 7.6. Procedure-aanroepen
7.6.1. Nesting
7.6.2.Herbrui kbaarh eid
7.6.3.Doorge ven van parameters 7.7. Subroutine-mechanismen
7.7.1.Su broutine-aanroep
7.7.2. Vastleggen van het terugkeeradres 7.7.3.State saving en rest oring
7.7 A.Param etersdo orgeven 7.7.5. En keleactue le voorbee lden
7.7.5.1.Procedu re-ondersteun ing bijNS 16 000-architectuur 7.7.5.2. Ondersteun ing van pro ceduresin de VAX-ll
Alfabetische lijst van ref eren ties
206 207 208 211 211 211 212 212 212 217 217 219 220 221 222 223 225 225 225 226 226 228 228 229 229 233 234 235 235 242 247
1. Begrippen en definities
Het is in het algemeen nuttig, en in de exacte wetenschappen gebruikelijk, bij het bespreken van een bepaald vakgebied (of delen daarvan) van te voren te definiëren wat men onder de gebruikte terminologie dient te verstaan. Dat is ook de bedoeling van dit hoofdstuk, waarin begrippen worden gedefiniëerd en de terminologie wordt verklaard die in de computer-architectuur gebruikelijk is.
1.1. Ontwerpniveaus
Bij het ontwerpen en beschrijven van systemen in het algemeen en van digitale re-kenmachines in het bijzonder kunnen drie verschillende ontwerpniveaus worden onderscheiden (Blaauw [B173]), namelijk:
• de architectuur
• de uitrusting (implementatie) • de realisatie.
Een boek dat de architectuur en tevens de uitrusting en de realisatie van computers van Digital Equipment Corporation uitvoerig behandelt, is: Com pu ter Engineering, (BeIl [Be 78]).
Om een goed beeld te geven van wat met de drie bovenstaande begrippen wordt bedoeld, volgen nu de definities van deze gebieden met een korte toelichting.
1.1.1.
Architectuur
"De architectuur van een systeem kan gedefinieerd worden als de functionele verschijning van dat systeem, zoals die door de gebruikers ervaren wordt" [BI 73] Men zou dit de fenomenologie van het systeem kunnen noemen. De term archi-tectuur is voor het eerst omstreeks 1960 door Brooks in relatie tot computers ge-bruikt, maar het zal duidelijk zijn dat, in dit licht bezien, in feite elk mechanisme een architectuur heeft en derhalve is het begrip 'architectuur van systemen' al veel ouder.
Wanneer een kind leert 'klok kijken', dan leert het eigenlijk de architectuur van de klok hanteren. Het weet dan dat er twee wijzers zijn, een grote voor het aan-wijzen van de minuten en een kleine voor het aangeven van de uren en dat de stand van beide wijzers gezamenlijk de tijd aangeeft. Kan dat kind eenmaal deze archi-tectuur onderscheiden van de vormgeving, dan kan het even gemakkelijk een pols-horloge als een kerkklok gebruiken om te zien hoe laat het is.
De architectuur van een computer wordt vastgelegd in een beschrijvend document (bij IBM-machines "Principles of Operations" genaamd). Figuur 1.1.1 toont de architectuurbeschrijving van de PDP-ll MOVE instructie zoals die in het PDP-ll Processor Handbook (Digital Equipment Corporation [DEC 75]) is opgenomen.
1.1.2. lJitrusting
Met de uitrusting van een systeem wordt bedoeld: de logische structuur die aan de architectuur gestalte geeft. We zouden kunnen zeggen dat de architectuur beschrijft wat er gebeurt, en de uitrusting hoe dit tot stand komt.
Om nog even het voorbeeld van de klok aan te halen: de uitrusting beschrijft op welke manier de energie wordt geleverd om de wijzers te doen draaien (zwaarte-kracht, veer(zwaarte-kracht, elektriciteit) en op welke wijze het tempo van de draaibeweging
12
MOV
MOVB
move sou ree to destin at ion10/1
I 0 15 o 6 d 5 d d I d d o Operation : (dst)..{src)ConditionCodes: N:set II(src) <0: cleared Z:set il (src) =0:cleared V: cleared
C:not all ect ed
Description : Word:Movesthe souree oper an dto the desti natio nlocati on . The previou s eonten ts ol the deslinati on arelost. Thecon -tents ol the souree address are not affected.
Byte:Sam e as MOV.TheMOVBto a register(uni quearnong byte inst ructions)cxtends thc most sigmlicant bit ol the low
order byt e (sign extensio n). Otherwise MOVB operate s on
bytes exactl y as MOV oper at eson word s.
EXèlmple: MOV XXX.Rl ;loads Register1 withtheco
n-tents ol mem orylocat ion:XXXrepresen tsa pregr amm er-
de-lined mnemon ic usedto represent amemory iocation
MOV ::: 20 .RO : loads the numbe r 20 into Register0; ":::"indicates that the value 20is the operand
MOV @#20,-(R6) : pushes the operand con tained inlocation 20on to the stack
MOV(R6)+.@ ::: 177566 :.papstheoperand011the stack
and movesit int o memory location 177566(termi nal print buffer)
MOV Rl.R3 registertranster
performs an int er
MOVB @# 177562,@#177566 ; moves ach arader
trom terminal keyooard buffer to terminal printerbuIIer
Figuur 1.1.1.Architec tuur van PDP-U Move instructie.
wordt gestabiliseerd (balan s, slinger, kristal, stemvork, periode elekt risch net ).
Bij het ontwerpenvan computers kan men bijvoorbeeld voor wat betreft de uitrusting: • de signaaloverdracht tussen, respectievelijk binnen, onderdelen van de compute r
serie-gewijs of parallel laten verlopen of kiezen voor mengvormen daarvan; • bepaalde informatie al dan niet coderen;
• sommige onderdelen voor één bepaalde bewerking inzetten,danwel door diverse bewerkingen gemeenschappelijk laten gebruiken.
De uitrusting van een computer bestaat onder andere uit een datapad met een be-sturing. Figuur 1.1.2 toont het datapad van de PDP-ll/45.
ng:
Figuur 1.1.2.Dat apadvan PDP-II/45.
Het vast staan van de archit ectuuris geen beperking voor de on t werper van de uitrusting. Zoals uit voorgaande opsomming blijkt,heeft deze ontwerper een groot aantal graden van vrijheid (bijv.door bij de uitrusting van een klok te kiezen tussen een mechanische en een elektrische aandrijving). Een goede architectuur zal het aanta lvrijheidsgraden niet beperk en, zodat een bepaalde architectuur tot een veel-heid van uitrustingen kan leiden.
1.1.3. Realisati
e
Om tot een tastbarevorm van het uitrusting-ontwerp te komen, moet worden be-paald welke componenten worden gebruikt, hoe deze onderling verbonden moeten worden en hoe deze componenten t.o.v. elkaar geplaatst moeten worden. Dit gebied noemen we de realisatie.
Het zal duidelijkzij n dat de realisatie sterk gebonden is aan de voortdurende ont-wikkeling van componenten. Een voorbeeld hiervan zijn de verschillende generaties van de IBM/360 machines (voor een architectuur beschrijving zie Amdahl [Am 64] en International Business Machines [IBM 70]), welke alle dezelfde architectuur hebben, maar waarbij voor elke generatie gebruik is gemaakt van een nieuwe tech-nologie:
360 Very Small - Small Scale Integration 370 Medium Scale Integration
303x Large Scale Integration 43xl Very Large Scale Integration
De figuren 1.1.3 en 1.1.4 tonen respectievelijk een deel van de schematische en de totale daadwerkelijke realisatie van een Motorola Me 680 I 0 computersysteem. Het bestaat uit twee kaarten (de eerste voor de processor, het geheugen en het geheugen-beheersingssysteem, de tweede voor alle invoer en uitvoer). Voor het bussysteem
14 .c 17 GENI. 10<
,.
.. 5 678 9 10 12 Ic lO 68010L S FeO FCI 27 FC"2 25 ""- 0 ON- 9 LOS- 7 LQS-E 20 """-ACl! "02 "03 "0. A05""'"
"07"""
A09 AIO All Al2 AI3 AI. A15 AIO Al7 AI. 23 IR..2- Al9 2. JP...1- A20 25 1"-0- A2 1 A22 13 8>- ",3 12 a:;A()(-"" -Ic 11 74-5148 /'c 18 ~c:e" nnn n n n /11: 115 74l...S1-4 """'--_..-ij t-PRI/BIN""!
~~î~~~~i~~~~~~
zre: t" 9 1/211 'Z" 2/212 3/213 10 )., ""1104 11 5/Z15 12 6/2115 13 7/2 17 1'" 15 16 17Figuur 1.1.3. Gedeelte van de sch emati sche realisatie van het Motor olaMC 68010 comp ut er
sy ste em.
is de VME-bus gekozen. Verder is het systeem voorzien van een vaste schijf ('Win-chester') en een 'floppy drive'.Bij de schematische realisatie van figuur 1.1.3 is ge-bruik gemaakt van de internationaal gestandaardiseerde IEC-symbolen (lEC
=
Inter-national Electronic Commission) [Po 81].1.2. Redenen voor indeling
in
niveaus
Misschien doet de indeling in drie niveaus die in de vorige paragraaf is gemaakt, op het eerste gezicht wat kunstmatig aan, en vraagt de lezer zich af of dit niet een puur theoretische zaak is, die in de praktijk geen enkele betekenis heeft. Om te laten zien dat dit geen academische kwestie is, bezien we de redenen waarom tot deze indeling is overgegaan. Deze zijn:
• de verdeling van het werk • de eenheid van concept.
In de volgende sub-paragrafen zullen we deze redenen wat meer in detail belichten.
1.2.1. Verdeling van het werk
Als we het gehele ontwerp van een computersysteem bekijken, komen we al snel tot de konklusie dat het voor een ontwerper vrijwel onmogelijk is zo'n systeem in z'n geheel alleen te ontwerpen. Nu zijn er twee mogelijkheden om een te ontwerpen systeem op te delen in afzonderlijke, overzienbare eenheden.
De eerste manier is het systeem op te splitsen in diverse subsystemen, zoals de centrale verwerkingseenheid ('CVE'), het geheugen, input/output, etc. Dit wordt wel de 'horizontale verdeling' genoemd. Een belangrijk bezwaar van deze verdeling is, dat niet alle delen even omvangrijk en beheersbaar zijn, zodat de grotere functio -nele eenheden weer moeten worden gedeeld. De CVE bijvoorbeeld is een te grote en te gecompliceerde eenheid om in z'n geheel door één persoon te laten ont-werpen. Een tweede bezwaar is dat men bij deze horizontale verdeling moet naden -ken en beslissen over het splitsen van eenheden die nog gedefinieerd moeten worden. MeIvin Conway [Co 68] heeft hiervan gezegd, dat dit altijd leidt tot een ontwerp waarin de menselijke organisatie-structuur van de ontwerpers tot uiting komt, i.p.v. dat deze organisatie zodanig is opgebouwd dat het beoogde ontwerp zo goed mo-gelijk wordt gediend. Een derde bezwaar is dat deze manier van splitsen de ont-werpers van de deelsystemen belast met alle aspecten van zo'n deelsysteem: de functies, de taalaspecten om het deelsysteem te doen functioneren, de keuze van de bouwstenen, de plaatsing van de bouwstenen, enz. Dat betekent dat een ont -werper een groot aantal verschillende disciplines en technologieën moet beheersen. Maar als ernstigste bezwaar wordt gezien de als vanzelf optredende differentiatie in de beschrijving van de verschillende deelsystemen en in de taalaspecten waarmee het ontwerp door de andere deelsystemen moet worden 'aangesproken': dat is tenslotte het eindproduct waar de gebruiker voor wie het systeem ook is ontworpen -mee te maken krijgt.
Bij een dergelijke verdeling van het werk zal blijken, dat het ontwerp van elk der deelsystemen weliswaar beantwoordt aan de afgesproken 'interfaces',maar dat elke ontwerper daar op zijn eigen wijze aan tegemoet gekomen is, zodat de voorzienin-gen in de taal om de verschillende eenheden aan te roepen structureel van elkaar zullen verschillen.
16
Bij de andere maniervan werkverdeling - zoals aangegeven in de splitsing archi-tectuur,uitrusting en realisatie - die ook wel de 'verticaleverdeling' wordt genoemd, treden deze bezwaren niet op. Het vaststellen van de functies en de taalaspecten om die functies te activeren, is afgezonderd van het ontwerp van de implementatie, dat op zijn beurt weer een ander deel is dan het ontwerpen van de componenten en hun onderlinge verbindingen.
1.2.2.
Eenheid van concept
Uit de opsomming van de bezwaren tegen de horizontale verdeling blijkt reeds,dat de eenheid van concept belangrijk is voor de kwaliteit van het ontwerp. De gedach-tengang die daaraan ten grondslag ligt, is de volgende:een computersysteem is voor een bepaald type gebruikers bedoeld, zodat die gebruikers - of althans:een deel van die gebruikers- de architectuur moeten begrijpen;daarom moet het mo-gelijk zijn een gehele architectuur door één enkele persoon te doen begrijpen, be-heersen en ontwerpen, hetgeen alleen mogelijk is als het ontwerp consequent is; dit kan slechts worden bereikt door het ontwerp door één enkel individu te laten opstellen, of hooguit door een klein aantal met elkaar samenwerkende personen (Brooks [Br 75
D.
1.3.
Doelstelling en middelen
Uitgaande van de eerder genoemde driedeling in architectuur, uitrusting en realisatie, zal in deze paragraaf worden nagegaan wat de doelstelling van de verschillende deel-gebieden is, en welke middelen de ontwerper in dat deelgebied ten dienste staan.
1.3.1. Architectuur
Het eindproduct van de computerarchitectuur is het gebruikershandboek, dat alle details bevat die de gebruiker moet weten en die hij/zij vroeger of later ook zeker te weten komt (zie figuur 1.1.1). Het handboek moet niet alleen alles beschrijven waarmee de gebruiker wordt geconfronteerd, maar zich ook onthouden van alles wat niet zichtbaar is. De specificatie moet bovendien duidelijk laten uitkomen wat (nog) niet gedefinieerd is.
Behalve dat de specificaties volledig beschreven moeten zijn, dienen ze ook nog uit-voerig door middel van simulaties geverifieerd te worden om te voorkomen dat even-tuele tegenstrijdigheden en omissies onopgemerkt blijven. Het ondubbelzinnig speci-ficeren en het verrichten van simulaties pleiten voor het gebruik van een formele taal om de beschrijving vast te leggen: de schrijftaal is onvoldoende ondubbelzinnig om een ontwerp scherp te omschrijven.
Een aantal talen is voor dit doel ontworpen, zoals uit het volgende overzicht blijkt:
jaar van
taal auteur(s) in trod uctie machine
APL Iverson 1962 IBM SYSTEM/360
LOnS Schlaeppi 1964
COL CHU 1965
ALERT Friedrnann 1969
PMS BeH en Newell 1970 DEC POP/U
ISP BeH en Newell 1970 DEC POP/U
rd,
e,
l
-Dit gebied is nog steeds in ontwikkeling, zodat geen algemeen geldende aanbeveling kan worden gegeven om één van deze talen te prefereren.Wel kunnen eisen worden
geform uleerd waaraan zo' n taal moet voldoen, namelijk :
• hoog niveau;daarmee wordt bedoeld dat elke gewenste functie direct kan
worden weergegeven;
• conversationeel;dat is van belang voor de ontwerpprocedure; • gestru ctureerd ; om een goede ontwerpstructuur te waarborgen.
1.3.2.
U
itrusting
Het doel van de logische ontwerper is optimaliseren: een minimale pri
js/prestatie-verhoudingvoor het beoogde toepassingsgebied. Daarbij is de hoeveelheid aspecten
die in deze beschouwing betrokken zijn een maatstaf voor de kwaliteit van het
ont werp. De kosten van opleiding, installatie en onderhoud moeten betrokken
worden in beslissingen die tijdens het ontwerpen worden genomen. Bijvoorbeeld
wanneer het gaat om het behandelen van fouten: deze kunnen worden genegeerd, het systeem kan ze registreren, het systeem kan actief reageren door de gebruiker
op fouten te attenderen, maar zou bepaalde fouten ook kunnen herstellen. Het is aan de ontwerper van de uitrusting (im plem entati e) om hieruit een verantwoorde
keuze te maken.
De ont werp er kan zich bedienen van diagrammen waarin functies symbolisch door
blo kk en worden weergegeven en de samenhang van deze functies door verbindende
lijnen tussen de blokken wordt aangeduid.Toegespitst op het ontwerpen van de uitrusting kan op dit niveau een te ontwerpen systeem worden weergegeven door
een blo kschema, waarin de blokken de logische functies van schakelingen
represen-teren en de onderlinge verbindingen de signalen aanduiden.(zie figuur 1.1.2). Ook voor het specificeren van de implementatie bestaan diverse talen, zoals uit
on-derstaand overzicht blijkt :
.n - i-taal RTL APL REGISTERTRANSF ER CASSENDRE DOL AHPL ALERT jaar van
au te ur(s) introducti e machin e
Reed 1952
Iverson 1962 IBM SYSTEM/360
Sch orr 1964
Mermet 1966
Duley en Dietmeyerl967 HilI en Peterson 1968
Friedman 1969
Tab el 1.3.2. Uitrustingst alen .
Dit gebied is evenzeer nog in ontwikkeling. Opgemerkt wordt dat APLen ALERT
zowel voor architectuur als voor implementatie geschikt zijn (zie ook tabel 1.3.1).
1.3.3. R
ealisatie
Het resultaat van de realisatie-ontwerpfase is een beschrijving van het (dee1)systeem
in een vorm die voor fabricage en onderhoud geschikt is. Een goede realisatie dient
zonder al te veel problemen bouwbaar te zijn en, niet te vergeten, onderhoudbaar.
Componenten-keuze, plaatsing,koeling,enz.zijn belangrijke realisatie-facetten (zie figuren 1.1.3 en 1.1.4).
18
Het belangrijkste hulpmiddel bij de realisatie is de ontwerp-automatisering (compu-ter aided design). De ontwerper wordt daarbij gevrijwaard van allerlei niet-significante details, en door het systeem geholpen de aandacht te beperken tot de wezenlijke elementen van het ontwerp. Bijvoorbeeld worden door een algorithrnede printbanen berekend bij een gegeven verbindingspatroon tussen de verschillende bouwelementen en aan de ontwerper getoond. Wanneer daar om een of andere reden wijzigingen in moeten worden aangebracht, kan het systeem daarbij behulpzaam zijn.
1.4. Onderlinge beïnvloeding van de ontwerpniveaus
In het voorgaande werden de drie ontwerpniveaus afzonderlijk beschouwd en wer-den de scheidingsvlakken tussen die niveaus globaal aangeduid. Enerzijds is het van belang die scheidingsvlakken zo scherp mogelijk vast te leggen, anderzijds beïnvloedt het ene ontwerpniveau het andere heel sterk. Dat laatste is vanzelfsprekend in de hiërarchische lijn: architectuur ~ uitrusting~ realisatie, maar dat geldt ook in de omgekeerde richting.
Het duidelijk afbakenen van de verschillende ontwerpniveaus geeft binnen zo'n niveau maximale keuzevrijheid. Dit is te illustreren aan de hand van een alledaags voorbeeld: de steker en de wandcontactdoos ('stopcontact') van het openbare elek-triciteitsnet. Het scheidingsvlak tussen architectuur en uitrusting is vastgelegd door de normalisatie van de mechanische en elektrische specificaties waaraan beide moeten voldoen. Er is een veelheid van verschillende stopcontacten geïnstalleerd en een wel-licht nog grotere variatie in vormen van stekers, en toch kunnen ze probleemloos in alle mogelijke combinaties met elkaar gebruikt worden.
Een ander voorbeeld, genomen uit de computertechniek, is de definitie van de UNI-BUS, de input/output-voorziening voor de PDP-ll computerfamilie van Digital Equip-ment Corporation (DEC). Dankzij deze standaard kon de leverancier een assortiEquip-ment randapparatuur samenstellen dat aan alle computers uit de PDP-ll familie kan wor-den gekoppeld; tevens konwor-den in computerinstallaties de processors worwor-den vervangen door krachtiger modellen zonder ingrijpende veranderingen in de randapparatuur. Ten voordele van de gebruikers konden andere fabrikanten apparatuur leveren die met computers van dit type op eenvoudige wijze koppelbaar was.
Beide voorbeelden tonen bovendien de enorme winst aan van modulariteit bij het samenstellen van configuraties en de 'openheid' naar toekomstige ontwikkelingen, indien verbindingen tussen onderdelen volgens een geaccepteerde standaard worden verwezenlijkt.
Toch is het ook van belang dat de ontwerper die binnen één niveau bezig is, zich oriënteert op de andere niveaus: de ontwerper moet als het ware over de muur rondom het eigen ontwerpniveau heen kijken. Als voorbeeld hiervan kan men het verschil in architectuur tussen de VAX-ll en de PDP-Il beschouwen: door het goedkoper worden van de geheugenbouwstenen is het verantwoord grotere primaire geheugens te gebruiken waardoor het adresbereik dient te worden vergroot, terwijl het beschikbaar komen van krachtige digitale bouwstenen de aanleiding is om inge-wikkelder functies aan de architectuur toe te voegen.
l.S. Kenmerken van een goede architectuur
De kwaliteit van een architectuur wordt bepaald door de wijze waarop de diverse functies voor de gebruiker toegankelijk zijn. Het zal duidelijk zijn, dat de gewenste
Ilte ~n :n ten : 1- [- lip-nt r-.gen
functies alle aanwezig moeten zijn, maar dat is niet alles. Zelfs al zijn bepaalde functies voorhanden, dan kan het gebruik daarvan ingewikkeld en vervelend zijn, waardoor de regels voor het gebruik moeilijk te hanteren en te onthouden zijn. Een architectuur die zich als vanzelf laat gebruiken kan als 'helder' worden bestempeld. De vraag of een architectuur goed of slecht is kan niet normatief worden beant-woord ,het is een kwestie van afwegen, van mening, van smaak.
Er zijn echter wel kenmerkenaan te geven,aan de hand waarvan een architectuur kan worden beoordeeld. Deze zijn:
1. consequentheid 2. orthogonaliteit 3. eigenheid 4. spaarzaamheid 5. volledigheid 6. evenwichtigheid 7. transparantie 8. algemeenheid 9. openheid
In de volgen de subparagrafen zullen deze kenmerken nader worden toegelicht.
1.5.1.
Co
nseque ntheid
Een goede architectuur is consequent. Dat wil zeggen, dat met een gedeeltelijke kennis van het systeem het overige voorspeld kan worden.
Alsin een instructie-repertoire bijvoorbeeld een opdracht voor het nemen van de logarithme zou moeten worden opgenomen, dan zal bij een konsekwente archi-tectuur deze bewerking op grond van andere, eerder gespecificeerde opdrachten reeds voor een groot deel zijn vastgelegd. Immers, het formaat van de getallen,en het formaat van de opdracht zullen gelijk moeten zijn aan die voor de andere reken-kundige bewerkingen. Afronding, precisie en significantie zullen op dezelfde wijze als bij de andere bewerkingen moeten worden behandeld. Het nemen van de loga-rithrne uit het getal nul zal een soortgelijke uitzonderingsbehandeling moeten krij-gen als bijvoorbeeld het delen door nul.
0123456789 ~BCDEFGHIJKL~NOpoRSTUVWxYZ
I IJ ',I" •'I...} ,)~1'!1 ",•• '.'.l":'I"nUl.~ • • •·• • •1.1)).)1 >1)1 1"" ) '.""""""IIIoI\oC~I HhJ ~"~'• • lu"UUllt.HUI&l~'"11IJ IJN" .. '\' .. "
111111111 111
e
DUlUlU.OIOOOO:OOOOIOOOOOOOIOOOOIOOOIOOOOIOO.i"'~"'OIOOOI~OOOIO~.ClOOOIOOOOIOOOO I ' J I , , ,• IiI Ull'JM " " 1111 "J'll71nUl'sx n n,)1)IJl l>tnMIN lt a4I I I " '~"UI"'~'l" J\oIU1oI l\ll"OU"U'"H"'"'10nn11"""11 , . "" \ 1 I 1 111 1 1 1 111 1 1 1 1 1 1 1 1 1 1 1 111 1 1II 1 1 111 1 1 1 1 1 1 1 1 111 1 1 1111111 1 1 111 1 1 111 1 1 1111 1 1 1 111 1 1 11 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1 1 1 2 1 1 1 1 1 1 1 2 1 1 1 1 2 1 1 1 1 1 1 1 1 1 1 2 1 ? 1 1 1 1 1 1 1 1 1 1 1 1 ll. l l l l l l l l l l] I] ] ] ] 1 ] ] 1 ] ] ] JlI,]1 ] ] JJ l l . ]ll~l l l' l l l l l l l l l l l ] IJl] III ] Ill.IJll] ] l l l l l l 444444444444441444444444444414444444 144 444414444444444441444144414414444444444 11111111111111111111111111111111111111111111111111111111111111111111111111111111 i,6 , , 6 6 6 6 , 6 6 6 6 6 6.6 6 6 6 6 6 ,i6 6 6 6 616 6 6 , 6i6 61 16 6 6 6 6 6 61 166 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 616166 66 6!'66 6 77177777777111171111777111111111177117777~ 117 1 71111771717 7 7111 7 7 7 7 7111111111111111 11111111111 I 1111 • 111 1111 111 11 11111111111 111
IIIII~IIIII
IIIIII! .111 IIIIIII! 11111111I'J' " ' I11I1I11'J""''' ''Ill'' 1? '' Ü 1) J'~i'\,))f»J'J' 111lJ)ln)l'.nuI t l ' " " ' " " t"~' "J\oI " !14'\4I'uo'UIUIU"'IU~tlO"l1tlNn"'ll'I""
11 11 11111 11 I 11111 11111111111 I 11 ,,1, III 11 I I 11 11 11 l i l l l l l l l l l i l I 11,11IslsI I 11111 I III
_ AIOllll
20
Een voorbeeld van een inconsequent ontwerp is de Hollerith-ponskaartcode (zie fi-guur 1.5.1). Als we de Hollerith-code bekijken, dan zien we dat de code voor de letter S niet is af te leiden uit de kennis van de codes voor de letters A tot en met R, want de code die logischerwijze volgt op die voor de letter R, staat voor het teken '/' (slash). Dit is ooit zo gedaan in verband met mechanische problemen bij de kaartlezers.
1.5.2. Orthogonaliteit
In een goede architectuur worden onafhankelijke functies in hun specificaties apart gehouden. Dit principe wordt orthogonaliteit genoemd, of soms 'separation of concerns'. Het stamt uit de wiskunde, waar het oorspronkelijk werd gebruikt om aan te duiden, dat een aantal richtingen zodanig aan elkaar gerelateerd is, dat een verandering in één van die richtingen, geen veranderingen teweeg brengt in de posities langs de andere richtingen.
Opnieuw een voorbeeld uit de wereld van de horlogemaker: we kunnen de volgende twee voorzieningen aan de 'standaard' functies van een uurwerk toevoegen, nl.: • de zichtbaarheid van de tijd in het donker door het aanbrengen van lichtgevende
wijzers en wijzerplaat,
• het signaleren van een bepaalde ingestelde tijd (de wekker).
Dit zijn onafhankelijke functies en de orthogonaliteit zou geweld worden aangedaan, als de wekker bijvoorbeeld slechts dan zou kunnen functioneren als de wijzers ver-licht waren.
Een ander voorbeeld van orthogonaliteit is het feit dat in een auto voor licht en ruitewisser een aparte schakelaar is aangebracht.
1.5.3. Eigenheid
In een goede architectuur behoren de gespecificeerde functies tot de werkelijke vereisten van een systeem, hetgeen met de term eigenheid wordt aangeduid. Een voorbeeld waarin met eigenheid nu juist niet goed is omgesprongen, is de versnellingshandle van een auto: het behoort niet tot het eigene van het rijden om van de ene naar de andere versnelling over te schakelen, het is alleen nodig omdat de motor een beperkt vermogensbereik heeft. Een auto-matische versnellingsbak of een variabele transmissie beantwoordt beter aan de eis van 'eigenheid' in de architectuur van de auto.
Een ander voorbeeld m.b.t. de eigenheid is de getalrepresentatie in computers, en wel in het bijzonder de unieke representatie van het getal nul in het 'two's-complement', hetgeen overeenkomt met de definitie en het gebruik in de wis-kunde, waar het getal nul geen teken heeft.Zowel de voorstelling van het getal nul in het 'one's-cornplement' als die met teken en absolute waarde, hebben twee no-taties: een positieve en een negatieve. Daarom moet in deze beide getalrepresenta-ties door het voorschrijven van aparte regels, zoals 'plus nul is gelijk aan min nul', worden voorkomen dat wordt afgeweken van de normale mathematische eigen-schappen, hetgeen niet bijdraagt tot de oplossing van het probleem van de gebruiker.
Ie
.e
In,
1.5.4.
Spaarzaamheid
Eén van de gevolgen van die eigenheid is dat een goede architectuur ook zuinig is,in die zin, dat functies die niet eigen zijn aan het systeem ook niet behoren voor te komen. Zelfs al kan een bepaalde functie zonder extra
kost en worden aangebracht, dan nog moet de ontwerper zich afvragen of die functie eigen is aan het concept van die computer. In elke ontwerpfase komt er een moment dat men geneigd is om 'toeters en bellen' aan het systeem toe te voegen, zeker als een zodanig niveau is bereikt dat de ont-werpers onvoldoende gebruikerservaring hebben om het nut daarvan af te wegen.
Een voorbeeld daarvan zou zijn: het toevoegen van een instructie om 'character strings' met elkaar te vermenigvuldigen,met als argumentatie dat 'charcter strings' ook wel de voorstelling van getallen kunnen zijn. Daarbij het argument buiten be-schouwing latend,dat het produkt van twee tekstwoorden ongedefinieerd is.
1.5
.5.
Volledigheid
Wanneer alle functies van een gegeven klasse beschikbaar worden gesteld in een architectuur, noemen we die architectuur volledig.
Heeft een computer bijv. een voorziening voor het vermenigvuldigen van twee getallen, dan ligt het voor de hand dat ook in de inverse operatie, de deling, is voorzien; kent de machine instructies voor het optellen, vermenig-vuldigen en delen van getallen met een vaste komma, en bijvoorbeeld een instructie voor het optellen van twee floating-pointgetallen, dan mag men verwachten dat ook voor de vermenigvuldiging en deling van getallen met drijvende komma een instructie is aangebracht.
Het beginsel van de volledigheid mag echter het principe van de spaarzaam
-Operand 1 0 1 0 Operand 2 0 0 1 0 SETZ 0 0 0 0 1 AND 0 0 0 1 2 ANDCA 0 0 1 0 3 SETM 0 0 1 1 4 ANDCM 0 1 0 0 5 SETA 0 1 0 1 6 XOR 0 1 1 0 7 lOR 0 1 1 1 J 8 ANDCB 1 0 0 0 9 EQV 1 0 0 1 10 SETCA 1 0 1 0 11 ORCA 1 0 1 1 12 SETCM 1 1 0 0 130RCM 1 1 0 1 140RCB 1 1 1 0 15 SETO 1 1 1 1 Tabel 1.5.1. Logische functies in DEC Systern 10.
22
heid geen geweld aandoen. Een voorbeeld hiervan vormen de logische operatoren (instructies) van de DEC System 10 (zie tabel 1.5.1 [DEC 69j).
Alle 16 logische functies zijn hierin voorzien, hetgeen uit het standpunt van vol-ledigheid goed is. Zou men de frequentie van het gebruik gaan bezien, dan zou blijken dat de instructies AND, OR en XOR het meest voorkomen. Het weglaten van de resterende 13 logische operaties had een besparing opgeleverd in de ruimte voor de opdrachtencode, en zou gerechtvaardigd zijn geweest omdat deze 13 functies m.b.V. de drie andere te realiseren zijn.
Uit het voorgaande bleek duidelijk dat de volledigheid niet ten koste mag gaan van de spaarzaamheid. Volledigheid kan op zich dus leiden tot verspilling van ruimte in coderingen en derhalve tot overmatige geheugenomvang.
Verspilling kan worden tegengegaan door te zoeken naar een aantal orthogonale functies die het hele scala van gewenste functies mogelijk maken. Een voorbeeld hiervan buiten de sfeer van computers is de schroevedraaier-set die bestaat uit een hele reeks insteekmodulen en een paar verschillende handvatten waarin die modu-len passen: op die manier is heel wat materiaal bespaard om toch een complete set schroevedraaiers te realiseren.
1.5.6.
Evenwichtigheid
Evenwichtigheid houdt in dat de opzet van de architectuur in termen van de ver-deling van de functies in overeenstemming is met het geplande gebruik. Zo zou de toevoeging van complexe getallen met de daarbij behorende operaties aan een architectuur die hoofdzakelijk tekstverwerkingstoepassingen moet verzorgen, als onevenwichtig beschouwd moeten worden.Zeer zeker als dit ten koste zou gaan van instructies die met 'character strings' manipuleren.
1.5.7.
Transparantie
Een goede architectuur is transparant: de gebruiker wordt niet gehinderd door implementatievormen of eigenschappen van bepaalde technologieën. Dat is te vergelijken met het glas van een raam, dat de behaaglijkheid in huis bewaart, maar het uitzicht niet hoeft te belemmeren.
De gebruiker die een interlocaal telefoongesprek zal voeren, moet niet belast worden met de keuze van alle knooppunt-centrales en de verbindingen daartussen: het enige wat die gebruiker wil, is aangeven d.m.v, een abonnee-nummer met wie hij/zij spreken wil.
Het transparantie-kenmerk wordt ook vaak aangeduid als 'Separation of Concerns' of als 'Information Hiding', zie Parnas [Pa 75].
1.5.8.
Algemeenheid
De eigenschap om bepaalde functies voor een aantal doeleinden te gebruiken wordt aangeduid met het begrip algemeenheid: de ontwerper is er zich van bewust dat gebruikers creatiever zijn dan hij zich kan voorstellen en dat de toepassingen anders zijn dan hij nu verwacht.Daarom moet een ontwerper het gebruik van een bepaalde functie niet beperken tot datgene wat hij er zelf van nodig acht, tenzij dat in een brede kring aanvaard is.
Als voorbeeld hiervan kunnen we de invoer-en uitvoerstructuur bekijken. Oorspron-kelijk werden computers ontworpen voor het verrichten van rekenwerk en waren
et
van
s'
:t
on-in- en uitvoer uitsluitend bedoeld om met de destijds bekende randapparatuur (zo-als ponskaartlezers, magneetbanden en printers) gegevens uit te wisselen. Al heel snel zagen sommige mensen kans diezelfde gegevensuitwisseling te gebruiken om met die computer bepaalde processen te besturen, zij het dat dit met de nodige aanpassingen gepaard moest gaan. Achteraf gezien kan men dus (althans voor som-mige computers) zeggen, dat de invoer-Juitvoerstructuurte weinig algemeen was. Hedendaagse computersystemen hebben doorgaans dan ook een veel algemenere
ilo-structuur, waardoor een veelheid aan toepassingen en koppelingen mogelijk is.
1.5.9. Openheid
Een goede architectuur is tenslotte ook open: als beveiliging tegen toekomstige ontwikkelingen is het verstandig reserves in te bouwen, bijvoorbeeld in operatie-code, in adresruimte, etc.
Eén van de meest gehoorde beperkingen van de PDP-ll van DEC is, dat de adres-ruimte beperkt is tot 32k woorden, hetgeen in de maximale omvang van pro
-gramma- en data-modulen naar voren komt.Toen de eerste machine van deze familie werd geïntroduceerd, was men voor deze soort machines gewend te denken aan een geheugenomvang van 8 k of 16 k woorden. Het ontwerp liet dus ruimte open voor de verwachte groei in geheugenomvang. De VAX-ll/780 van dezelfde firma heeft nu een adres bereik van 4 Gigabytes.
Openheid getuigt van de bescheidenheid van de ontwerper, omdat deze daarmede te kennen geeft niet elke gebruikersomgeving nu en in de toekomst te kennen.
1.6. Architectuur stromingen
Zoals in vele takken van wetenschap, zijn ook op het gebied van de computer
-architectuur oplossingen van verschillende soorten mogelijk (zie Van de Goor [Go 7S
D.
Globaal kan men spreken van een viertal soorten architectuur:• programmatuur georiënteerd • apparatuur georiënteerd • neutraal
• gericht op speciale toepassingen.
Deze classificatie is gemaakt op grond van de relaties met de programmatuur en de '
apparatuur, en zal in het volgende worden uitgewerkt.
1.6.1.
Programma tu ur
-georièn
teerde architecturen
In deze architecturen worden veel gebruikte functies van één of meer hoger niveau programmeertalen, zoals ALGOL 60, vrijwel direct ondersteund.Het voordeel van deze architecturen is, dat het compileren, inclusief het genereren van een 'optimale' code, betrekkelijk eenvoudig is voor de klasse talen die door zo'n architectuur worden ondersteund. Recursie wordt bijvoorbeeld voor ALGOL-achtige talen auto-matisch verzorgd. Ook het behandelen van arrays wordt vaak zeer uitgebreid onder-steund, door bijvoorbeeld het automatisch controleren of de index van een array wel binnen de gedefinieerde grenzen ligt.
Enkele representatieve voorbeelden zijn: de Burroughs B1700, B6700, B7700 [Bur 69], de Manchester University MU-S [Mu 77] en de ICL-2900 serie, zie Buckle [Bu 78]. Naast taal-georiënteerde architecturen is er momenteel een stroming waarbij 'opera-ting system' concepten door de architectuur ondersteund worden. De Intel IAPX 432 [Int 81] is een uitstekend voorbeeld hiervan.
24
1.6.2. A
pparatuur-georiënteerde archit
ectuur
Dezesoort architectuur is meest alhelemaal gericht op het bereike nvan een hoge doorvoersnelheid:de apparatuur bepaalt de executie-sne lheid en daaro m sluit de architectuur daar zeer nauw bij aan teneinde verliezen te voorko men. De CDC STAR, waarvan het eerste exemplaar in 1974 aan het Lawren ce Liverm ore Laboratory in de USA werd afgeleverd, kan 100 miljoen bewerk ingen (optellen, vermenigvuldigen) per seconde op getallen met drijvende komma uitvoe ren. Om die snelheden te halen worden in de uitrusting verschill en de voorzieninge ngetroffen die hun weerslag hebben gevonden in de architectuur:
• door het toepassen van 'int erleaving' wordt de 'bandb ree dte' vanhet geheugen vergroot;
• toepassen van 'pipe lining' in de arithmetische eenhedengeeft een aanzien lijke snelheidsverhoging;
• een extra verhoging van de snelheid wordt verkregen door een aantal van deze arithmetische eenheden parallel te laten werken;
• de input en output wordt door afzonderlijke computers geregeld;
• gebruik van 'look-ahead' technieken maakt optimaal gebruik van dezeeenheden mogelijk;
• de instructieset is betrekkelijk eenvoudig en heeft zeer weinig variabiliteit in lengte, aantal operanden, en dergelijke, om snelle decodering mogelijk te maken. Of de programma's voor deze machines gemakkelijk gecom pileerd kunnenworde n is van ondergeschikt belang, omdat deze machines bedoeld zijn om 'produkt ie' te doen van grote hoeveelheden rekenwerk, waarbij het merendeel der programm a's veelvuldig wordt gedraaid met steeds wisselende data.
Oudere talen, zoals FORTRAN ,kunnen een misaanpassin g veroorzaken omdat de architectuur op sommige punten een hoger niveau heeft dan de programmeer taal. Het gebruik van vectoroperaties bijvoorbeeld is alleen mogelijk door de compiler deze te laten extraheren uit een aantal regels FORTRAN en/of deze taal uit te breiden met vector operaties,zoals APL deze van nature heeft.
Enkele apparatuur-georiënteerde architecturen zijn: • CDC Cyber 205 [Ka 79]
vector-georiënteerd voor wetenschappelijke en com merc iële toepassingen ; • Texas Instruments Advanced Scientific Computer [Wa 72]
vector georiënteerd voor wetenschappelijke en com me rciële toepassingen ; • ILLIAC IV (experimentele machine) [Ba 69]
array computer.
1.6.3. Neutraal
De neutrale architecturen streven een evenwicht na tussen de programmatuur- en de apparatuurgerichte architecturen. De argumenten voor deze aanpak liggen in het tijdsafhankelijke karakter van de programmatuur en de apparatuur.
• Programmatuur
Eriseen snelle ontwikkeling op het gebied van de programmeertalen en be-sturingsprogrammatuur,zowel wat concepten als toepassingsgebieden bet reft (bijv. Fortran, Algol 60, Algol 68, PL/l, Pascal, Concurrent-Pascal, Modula, ADA, CLU en Alphard).
'en
n
m,
Op tim aliserin g van de architectuur voor een enkele taal of groep van talen kan een minder efficiënte implementatie van nieuwe talen tot gevolg hebben. • Apparatuur
De moderne technologieën hebben tot resultaat gehad, dat de dichtheid van sch ake l- en geheugenelementen zeer sterk is toegenomen,wat o.a. tot uiting ko mt in de sterke daling van dekosten van de hardware. Dit maakt het op-voeren van de snelheid, o.a. door activiteiten parallel te doen uitvoeren, eco-nomisch verantwoord.
Enk ele voorbeelden van neutrale architecturen zijn de IBM/360 ,de DEC PDP-ll, VAX-ll [DEC77] en Univac 1100 series.
Architecturen in deze klasse moeten gezien worden als zijnde geconcipiëerd op een bepaald moment in het ontwikkelingsproces van programmatuur en apparatuur met inachtneming van een (beperkte) toekomstprognose. Latere ontwikkelingen worden in volgende generaties verwerkt door een uitbreiding van de architectuur, Voorzover dit binnen dat kader mogelijk is. Een nieuwe serie wordt geïntroduceerd wanneer de oude architectuur als te beperkend wordt ervaren (het adresserings-bereik en -mechanisme is een klassiek voorbeeld hiervan).
1.6.4. Sp
eciale
toepassing
en
Gebieden met uitzonderlijk hoge snelheidseisen (t.g.v.real-time bijspraakverwerking bijvoorbeeld) of met strikte kosteneisen (bijv. het gebruik van digitale filters bij modems) kunnen speciale architecturen vereisen.
De bestaansredenen voor een dergelijke architectuur zijn vaak tweeledig; • Snelheid
Door een probleemgerichte architectuur en implementatie kan een belangrijke snelheidswinst behaald worden in vergelijking met een 'general purpose' aanpak. Digitale filteralgoritmen bijvoorbeeld, zijn vaak relatief klein en hebben weinig data gelijktijdig nodig. Dit stelt dus weinig eisen aan de adresgrootte van de programma- en dataruimten.
• Kostenbesparing
Vanwege het speciale karakter van een toepassing zijn kostbare functies (zoals bijvoorbeeld 1/0, geheugen management, floating point) niet of alleen in een sterk vereenvoudigde vorm vereist. Dit geeft een kostenbesparing t.O.V. een general purpose architectuur.
Door de enorme kostenreductie van de hardware en de toenemende automatisering van het LSI ontwerp- en fabricageproces is een sterke groei van speciale architec-turen te verwachten. Een voorbeeld hiervan is de Delft Parallel Processor (DPP), (zie [Si84]).
1.7. Invloed van programmeertalen op de architectuur en omgekeerd
De ontwikkelingen van de hoger niveau programmeertalen en de computerarchi-tectuur beïnvloeden elkaar zeer sterk. Traditionele talen die hun invloed op de architectuur hebben doen gelden, zijn bijvoorbeeld Cobol, Fortran en Algol. De laatste twee zijn sterk procedure-georiënteerd, d.W.Z. dat het accent ligt op algoritmen i.p.v. datastructuren.Dit heeft geleid tot architecturen met de volgende eigenschappen:
26
• Veel operaties (instructies)
Dit vanwege de oriëntatie van talen zoals Fortran en Algol op berekeningen. • Weinig datastructuren
Het array is vrijwel de enige structuur die door bestaande architecturen onder-steund wordt. Dit gebeurt in de vorm van indicering (d.w.z. element-selectie en 'bou nds checking ' op de indicesvia descriptors en dope vectoren).We komen daar later nog uitvoerig op terug.
• Weinigparallellisme
De bestaande talen zijn sequentieel van aard en laten, in het algemeen, alleen operaties op elementen toe, i.p.v, op structuren (dit geldt niet voor APL, welke taal vector-en matrix-operaties kent). Dit geeft weinig gelegenheid tot het uitbuiten van goedkope hardware ter vergroting van de executiesnelheid. • Weinigchecking
Met het toenemen van de grootte van pro gramma's en de algemene trend dat de maatschap pij afhankelijker van de computer wordt, is de eis van betrouw-baarheid toegen omen. Dit heeft zijn weerslag op de ontwikkeling van de talen. PascalenADA zijn nieuwe talen die het schrijven van betrouwbare programma's vergemakkelijken en bevorderen.
Figuur 1.7.1. toont een Pascal programma waarin user-defined datatypen en checking voorkomen. Naast de normale datatypen zoals integer, character, real,
enz ., welke gepredefinieerd zijn, laat de taal ook de introductie van nieuwe, 'user defined' datatypen toe. Het datatype DAG, in figuur 1.7.1, is zo'n nieuw geïntro-duceerd type en gedefinieerd als zijnde de dagen van de week. Het is hier om-schreven alseen zgn. geënumereerd data -ty pe, d.W.Z. dat in de definitie de gehele verzameling van mogelijke waar den is opgenomen .
De typenWERK Den DATM zijn su bra ngesvan reeds gedefinieerde typen, resp. van de typen DAG en INTEGER (gepre definieerd). De variabelen Dl en D2 zijn gedeclareerd als type DAG, de variabele DAT als type DATM. Bij de 'assignrnent statements' aan D2 en DAT vindt 'checkin g' plaats om te garanderen dat de be-reken de waar den voor D2 en DAT voldoen aan de gestelde eisen (bijv.:waarde voor DAT moet voldoen aan: 1~ DAT~ 31).
progral'QVoorbeeld (input, output ); const PI
=
3.14;type DAG= (ZO, MA,DI, WO, DO, VR, ZA); WERKD= MA..VR;
DATM = 1..31; var I,J: int eger;
01,02: DAG; DAT:DATM: begin 02:=suce(Dll ; DAT:
=
1.7 +J; for Dl:= MA10 VR do ende
L' S
Ontwikkelingen op het gebied van programmeertalen laten zich indelen in twee
stro mingen: de interpretatieve talen en de te compileren talen. Daarom ishet
nu ttig om apart aandacht te besteden aan de talen die van nature interpretatief
zijn, en talen die zich voornamelijk voor compilatie lenen.
1.7.1.
In t
erp
r
e
tati
eve
tal
en
In het volgende hoofdstuk zullen we uitvoerig aandacht besteden aan het begrip
'interpreteren ' , maar nu volstaan we met het stellen van het feit, dat interpretatieve
talen interactiefvan karakter zijn, hetgeen er toe heeft geleid, dat deze talen, zoals BASIC en APL, een grote vlucht genomen hebben door het gebruik van terminals
en door de komst van 'personal computers'. Sommige van deze talen, bijvoorbeeld
APL, laten variabelen toe waarbij het datatype en de datastructuur dynamisch zijn,
d.w.z. dat ze ten tijde van de executie veranderen kunnen.
Tevens vereisen deze talen minder declaraties waardoor checking voornamelijk ten tijde van de executie (i.p.v, tijdens de compilatie) plaatsvindt. Dit laatste gaat ten koste van de executietijd en geeft geen bewijs van programmacorrectheid in geval van data-afhankelijkheid.
1.7.2. Compilatie-talen
De te compileren talen hebben een langere historie dan de interpretatieve tàlen
(Fort ran bestaat al sedert 1954). Dat komt omdat het compilatie-proces een
effi-ciënt er gebruik van de machine mogelijk maakt.
Program meert alen van deze soort hebben een ontwikkeling doorgemaakt die het gebruik van procedures sterk op de voorgrond bracht. Bezien we bijvoorbeeld de
tab el 4.1.l.uit hoofdstuk 4,dan valt daar op, dat het aantal 'procedure-ealls' bij Pascal-programma's vele malen groteris dan bij Fortran-programma's. De belang-rijkste reden daarvoor is, dat gestructureerd en modulair programmeren als methode
van werken sterk werd bevorderd, omdat door die methode de programma's over-zichtelijker - en dus begrijpelijker - maar ook beter wijzigbaar worden.Het af-schaffen of het sterk reduceren van de mogelijkheden van 'GOTO-statements' is
één van de karaktertrekken van de nieuwere talen.
Taalconstructies als 'if-then-else', 'do-while' ,'do-until', enz. zijn geïntroduceerd om
de structuur van een programma overzichtelijk te maken en de blokstructuur biedt mogelijkheden voor beveiliging van data, enzovoorts.
Een tweede aspect van de ontwikkelingis dat behalve de programma's ook de data gestructureerd werd. Hierdoor krijgt de data ook weer de conceptuelevorm zoals de gebruiker die bedoelt. Om nog even op het voorbeeld van figuur 1.7.1 terug te komen: het feit dat een data-type DAG wordt gedeclareerd als een 'enumerated type' is een bescherming tegen toekenning van verkeerde waarden aan zo'n variabele. Als we een dag van de week willen toekennen aan een variabele, dan declareren we die variabele te zijn van het type DAG en indien nu op één of andere wijze JANUARI aan deze variabele zou worden toegekend, kan de compiler checken, dat JANUARI niet tot het data-type behoort.
Dit vrijwaart de programmeur van het telkens mentaal vertalen van een interne programma-representatie naar en van de externe gebruikers-representatie. De aan-wezigheid van een groot aantal.standaard data-structuren, zoals array,record, set,
applicatie-28
afhankelijke data-structuren is een belangrijke bijdrage van de moderne talen als Pascal, ADA, enz.
Een recente ontwikkeling op het terrein van data-typen en operaties, is de komst van de abstracte data-typen, die we kunnen kenschetsen als 'user-defined', maar waarbij ook de operaties op die datatypen moeten (c.q. kunnen) worden gedefi-nieerd. Bijvoorbeeld in het geval van figuur 1.7.1 zou, als DAG een abstract data-type was, de vermenigvuldig- en deeloperatie niet worden gedefinieerd en aan de optelling bepaalde begrenzingen opgelegd worden.
Het gebruik van user-defined en abstracte data-typen, laat een grote mate van 'checking' toe welke de correctheid van programma's bevordert.
1.8. Architectuur een uitdaging
De ontwikkeling van de computerarchitectuur speelt zich af in een spanningsveld van krachten waarvan sommige remmend en andere stimulerend werken.
1
.8.1.
Economisch aspect
Figuur 1.8.1 geeft een beeld van het aantal geïnstalleerde computers. Het grote aantal geïnstalleerde computers is er de oorzaak van, dat er een eis voor continu-iteit wordt gesteld, zowel van de kant van de leverancier als van de zijde van de gebruikers, omdat zowel de leverancier als de gebruiker aanzienlijke investeringen hebben gedaan, zowel in tijd als in geld gemeten, voor opleidingen (know-how), voor apparatuur en voor programmatuur.
De leverancier heeft een ontwikkelingsinvestering gedaan,heeft een productielijn opgezet, meet-en testapparatuur geïnstalleerd, randapparatuur vervaardigd of ge-kocht, enz., zodat deze er belang bij heeft zo lang mogelijk dezelfde producten
o o o x -;;; 1200 ~
'"
"0 ~ ~ ~c 900 :ä) C> mini computers 600 300 main frames(grote computers)
'8 1 '80 , '79 "75 O+ - ----,- - - r - - - t - - . '74 '16 '77 '78
te blijven voeren. Bovendien is er meestal een 'operating system' ontwikkeld, dat
vele tientallenmanjaren aan ontwikkeling heeft gekost. Verder werden compilers
voor hogeretalen ontwikkeld, enz.
Degebruiker heeft soms grote hoeveelheden dure randapparatuur aangeschaft, zo-dat bij vervanging van een CVE het liefst een compatibele machine wordt aange-sch af t. Verder heeft de gebruiker meestal ook know-howopgebouwd omtrent het
operati ng system en compilers, en bestaat er een grote hoeveelheid applicatie-. progra mmat uur .Aangezien daarbij vaak specifieke eigenschappen van de hardware
worden betrokken(denk aan routines in assembler-code), is dat ook vaak een reden waarom de gebruiker als vervanger een compatibel systeem wil hebben.
Het zal duidelijk zijn, dat de vraag naar compatibiliteit met een verouderd systeem een remmendekracht is op het invoeren van nieuwe ideeën en technieken.
1
.8.2.
O
ntw ikke ling
e
lek tronische bouwstenen
Het tijdperk van de 'Very Large Scale Integration' is reeds aangebroken. De grote dichtheden en lage kosten van logische schakelingen zijn voorwaarden voor de ver-schuiving van functies uit de programmatuurnaar de apparatuur. Parallellisme, multiprocessing, enz. zijn economisch haalbare implementatie-alternatieven geworden. Enkele archi tecturen die hiervan reeds gebruik gemaakt hebben, zijn:
• Manchester University MU-S [MU 77)
Dearchit ectu u r hiervanis zodanig dat berekening van de adressen der operanden
en ophalen C.q.wegschrijven van de operanden d.m.v. een speciale Operand
Fet ch Unit verricht wordt, die zo veel mogelijk onafhankelijk werkt van de rest van de machine .
• ILLIAC IV
De architectuur van deze machine is gebaseerd op parallel-processing.
Deze computer bestaat uit een matrix van 64 processoren, die alle dezelfde in -structie in een bepaalde tijdseenheid afwerken (Single Instruction Multiple Data). Het goedkoper worden van digitale bouwstenen, het ontwikkelen van nieuwe techno-logieën om grotere dichtheden en grotere snelheden te bereiken, zijn krachten die de ontwikkeling van moderne architecturen sterk kunnen stimuleren.
De snelle opeenvolging van aankondigingen van nieuwe architecturen door de half-geleiderfabrikanten zoals Motorola, National Semiconductors, Intel en Zilog geeft hiervan een indicatie. Deze bedrijven produceren 'single-chip' microcomputers waar-bij de architectuur sterk bepaald wordt door de op dat moment beschikbare chip -technologie.
1.8.3. Hog
er
niveau talen
De ontwikkeling van hoger niveau talen is reeds aan de orde geweest. Het betrouw-baarheidsaspect zou in toekomstige architecturen met behulp van speciale 'checking'-logica ondersteund kunnen worden.
Parallelliteit, of een mechanisme dat gemakkelijk problemen in een aantal (semijon-afhankelijke subproblemen opsplitst, is vrijwel niet aanwezig. De diversiteit van stromingen (bijvoorbeeld compileren en interpreteren) en de steeds verdergaande
on t wik keling is er tevens de oorzaak van dat een enkele architectuur niet optimaal kan zijn en blijven.
30
Concluderend kan worden gesteld dat het gebied van de computer-architectuur nog vele uitdagingen biedt. De grootste uitdaging moet worden gezien in de defi-nitie van nieuwe architecturen waarin de mogelijkheden van VLSI optimaal gebruikt kunnen worden.
ct
2. Machineniveaus
In dit hoofdstuk willen we nagaan van welke aard de machine-instructieskunnen zijn die een ontwerper in zijn systeem gaat aanbrengen. Zoals in het vorige hoofd -stuk is uiteengezet, geeft de architectuur een functionele beschrijving van een com-putersysteem, zoals dat door de gebruiker ervaren wordt. De vraag rijst dan wie 'de gebruiker' is. Is dat degene die een applicatieprogramma gebruikt (bijvoorbeeld een ontwerper van een vliegtuig die gebruik maakt van een CAD/CAM-pakket),of is dat de programmeur van die applicatie, danwel de systeemprogrammeur? Het stel -len van deze vraag geeft meteen een aanknopingspunt voor het antwoord: in alle gevallen kan men van een gebruiker spreken, alleen het taalniveau waarop men het systeem benadert, verschilt.
We zullen daarom eerst nagaan welke taalniveaus er zoal in een computersysteem zijn te onderscheiden, hoe men van het ene taalniveau naar het andere kan over-gaan en op welk niveau een hardware-implementatie van de taal kan wordengekozen. Tenslotte wordt in dit hoo fdst uk bezien welke eisen de overdraagbaarheid van s oft-ware van het ene naar het andere systeem stelt aan de hardware-implementatie en aan die software zelf.
2.1. Verschillende taalniveaus in bestaande machines
Bij het beslissen welke instructies samen de 'machinetaal' vormen, dient de ontwer -per een evenwicht te vinden tussen enerzijds de verlangde '-performance' in het doel waarvoor de machine wordt ontworpen en anderzijds de complexiteit van de machi -ne en de totale kosten van de hardware en de software.Grote performance zal in het algemeen tenderen naar krachtige instructies, die echter veel elektronische scha -kelingen vereisen en dus de kosten verhogen. Een algemeen toepasbaar systeem (general purpose) zal minder speciale instructies toestaan dan een 'special purpose' systeem.
Tot op heden resulteert dit afwegingsproces voor 'gen era1 purpose' computers mees -tal in eenvoudige machine-talen, die voor de mens echter zeer moeizaam te gebruiken zijn.
Hoger-ni veautaal(PASCA L) A:=B+C;
Assembleert aal (MACRO-l 1l
MOV B. Rl AOO C.Rl
MOV Rl .A Machin et aal {POP·l 1)
Iym b o lisch 1000: MOV@#2002 .Rl AOO@# 2004 .Rl MOV Rl.@#2000 2000 : A 2002: B 2004: C
Figuur 2.1.1. Verschillende programma-niveaus.
in birs 0001 011 111 000 001 ססoo011 111 0 10 010 0110011 111 000 001 ססoo011111 010 100 0001000 001011111 0000 011111010000
32
Talen als PL/l, ALGOL, PASCAL, ADA, enz. zijn juist ontworpen om de gebruiker te vrijwaren van allerlei moeizame details en deze leveren in het algemeen zeer goed leesbare programma's op.
In figuur 2.1.1 is een voorbeeld gegeven van een eenvoudige bewerking:het toe-kennen van de som van twee getallen aan een variabele. Dit is geprogrammeerd in achtereenvolgens een hoger-niveau taal (PASCAL), een assemblertaal (MACRO-l 1) en een machinetaal (PDP-ll).
Uit dit gegeven voorbeeld blijkt dat de programmeur, wanneer dat maar enigszins mogelijk is, zijn of haar programma zal verkiezen te schrijven in een hoger-niveau taal. Is dit om de een of andere reden niet mogelijk, dan zal de voorkeur toch nog worden gegeven aan de assembleertaal in plaats van aan de machinetaal.
Er is echter nog een taalniveau, dat zich bevindt tussen assembleertaal en machine-taal: het niveau van het 'operating system', waar zaken als invoer/uitvoer, geheugen-beheer, regelingen voor het toelaten van een aantal gebruikers tegelijkertijd, enzo-voorts worden afgehandeld.Dit niveau kan worden aangeduid als 'hybride', omdat daarin twee groepen instructies bestaan, nl. die van de machinetaal en 'bijzondere' instructies, Deze groepen worden op verschillende manieren behandeld, maar hier-over straks meer.
In de machines die tot aan het begin van de 60-er jaren werden gemaakt, werden de machine-instructies rechtstreeks in 'hardware' gerealiseerd. In 1953 had prof. Wilkes echter de microprogrammering ten tonele gevoerd [Wi 53], waarbij elke instructie van de machinetaal werd omgezet in een aantal microinstructies, die tot in de klein-ste details de besturingssignalen specificeren voor de elektronische bouwklein-stenen. De verzameling microinstructies kan ook weer als een taal worden aangemerkt. Dit geheel is afgebeeld in figuur 2.1.2.
Het gebied aangeduid met 'apparatuur' bestaat uit de micro-programmering en de hardware. De rest van het systeem wordt de 'programmatuur' genoemd. Computer-architectuur is de beschrijving van het grensvlak tussen de apparatuur en de prograrr.-matuur.
Concluderend kunnen we vaststellen dat we thans in de gangbare machines vijf taalniveaus kunnen onderscheiden, hetgeen in figuur 2.l.2.schematisch wordt aan-geduid door Ll-L5 (L van Language).op de diverse grensvlakken. Zie voor een uitvoerige behandeling van de verschillende niveaus in een computersysteem: Tanenbaum [Ta 76].
applicatie {
program-matuur
systeem
archit ect uu r-+
appara- { tuur
administratieve systemen, CAD/CAM-pakket,
ICES-STRUDL,enzovoorts
hoger data data
niveau commu- base talen
nicatie systeem assembler
bestu ri ngspro gra m mat u u r .oY.{:;::,::;i.•-'YkP:~~.:.::•..,:::'-'}:'W~·::W:·;;';:.. ....y).:::...:.~~.~;::";%"'':;::.:::<{~';;::::$:;:'
micro pro grammering
hardware L5 L4 L3 L2 L1
:r d Ie ss 1-
rr.-2.2.
Overgang van een hoger naar een lager taalniveau
In de voorgaande paragraaf werd aangetoond, dat de programmeur er in het algemeen de voorkeur aan geeft in een taal te programmeren die van een hoger niveau is dan de machinetaal,zeker hoger dan de micro-programmering. De vraag doet zich daarbij
vo or , hoe een programma dat in zo'n hoger-niveau taal is geschreven, kan worden verwerkt door de machine met een laag-niveau machinetaal. Met andere woorden: hoe wordt een programma van de ene taal omgezet in een andere taal? Bij het be-antwoorden van deze vraag zullen we alleen nagaan hoe we van een hoger niveau
naar een lager niveau kunnen komen, in de omgekeerde richting is dat in het alge-meen niet mogelijk. En daarmee hebben we meteen een argument in handen om eenarchit ectu u r altijd op een zo hoog mogelijk niveau te definiëren, omdat op een lager niveau niet meer is te onderkennen, of althans heel moeilijk, welke bewerking door de programmeur is bedoeld. Dit is eenvoudig in te zien aan de hand van het voorbeeld in figuur 2.1.1. Bezien we het laagste taalniveau, dan is aan de afzonder-lijke instru ct ies niet meer te zien, dat ze deel uitmaken van het hoger-niveau state-ment. Dit wordt wel aangeduid als 'het verlies van semantiek'.
Er zijn drie manieren om van het ene taalniveau naar het andere te geraken. Deze zijn:
• vertalen (compileren C.q. assembleren);
• interpreteren;
• invoeren van een tussentaal (mengvorm van vertalen en interpreteren).
2.2.1. V
ertalen
Bij het vertalen van een programma Ph in de taal Lh naar een taal LQ die de machine kan verwerken, wordt van het programma Ph een nieuw programma PQ in LQ ge-maakt, door elke instructie uit het oorspronkelijke programma Ph te vervangen door een reeks instructies uit LQ die gezamenlijk dezelfde uitwerking hebben als de vervangen instructies uit het oorspronkelijke programma Ph.Dit gebeurt door een programma (meestal in LQ geschreven, maar soms ook in Lh) dat het oorspron-kelijke programma als input-data accepteert en dat het 'objectprogramma' als output-data genereert. Dit objectprogramma wordt daarna in de machine geladen om te worden uitgevoerd (zie figuur,2.2 .1). Tijdens het uitvoeren van het programma PQ
is het equivalente programma Ph niet meer nodig. Tevens verricht de vertaler nog een aantal andere functies, namelijk controle-functies en code-optimalisatie.
