Arvutid II teooria eksam (0)

Sardsüsteem:

• Peavad olema efektiivsed
  

 Loodud mingi spetsiifilise ülesande jaoks. Teadmine
süsteemi käitumisest süsteemi loomise ajal aitab vähendada
süsteemi loomisele kuluvaid ressursse ning suurendada
stabiilsust
 Spetsiaalne kasutajaliides
(mitte aga hiir , klaviatuur ja ekraan )
Mitmed sardsüsteemid peavad vastama reaalaja nõudmistele
• Reaalaja süsteem peab reageerima välistele stiimulitele mingi
keskkonna poolt etteantud ajaühiku jooksul
• Reaalajasüsteemides on õiged vastused, mis hilinevad, valed
vastused.
• „Reaalaja piirangut nimetatakse tugevaks, kui selle mitte
saavutamine viib katastroofini” katastroofini
• Kõiki ülejäänud reaalaja piiranguid nimetatakse pehmeteks.
Sardtarkvara
 Annab tootele olemuse
 Sama platvormi pealt erinevate toodete loomine
 Võib muuta väga hilise hetkeni
 Mitmed tootjad kasutavad sama riistvara
 Protsessorid on odavamad kui ASICud
 Riistvara loomine on väga kallis!
30% dimensionaalne vähenemine:
 Loogikalülituse viide väheneb 30% (töösagedus tõuseb 43%)
 Kahekordistub transistoride tihedus
 Ühe siirde energia väheneb 65% (50% võimustarbe
vähenemine 43% kiiruse tõusu juures)
disainivoog
 Arhitektuuri valik
 Ressurssidele sidumine
( mapping )
 Planeerimine
(scheduling)
 Palju simuleerimist ja
emuleerimist
 Design space
Exploration
Riistvara/ tarkvara
koosdisain
 Partitsioneerimine
 Tarkvara
genereerimine
 Riistvara süntees
 Integreerimine
 Prototüüpimine
Spetsifikatsioonid võivad olla:
 Mitteformaalsed (loomulikus keeles)
 Detailsemad ja ühetähenduslikumad, kasutades
spetsifikatsioonikeeli
 Spetsifikatsioonikeeled peavad:
 Olema võimelised hästi väljendama peamisi süsteem
omadusi ja erinevaid aspekte sisutihedal ja selgel kujul
 Sobima hästi nõuete täitmise kontrolliks ja
implementatsioonide sünteesiks (soovitavalt automaatselt)
 Alati tuleb valida see keel, mis antud süsteemi jaoks
sobiks kõige paremini!
 Spetsifikatsioonikeeled võivad olla
 Graafilised
 Tekstilised
 Spetsifikatsioonikeeled võivad olla
p
 Tavalised programmeerimiskeeled (C, C++)
 Riistvara kirjelduskeeled ( VHDL , Verilog)
 Spetsiaalsed keeled, mida kasutatakse erinevates
valdkondades süsteemide spetsifitseerimiseks. Tihti
põhinevad need mingil arvutusmudelil (model of
computation)
 Mida me tahame sardsüsteemi spetsifikatsiooniga
peale hakata?
 Valideerida süsteemi kirjeldust, et kontrollida, kas
funktsionaalsus vastab soovitule ja et vajadused on
kirjeldatud korrektselt Selleks kasutatakse:
korrektselt. • Formaalset verifitseerimist
• Simuleerimist
 Et sünteesida efektiivseid rakendusi
81
Formaalsed mudelid
 Me sooviksime, et spetsifitseerimiskeeled oleks hästi
defineeritud semantikaga  spetsifikatsioonid
peaksid olema ühetähenduslikud
 Semantika on reeglite kogu, mis seob tähenduse
(interpretatsiooni) süntaktiliste keelekonstruktsioonidega
(sümbolite kombinatsiooniga)
 Semantika põhineb aluseks oleval arvutusmudelil
Nimetatud mudel määrab ära, milliseid süsteeme saab selle
keelega kirjeldada
Arvutusmudel määrab ära keele väljendusvõime
 Kas me sooviksime kasutada suure
väljendusvõimega keeli (et saaksime kirjeldada mida
iganes)?
 Suur väljendusvõime: imperatiivne mudel (näiteks C või
Java piiranguteta kasutamine):
• Võime kirjeldada “kõike”
• Puudub võimalus formaalseks analüüsiks (või see on väga
keerukas)
 Piiratud väljendusvõime, mis põhineb hästi valitud
arvutusmudelil:
• Spetsifitseerida saab ainult valitud süsteeme
• Formaalne analüüs on võimalik
• Efektiivse (võib-olla isegi automaatse) sünteesi võimalus
Nõudmised spetsifitseerimistehnikatele
 Hierarhia
Inimesed ei suuda aru saada süsteemidest, milles on
rohkem kui ca 5 objekti.
Tegelikud süsteemid nõuavad palju
enamat
Käitumuslik hierarhia
Näited: olekud , protsessid, protseduurid.
 Struktuurne hierarhia
Näited: Protsessorid, räkid, trükkplaadid
Struktuurne käitumine
Peaks olema “kerge” alamsüsteemide
käitumisest tuletada süsteemi, kui
terviku käitumine
Ajaline käitumine
Esmaoluline sidumaks reaalse maailmaga
Igasugune lisainformatsioon (perioodid, sõltuvused,
stsenaariumid) on teretulnud
Ka kasutatava platvormi ajaline käitumine (kiirus) peaks
olema teada
Väga suur mõju disainiprotsessile!
Arvutusmudelid (models of computation) käsitlevad
keele täitmismudeli (execution model) loomiseks
vajalikke teoreetiliste valikute kogumeid
Disain on esitatud kui komponentide kogum, mida võib
vaadelda kui isoleeritud monoliitseid mooduleid (tihti
kutsutakse neid protsessideks – processes või ülesanneteks
p p
– tasks), mis suhtlevad omavahel ja ümbruskonnaga
Arvutusmudel defineerib nende moodulite käitumise ning
omavahelise suhtlemise
Arvutusmudelid esitavad:
Kuidas iga moodul (protsess või
ülesanne) teostab oma sisemisi
arvutusi
Kuidas moodulid vahetavad
omavahel informatsiooni
Kuidas nad seostuvad omavahel
kattuvuse ( concurrency ) mõistes
Mõningad arvutusmudelid ei
kajasta moodulite sisemust,
vaid üksnes nende suhtlemist ja
kattuvust
Süsteemid koosnevad tegevuste (protsessid või
ülesanded) kogumist. Neid tegevusi võib
potensiaalselt täita paralleelselt, ehk teisisõnu: nad
on kattuvad (concurrent).
Kuidas väljendada kattuvust?
See on üks aspekt, milles arvutusmudelid erinevad
Andmete-põhine kattuvus
Kontrolli-põhine kattuvus
Andmete-põhine kattuvus
Süsteem on kirjeldatud kui protsesside kogum ilma
määratlemata täitmisjärjekorraga
Protsesside täitmise järjekord (ja selle põhjal võib
kaudselt teha järeldusi parallelismi kohta) on
fikseeritud ainult andmete sõltuvuse põhjal
Väga tüüpiline paljudes DSP rakendustes
Kontrolli-põhine kattuvus
Protsesside täitmise järjekord on üheselt kirjeldatud
süsteemi spetsifikatsioonis
Kasutatakse spetsiaalseid konstruktsioone et
määrata ära täitmise järjekord ja kattuvus
module p1:
............
end module
module p2:
............
end module
d l 3
See näide on kirjutatud
ESTERELis
Protsess p1 algab
esimesena ja peab
module p3:
............
end module
module p4:
............
end module
run p1;
[run p2 || run 3];
run p4
lõppema enne kui p2 ja
p3 algavad
p2 ja p3 algavad
paralleelselt
p2 ja p3 peavad
mõlemad lõppema, enne
kui p4 saab alustada
Kommunikatsioon
Protsessid peavad info vahetuseks kommunikeeruma
Erinevad arvutusmudelid kasutavad erinevaid
arvutusmudeleid
Jagatud mälu (shared memory )
Sõnumite edastamine ( message passing)
Blokeeriv
Mitte-blokeeriv
Sünkroniseerimine
Sünkroniseerimist ei saa eraldada
kommunikatsioonist
Iga protsesside vaheline suhtlemine eeldab mõningast
kommunikatsiooni ja sünkroniseerimist
Sünkroniseerimine: Üks protsess on seisatud
( suspended ) kuni teise täitmine jõuab mingi punktini
38
Kontrolli-põhine sünkroniseerimine
Andmete põhine sünkroniseerimine
Kontrolli-põhine sünkroniseerimine
Kontrolli-põhise
sünkroniseerimise puhul
tegeleb sünkroniseerimisega
kontrollistruktuur
module p1:
............
end module
module p2:
............
end module
Siin on mitmeid
sünkroniseerimise punkte:
peale p1 lõpetamist ja enne p2,
p3 algust
Peale p2 ja p3 lõppemist ning
enne p4 algust
module p3:
............
end module
module p4:
............
end module
run p1;
[run p2 || run 3];
run p4
Andmete põhine sünkroniseerimine
Kommunikatsioonimehhanismid väljendavad
kaudselt ka sünkroniseerimist
Jagatud mälu põhine sünkroniseerimine
Sõnumite edastamise põhine sünkroniseerimine
Kommunikatsiooni blokeerimine sõnumitega tähendab
automaatselt saatja ja vastuvõtja vahelist sünkroniseerimist
Protsesside omadused
Protsesside arv
Staatiline;
Dünaamiline (Dünaamiliselt muutuv riistvaraplatvorm?)
Käitumuslik hierarhia:
Protsesside rekursiivne deklareerimine (ADA, VHDL)
processErinevad tehnikad protsesside loomiseks
Ilmutatud kujul koodis (vt. ADA)
declare
process P1 …
fork ja join (vt. Unix)
id = fork();
spetsiaalsed protsessi loomise funktsioonid
id = create_process(P1);
Sünkroonsed v. asünkroonsed keeled
Mitmete protsesside kirjeldamine on paljudes keeltes
mittedeterministlik:
Ülesannete täitmise järjekord ei ole kindlaks
määratud (võib mõjutada tulemust).
Sünkroonsed keeled: põhinevad automaatide
teoorial
teoorial.
„Sünkroonsete keelte eesmärgiks on pakkuda
kõrgtaseme, modulaarseid konstruktsioone, et
selliseid automaate oleks kergem luua” [Halbwachs].
Sünkroonsed keeled kirjeldavad samaaegselt
töötavaid automaate.
Sünkroonsed keeled eeldavad (globaalset)
taktsignaali. Igal taktil arvestatakse kõikide
sisenditega, arvutatakse uued olekud ja väljundid
ning alles siis tehakse siire.
See eeldab levitamismehhanisme kõikidesse
süsteemi osadesse.
Ideaalne vaade üheaegsele toimimisele.
 Eeliseks on deterministliku käitumise tagamine.
Tüüpilised arvutusmudelid
Olekudiagrammid (StateCharts)
 Andmevoo (dataflow) mudelid
 Petri võrgud (Petri Nets )
Diskreetsed sündmused (Discerete events )
(Sünkroonsed) lõplikud olekumasinad (Finite State
Machines )
Sünkroonsed/ reaktiivsed keeled
Koosdisaini lõplikud olekumasinad
 Timed Automata
Olekudiagrammid
Arvutusmudel, mis põhineb jagatud mäluga
kommunikatsioonil
Sobib ainult kohtrakendustele (mitte
hajussüsteemidele)
Klassikaline automaat ei ole sobiv keerukate
süsteemide kirjeldamiseks (keerukaid graafe ei ole
võimalik inimestel mõista)
Hierarhia sisse toomine StateCharts
Hinnang StateChart’ile
Pros:
Hierarhia lubab suvalist komplekti AND- ja OR-superstate’e.
Mitmed kommertstarkvarapaketid
(StateMate, StateFlow, BetterState, ...)
On olemas „ back -end“ tarkvara StateChart’ide
transleerimiseks C-sse või VHDLi, võimaldades sedasi
C tarkvaralisi ja riistvaralisi lahendusi.
Cons:
Genereeritud C programmid ei ole alati efektiivsed
Ei sobi hajusrakendustele
Ei ole programmilisi konstruktsioone
Ei võimalda kirjeldada mitte-funktsionaalset käitumist
Ei ole objekt orienteeritud
Ei võimalda haarata struktuurset hierarhiat
SDL
Ideaalne hajusrakendustele (kasutati ISDNi
spetsifitseerimisel),
Tarkvara on saadaval: SINTEF, Telelogic, Cinderella
(www.cinderella.dk).
Ei ole täiesti deterministlik ja ei ole sünkroonne
Implementatsiooni puhul on vaja teada FIFO
maksimumsuurust – arvutamine võib olla väga keeruline
Timeri põhimõte sobib vaid pehmetele reaalaja süsteemidele
Hierarhiate kasutamine on limiteeritud
Programmeerimiskeelte tugi on limiteeritud
Mittefunktsionaalseid omadusi ei ole võimalik kirjeldada
Andmevoo mudelid
Süsteemid on kirjeldatud, kui suunatud graafid, kus:
Sõlmed esitavad arvutusi (protsesse)
 Kaared esitavad täielikult järjestatud andmevoogu
Sõltuvalt semantikast on andmevoo põhjal
defineeritud mitmeid erinevaid arvutusmudeleid:
Kahni protsessivõrgud ( Kahn Process Networks )
Andmevoo protsessivõrgud (Dataflow process networks)
Sünkroonne andmevoog (Synchronous dataflow)
Andmete-põhine kattuvus
Andmevoo mudelid on väga sobivad signaalitöötluses
 Kodeerimine /dekodeerimine, filtreerimine, pakkimine jne
Perioodilised ja regulaarsed andmete lugemised
Tüüpiliselt on signaalitöötlusalgoritmid esitatud blokkdiagrammidena,
mis sobib väga hästi andmevoo
semantikaga
Kahni protsessivõrgud
Protsesside suhtlemisel saadetakse andmeühikuid
läbi ühesuunaliste FIFO kanalite
Kanalisse kirjutamine on mitteblokeeriv
Lugemine blokeeriv:
Protsess on blokeeritud kuni kanalis on piisav kogus andmeid
Protsess, mis proovib lugeda tühjast
kanalist, peab ootama kuni andmed
on saadaval. Ta ei saa enne lugemise
alustamist, kas andmed on saadaval.
Samuti ei saa ta ka tühja kanali korral
lugemisest loobuda
Kahni protsessivõrgud on deterministlikud:
Kindale sisendandmete kombinatsioonile vastab vaid üks
võimalik väljundandmete kombinatsioon (sõltumata sellest,
kui kaua võtavad mingid arvutused aega)
On võimalik vaid spetsifikatsiooni põhjal (teadmata midagi
implementatsioonist) tuletada väljundjada, teades sisendandmeid
Aeg
Andmevoo mudelid on asünkroonselt kattuvad
Sündmused võivad toimuda igal ajal
On olemas sündmuste osaline järjestatavus
• A poolt sümboli genereerimin
toimub alati enne selle tarbimist
B poolt
• Ei ole mingit ette määratud
järjekorda, kas sümboli
tarbib enne B või C
Petri võrgud
Süsteem on spetsifitseeritud kui suunatud
kahealuseline graaf , kus on kahte tüüpi sõlmi:
Koha sõlmed (places): Hoiavad hajutatud süsteemi olekut,
mida väljendatakse märgi ( token ) olemasolu või
puudumisega antud sõlmes
Üleminekud (transitions): Kasutatakse süsteemi toimimisetähistamiseks
Süsteemi olek: kirjeldatakse koha sõlmede
markeeringuga (märkide arv igas sõlmes)
Süsteemi dünaamiline areng on määratletud
üleminekute käivitumisega
Üleminek võib käivituda kui kõik sellele eelnevad koha
sõlmed on märgitud
Ülemineku käivitumisel likvideeritakse iga eelneva koha
sõlme märgistus ja märgitakse kõik järgnevad sõlmed
Petri võrkude tunnused ja kasutus
Petri võrgud on intuitiivsed ja mitteinterpreteeritud
mudel
On palju kasutatud nii infosüsteemide arendamisel,
kui ka arvutiarhitektuuride, operatsioonisüsteemide,
hajussüsteemide ja riistvarasüsteemide loomisel
Petri võrkude omadused
Saab kontrollide mitmeid süsteemi omadusi:
 Piiratus (Boundness) – saab kontrollida, et etteantud
ressursid ei oleks ületatud. Tokenite arv teatud kohas. Kui
piirang on 1, siis seda kutsutakse vahel ka ohutuseks
(safeness)
Elus olemine (Liveness) – Et vältida deadlock ’e. Üleminek on
elus, kui iga võimaliku märgistuse puhul on võimalik selle
ülemineku aktiveerumine
Saavutatavus (Reachability) – Et jõutakse vajalikku olekusse
või et mõnda olekusse kunagi ei jõutaks. Kas on võimalik
liikuda ühest märgistusest teise?
Spetsiaalsed matemaatilised töövahendid. Formaalne
verifitseerimine .
Petri võrgud on asünkroonselt samaaegsed
Sündmused võivad toimuda igal ajal
On olemas sündmuste osaline järjestus
Laiendused:
 Ajalised Petri võrgud (aja aspektide modelleerimiseks)
• Ülekannetega on seotud ajad (aja intervallid )
• Märgid kannavad ajamärgistust
Värvitud Petri võrgud
• Märkidel on väärtused
• Ülekannetega on seotud funktsioonid
Petri võrke saab simuleerida, et süsteemi
verifitseerida ja hinnata suutlikust
DEM
Süsteem on protsesside kogum, mis reageerib
sündmustele
Iga sündmusega on seotud ajatempel, mis näitab
selle sündmuse toimumise aega
Ajatemplid on täielikult reastatud
 Diskreetne sündmusesimulaator peab globaalset
sündmuste järjekorda, mis on sorteeritud ajatemplite
põhiselt. Simulaator defineerib ka globaalse ühtse
aja
Mudelid on asünkroonsed ja samaaegsed
Näiteks: VHDL, Verilog
C kasutamine sardsüsteemide loomisel
 Motivatsioon
Paljud standardid (näiteks GSM, MPEG ) on publitseeritud C
programmidena
• Riistvara kirjelduskeele (näiteks VHDL) kasutamiseks peaks
standardeid hakkama “tõlkima”
Paljude süsteemide funktsionaalsus eeldab nii riistvara kui
ka tarkvara
• Simuleerimine nõuaks vastavaid liideseid, kui just sama keelt ei
kasutata
On proovitud kirjeldada riistvara ja tarkvara, lähtudes
samast keelest. See ei olegi nii lihtne Erinevad C dialektid
riistvara kirjeldamiseks
C/C++ puudused
C/C++ ei ole loodud riistvara disainiks
C/C++ ei toeta:
Riistvara stiilis kommunikatsiooni – signaalid, protokollid
Aja mõistet – taktsignaal, operatsioonide ajaline järjestus
Kattuvus – Riistvara töötab paralleelselt
Reaktiivsus – Riistvara reageerib välistele andmetele,
suhtleb keskkonnaga
Riistvaralised andmetüübid – bit, mitmeväärtuseline loogika
Silumise käigus on ligipääs riistvarale keeruline
SpecC
interface interface channel C implements L,R<
int Read(void)
behavior B1 (in int p1, L p2, in int p3)< };
behavior B2 (out int p1, R p2, out int p3)< };
behavior B(in int p1, out int p2)<}
SystemC
 Requirements , solutions for modeling HW in a SW
language :
C++ class library including required functions .
Concurrency: via processes, controlled by sensivity lists*
and calls to wait primitives .
Time: Floating point numbers in SystemC 1 0
1.0.
Integer values in SystemC 2.0;
Includes units such as ps, ns, μs etc*.
 Support of bit-datatypes: bitvectors of different lengths; 2-
and 4-valued logic; built -in resolution*)
 Communication : plug-and-play (pnp) channel model,
allowing easy replacement of intellectual property (IP)
Deterministic behavior not guaranteed.
Java
Eelised
“Ohutu” keel
• Puudub viidaaritmeetika
• Toetab eranditöötlust (exception handling )
• Kasutaja põhjustatud mälulekete puudumine
Toetab kattuvust ( light weight processes)
light-Platvormist sõltumatu
• Väga kompaktne byte-code (kompaktsem, kui teiste keelte
masinkood )
Java
Puudused
Run-time library’te suurus
Ligipääs spetsiaalsele riistvarale (otsene I/O kontroll)
 Automaatne mälukoristus
Mittedeterministlik threadide käivitamine (WCET hinnangud
peavad olema väga pessimistlikud)
 Real -aja mõiste hägusus
Sardtarkvara süntees
􀁡 Süsteemi analüüs
􀁡 RTOS & rakenduste valimine
􀁡 Tükeldamine
􀁡 Liideste defineerimine
􀁡 Moodulite projekteerimine
􀁡 Tarkvara integreerimine
􀁡 Tarkvara paigaldamine (ROM)
􀁡 Tarkvara kompileerimine & linkimine
© Peeter Ellervee sardsüsteemid - arvutusprotsessid 6
Sardtarkvara
􀁡 Üks ja ainuke rakendusprogramm
􀁠 Mälujaotus
⌧ programm – rakendus + süsteem
⌧ andmed – staatilised / dünaamilised / pinu
􀁠 Programmi töö
⌧ alglaadimine
• protsessori initsialiseerimine
• programmi initsialiseerimine
⌧ programm tsüklis
⌧ süsteemipöördused
􀁡 Mitu rakendusprogrammi (ülesannet)
⌧ lisaks üksikule programmile
􀁠 Mälujaotus
⌧ eri programmide andmed/programm eri kohtades
⌧ andmete kaitsmine
• MMU – Memory Management Unit
􀁠 Programmide töö
⌧ süsteemi initsialiseerimine
⌧ ülesannete vahetamine
• planeerimine, CPU sisu salvestamine,
Mälujaotus – mitu rakendust
􀁡 Iga rakendusprogramm füüsiliselt erineval aadressil
􀁠 rakenduse sisemised mälupiirkonnad samad (.data, . heap jne.)
􀁠 MMU-d kasutatakse mälu kaitsmiseks valepöörduste eest
􀁠 linkimine keerukas – aadressid vaja eraldi ette anda
􀁡 Kõikide rakendusprogrammide jaoks on mälujaotus
ühesugune – nn. virtuaalne aadressväli (virtuaalmälu)
􀁠 rakenduse sisemised mälupiirkonnad samad (.data, .heap jne.)
􀁠 MMU vajalik nii mälupiirkondade kaitsmiseks kui ka
virtuaalse aadressi “tõlkimisel” füüsiliseks aadressiks
􀁠 linkimine lihtne – sama kõikidele rakendustele
􀁡 ROM
⌧ RO segment (mitu programmi/kasutajat)
􀁠 .boot piirkond
⌧ CPU initsialiseerimine
⌧ katkestusvektorid
⌧ pinu jt. mälupiirkondade aadressid
• … või teostatakse (RT)OS-i poolt
􀁠 .init piirkond
⌧ parameetrid programmile / tulemus OS-le
⌧ objektide algväärtustamine (nt. C++)
© Peeter Ellervee sardsüsteemid - arvutusprotsessid 12
􀁡 ROM (jätkub…) .text piirkond
􀁠 main() …
⌧ rakendusprogrammid
⌧ kompileeritult või teekidest .o-failidena
􀁠 sys.f-ns
⌧ standartsed alamprogrammid
• kompilaatori-spetsiifilised
⌧ süsteemsed alamprogrammid
• OS-spetsiifilised
• S/V draiverid jms.
􀁡 RAM
⌧ RW segment (mitu programmi/kasutajat)
􀁠 .data piirkond
⌧ staatilised ( globaalsed ) muutujad/andmed
􀁠 .heap piirkond
⌧ dünaamilised muutujad/andmed
⌧ kasutatud/vabade plokkide nimekiri
• prügikogumine (garbage collection ) aega-ajalt vajalik
• vajadusel suurendatakse OS-i poolt
􀁠 . stack piirkond
⌧ lokaalsed muutujad/andmed (pinu)
Mälukujutis
􀁡 a.out / .exe / .com
⌧ OS-i poolt mällu laetav programmi “ toorik ”
􀁠 Sisaldab
⌧ programmi initsialiseerimine & sisu
⌧ algväärtustatud andmed (muutujad & konstandid)
• osa globaalsetest muutujatest
􀁠 OS-i poolt teostatakse
⌧ mälujaotuse ette valmistamine
• piirkondade eraldamine (MMU), viidad registritesse, …
⌧ programmi juhtimine
• alustamine, katkestamine, OS-i pöördused,
Kompileerimine
􀁡Etapid
􀁠 teisendamine abstraktseks
operatsioonide jadaks
􀁠 optimeerimine
􀁡Programmi teisendamine
operatsioonide jadaks
􀁠 Keelekonstruktsioon –>
baas-plokkide jada
􀁠 Baas- plokk ~ avaldis
Kompileerimine
􀁡Programmi teisendamine
operatsioonide jadaks
􀁠 Baas-plokk ~ avaldis
􀁠 Avaldis –> operatsioonide jada
⌧ nn. Poola kuju (Polish notation,
prefix notation, Jan Łukasiewicz)
⌧ operatsioonide prioriteedid
⌧ primaased avaldised
• sulud , muutujad, funktsioonid, …
⌧ pinu või virtuaal- registrid
􀁠 Ühised alamavaldised
x = a + b + c ;
r1