ITKA203 – Käyttöjärjestelmät
Kurssimateriaalia: ”luentomoniste”

Tämän version tilanne: Tämä versio monisteesta on käyttökelpoinen vuoden 2023 kurssitoteutukselle, ainakin aloituspäivänä. Huomautus: Tarkoitus on muokata monistetta kurssin aikana niin paljon kuin ehditään. Kuitenkin niin, että päälinjat ja sisältö säilyvät samoina kurssin ensimmäisestä päivästä (22.3.2023) siihen asti, kun viimeinen tenttiuusinta elokuussa 2023 on ollut. Erityisesti joitain vuoden 2022 tarkkanäköisten opiskelijoiden huomaamia sanamuotoseikkoja konekieliosuudessa olisi hyödyllistä selkeyttää. Sivunumerot saattavat hivenen heittää versiosta toiseen muutosten johdosta. Mahdolliset uudet kuvat lisätään ensivaiheessa ilman numerointia, joten jos esimerkiksi luennolla on puhuttu kuvasta 23 niin se on vielä elokuussa 2023 edelleenkin kuva 23.

Merkittävät asiavirheet korjataan aina välittömästi – ilmoita heti, jos löydät sellaisen!

Esipuhe

Tämä on Jyväskylän yliopiston Informaatioteknologian tiedekunnan kurssia ITKA203 Käyttöjärjestelmät tukeva teksti. Kädessäsi oleva versio on tulostettu LATE X -ladontajärjestelmällä päivämäärällä 22. maaliskuuta 2023. Tämän lisäksi kurssin sisältöön kuuluvat sekä luennoilla nähtävät esimerkit että demot laajoine opastusteksteineen. Koko kurssimateriaalin viimeisin kehitysversio löytyy versionhallinnasta seuraavasta sijainnista:
https://gitlab.jyu.fi/itka203-kurssimateriaali/itka203-kurssimateriaali-avoin

Edellä mainitussa sijainnissa löytyy myös kohtalaisen tarkoin määritellyt osaamistavoitteet, joiden saavuttamiseen demot, esimerkit ja myös tämä moniste tähtäävät.

Keväästä 2014 alkaen materiaali on ollut versiohallintajärjestelmässä¹ siinä toivossa, että sitä kehitettäisiin yhteisvoimin kulloisenkin vastuuopettajan koordinoimana. Mikäli haluat selventää aihepiiriä nykyistä paremmin, ota rohkeasti yhteyttä projektiin, jotta pääset mukaan kirjoittamaan ja korjaamaan monistetta paremmaksi ja alan kehittyviä tarpeita vastaavaksi! Mikäli löydät asiavirheitä tai epäselvyyksiä, joita ei ole sellaisiksi merkitty, ota yhteyttä välittömästi!

Tekijät sitoutuvat sijoittamaan osuutensa avoimen lisenssin alle sekä käyttämään yhteistä versionhallintajärjestelmää muutosten tekemiseen. Hyvistä kontribuutioista voitaneen kurssin yhteydessä antaa bonuspisteitä tenttiin; näistä on neuvoteltava vastuuopettajan kanssa etukäteen.

Lisenssi

Tämä teos on lisensoitu Creative Commons Nimeä-JaaSamoin 4.0 Kansainvälinen -käyttöluvalla.

Tekijät ja kiitokset

Allekirjoittanut on kasannut materiaalin vuosina 2007-2023 hyödyntäen aiempien opettajien (Jarmo Ernvall, Pentti Hämäläinen, Aarni Perko) aiherajauksia sekä luentomateriaaleja. Vaikuttimena on William Stallingsin oppikirja [1], tosin etenkin käytännön osioissa materiaali on originaalia ja perustuu suoraan laite- ja rajapintadokumentaatioon. Kevään 2014 aikana merkittäviä uudistuksia teki tuntiopettaja Juha Rautiainen. Emma Lindfors kävi syksyllä 2014 monisteen läpi opiskelijan näkökulmasta antaen arvokkaita ehdotuksia täsmennyksistä ja rakenteen selkeyttämisestä. Keväällä 2015 Ari Tuhkala piirsi havainnekuvat aiempaa kauniimmin ja Tomi Lundberg auttoi dokumentin strukturoinnissa sekä tuotti demoihin kaivatun vim-tekstieditorin alkuopastuksen. Keväällä 2019 Jonne Itkonen teki merkittäviä ilmiasuparannuksia ja sisältötäsmennyksiä. Keväällä 2020 Minna Sirén kustomoi HTML:nä jaettavan tehtäväpaketin CSS-tyylitiedoston demo-ohjeiden lukemista aiempaa paremmin tukevaan muotoon. Hämmentävän läheisesti vastaavan kaltainen kurssimateriaalin kehitysprosessi vaikuttaa johtaneen ilmaiseen englanninkieliseen verkko-oppikirjaan [2], jota allekirjoittanut tänä päivänä suositteleekin ensimmäiseksi lisälukemistoksi yllä mainitun maksullisen oppikirjan sijasta.

Muutama sana terminologiasta ja alaviitteistä

Tärkeintä on aina käsitteet termien takana, mutta alalla tarvitaan myös oma erityissanasto, jolla voidaan kommunikoida asiat lyhyesti. Tälläkin kurssilla tulee vastaan huikea määrä uusia sanoja, joilla kutakin esiteltyä käsitettä tai rakennelmaa symboloidaan puhutussa ja kirjoitetussa kielessä. Käsite- ja sanastovyöryyn on syytä varautua kurssin ensi hetkistä alkaen!

Monet käsitteet ja sanat ovat syntyneet englanniksi. Alkuperäissanat ovat enemmän tai vähemmän loogisia analogioita reaalimaailman ilmiöistä. Suomalaiseen sanastoon on poimittu enemmän tai vähemmän loogisin perustein lainasanoja tai sanayhdistelmiä. Suomennoksiakin on tehty, enemmän tai vähemmän loogisin perustein, ja on pyritty vakiinnuttamaan suomalaiseen suuhun taipuvaa terminologiaa ammattikieleen. Vaikka olenkin yleensä kielipoliisi pahimmasta päästä, aiheen työstäminen suomeksi asettaa haasteita: Pitäisikö puhua esimerkiksi suorittimesta vai prosessorista, vuorontajasta vai skedulerista, näennäismuistista vai virtuaalimuistista, näennäis- vai virtuaalikoneesta, kuoresta vai shellistä, lokitiedoista vai logitiedoista… Kieltämättä monet sanoista periytyvät omasta ja lähipiirini puheenparresta, jonka syntyhistoria paikallisessa tietojenkäsittelykulttuurissa on vanhempi kuin minä itse. Osittain moniste siis pitää yllä tuota kyseistä perinnettä sen sijaan, mitä kielitoimiston suositukset mahdollisesti sanovat. Siihen olen pyrkinyt, että jokaisesta asiasta käytetään säännönmukaisesti samaa sanaa sen jälkeen, kun käsitteen ensiesittelyn yhteydessä on listattu myös muut yleisesti käytetyt variaatiot. Olen tietoisesti käyttänyt lainasanoja ja englismejä niin runsaalla kädellä, että se sattuu jo omaan sieluun, mutta tällä olen halunnut kaventaa eroa kurssilla vastaan tulevan termin ja englanninkielisessä kirjallisuudessa esiintyvän sanaston välillä.

Lukija, jota monisteen lukuisat alaviitteet häiritsevät, ohittakoon ne huoletta² .

Jyväskylässä 2016-2023,
Paavo Nieminen <paavo.j.nieminen@jyu.fi>

Sisältö

1 Motivointia ja sijoittamista kokonaiskuvaan

Käyttöjärjestelmä on ohjelmisto, joka toimii rajapintana laitteiston ja sovellusohjelmien välillä. Sen tehtävä on tarjota palveluita, joiden kautta tietokonelaitteiston käyttö on muille ohjelmille suoraviivaista, tehokasta ja turvallista. Siinä se kaikessa lyhykäisyydessään oli. Loppu tästä kurssista on tämän lauseen avaamista. Karkea yleiskuva ei nimittäin riitä silloin, kun ratkaistavana on johonkin yksityiskohtaan liittyvä ongelma!

Tärkeätä on heti alkuun todeta, mitä tältä kurssilta ei kannata odottaa: Täällä ei ensinnäkään käsitellä graafisia käyttöliittymiä.Yhtään ikkunaa painikkeineen ei suunnitella eikä sen taustaväriä mietitä. Ei mietitä, miten verkkokauppaa käytetään mobiililaitteella tai WWW-selaimella tai millaisia ajatuksia tietokonetta klikkailevan käyttäjän päässä liikkuu. Sen sijaan tämä on matka ytimeen, syvälle kohti puolijohteista valmistettua aparaattia, joka murskaa numeroita miljardi kertaa sekunnissa tikittävän kellon piiskaamana. Sieltä tullaan takaisin vain hieman sen rajapinnan yläpuolelle, jonka alapuolella on rauta ja yläpuolella softa. Asioista puhutaan ohjelmakoodilla, konekielellä ja heksaluvuilla.

Teknisesti orientoituneita, laitteiden toiminnasta kiinnostuneita opiskelijoita tämä aihepiiri yleensä kiehtoo luonnostaan. Muille asia saattaa tuntua lähtökohtaisesti vastenmieliseltä ja tarpeettomaltakin… Se on kuitenkin harhaa, koska laitteiston rajapinta on erittäin olennainen informaatioteknologian koneiston ratas. Kuitenkin heti alussa on syytä ymmärtää, mitä tuleman pitää. Pidä edeltävän ohjelmointikurssin oppikirjasta kiinni, koska pian lähdetään laskeutumaan syvemmälle! Jos et innostukseltasi jaksa pysyä tuolilla, voit jatkaa luvusta 2.3. Muussa tapauksessa ilmeisesti epäröit, joten tarvitset lisää motivointia.

Aloitetaan mielikuvaharjoitteesta: Kirjoittelet opinnäytetyötäsi jollakin toimisto-ohjelmalla, esimerkiksi Open Office Writerilla. Juuri äsken olet retusoinut opinnäytteeseen liittyvää valokuvaa piirto-ohjelmalla, esimerkiksi Gimpillä. Tallensit kuvasta tähän asti parhaan version siihen hakemistoon, jossa opinnäytteen kuvatiedostot sijaitsevat. Molemmat ohjelmat (toimisto-ohjelma, kuvankäsittely) ovat auki tietokoneessasi. Mieleesi tulee tarkistaa sähköpostit. Käynnistät siis lisäksi WWW-selaimen ja suuntaat yliopiston sähköpostin nettikäyttöliittymään. Taskussasi piippaa, ja huomaat että kaverisi on kirjoittanut viestin Facebookin kautta suoraan omaan älypuhelimeesi…

Edellä esitettyyn mielikuvaan lienee helppo samaistua. Teknologia on arkipäivää, jota ei tule ajateltua sen enempää. Sitä vain käytetään osana normaalia elämää. Z-sukupolven lapset todennäköisesti oppivat klikkaamaan ennen kuin lukemaan.

Tällä kurssilla kuitenkin mennään pintaa syvemmälle. Äsken kuviteltu tilanne näyttää ulkopuolelta siltä, että käyttäjä klikkailee ja näppäilee syöttölaitteita kuten hiirtä ja näppäimistöä tai älypuhelimen kosketusnäyttöä. Sitten ikään kuin välittömästi jotakin muuttuu tulostuslaitteella kuten kuvaruudulla tai älypuhelimen näytöllä. Itse asiassa tietokonelaitteiston sisällä täytyy tapahtua hyvinkin paljon jokaisen klikkauksen ja tulostuksen välisenä aikana. Tämän kurssin tavoite on, että sen lopuksi tiedät varsin tarkoin muun muassa:

• miten näppäilyt teknisesti siirtyvät koko pitkän matkansa sovellusohjelmien käyttöön
• miten on teknisesti mahdollista, että käytössä on monta ohjelmaa yhtä aikaa (ja miksi se ei oikeastaan ole mitenkään itsestäänselvää)
• mitä on huomioitava, kun tehdään ohjelmia, jotka ratkaisevat samaa ongelmaa yhteistyössä samanaikaisesti
• mitä oikeastaan tarkoittaa se, että jotakin tallennetaan pysyvästi ”tietokoneeseen”
• miksi pitäisi nostaa hattua jollekin, joka on saanut kehitettyä käyttökelpoisen käyttöjärjestelmän.

Lisäksi tavoitteena on lisätä monelta muultakin osin IT-alan yleissivistystä sekä ottaa haltuun perusteluineen ne ohjelmoinnilliset yksityiskohdat, joita hyvien ohjelmien tekeminen nykytietokoneille vaatii. Ensimmäisen ohjelmointikurssin antamaa perustaitoa laajennetaan antamalla kevyt yleiskäsitys kahdesta erilaisesta ohjelmointikielestä: laiteläheisestä C-kielestä ja moninaisiin ylläpitotehtäviin soveltuvasta Bourne Again Shell -skriptikielestä. Jonkin verran tutustutaan myös symboliseen konekieleen eli assembleriin³ .

Yritetäänpä sijoitella tätä kurssia kartalle informaatioteknologian kokonaiskuvassa. Arkipäivää ovat esimerkiksi verkkopankin käyttö, yhteydenpito sosiaalisessa mediassa, digitaalisten muistojen tallentaminen ja jakaminen (esim. valokuvat, videot) tai digitaalisten pelien pelaaminen. Nämä ovat selkeästi informaatioteknologian (eli tietokone- ja tietoliikennelaitteistojen sekä ohjelmistojen) sovelluksia. Puhelu sukulaiselle kulkee nykyään kännykästä kännykkään radiolinkkien ja valokuitukaapelin kautta. Lentokoneiden, laivojen ja autojen ohjaamisesta on tehty täsmällisempää, helpompaa ja turvallisempaa informaatioteknologian avulla. Muinaiset DVD-levyt ja suoratoistopalveluiden ohjelmat katsotaan laitteella, jota ohjaa jonkinlainen tietokone. Myös televisiossa itsessään on tietokone. Universumin salat avautuvat tietokoneella tehtävän laskennan avulla samoin kuin huomisen päivän sääennuste. Sykemittari auttaa tekemään optimaalisen treenin. Siinä on sisällä tietokone, joka on langattomasti yhteydessä toiseen tietokoneeseen. Talot, joissa asumme, on suunniteltu tietokoneen avulla samoin kuin keittiön kaapiston mitat. Lista jatkuisi lähes äärettömiin, mutta riittäköön jo vakuutteluksi.

Informaatioteknologian kenttä on laaja, mutta kaikissa tilanteissa on aina mukana sekä ihminen että jonkinlainen, useimmiten toisiin vastaaviin yhteydessä oleva, tietokone. Alalla olemme tottuneet käyttämään ihmisestä nimitystä ”käyttäjä”, koska hän käyttää näitä rakentamiamme järjestelmiä. Toisessa päässä kuviota, kauempana arkihavainnosta, on tämän kaiken mahdollistava laitteisto, jonka eräästä olennaisesta komponentista käytämme tietyllä tapaa hassua ilmaisua ”tietokone”. Välissä tarvitaan erinäinen valikoima jotakin, mitä sanomme ”ohjelmistoksi”.

Kuva 1 on karkea yleistys kerroksista, joihin käyttäjän ja tietokonelaitteiston välissä oleva osuus kokonaiskuvasta voidaan ajatella jaettavan. Käydään sitä läpi muutaman tekstikappaleen verran.

Kuva rajoittuu tilanteeseen, jossa yksittäinen käyttäjä hyödyntää yksittäistä sovellusohjelmaa yksittäisellä tietokonelaitteella. Tämä on yleinen ja helposti samaistuttava informaatioteknologian sovellus, vaikka se on ehkä yksinkertaisin mahdollinen. Arkipäivän tutuissa sovelluksissakin kun käyttäjän tavoite voi olla yhteydenpito muihin käyttäjiin (esimerkiksi email, some…) palveluntarjoajiin (esimerkiksi verkkopankki, nettikauppa…), jolloin välissä voi olla kilometreittäin verkkoyhteyksiä ja järjestelmään voi kuulua monia tietokoneita ja tietokantoja. Onneksi asiat voidaan opiskella (ja toteuttaakin) yksi pienempi pala tai koeputkiesimerkki kerrallaan.

Olipa informaatioteknologian sovelluksen kokonaiskuva tai sen merkitys ihmisen elämässä kuinka laaja tahansa, siihen kuuluu aina olennaisena osana yksi tai useampi sähköllä toimiva tietokone, joka on piirretty kerroksittaisen kuvan alimmalle tasolle. Laitteisto on teknisistä syistä yksinkertainen, ja jotta monimutkaisempien ohjelmistojen olisi helppoa sitä käyttää, tarvitaan tietynlainen erityisohjelmisto, jota sanotaan käyttöjärjestelmäksi.

Ylipäätään kerroksittainen rakenne on historian mittaan osoittautunut hyväksi tavaksi tehdä ohjelmistoja. Jokainen alempi kerros niin sanotusti tarjoaa palveluja, joita ylempi kerros voi hyödyntää tarjotakseen puolestaan palveluja seuraavalle ylemmälle kerrokselle. Kerrosten väliin määritellyt rajapinnat (engl. interface) mahdollistavat kerrosten tarkastelun (kuten suunnittelun, toteutuksen ja opiskelun) toisistaan riippumattomina, erillisinä kokonaisuuksina. Rajapinta tarkoittaa alemman kerroksen valmistajan määrittelemiä keinoja, joilla kerroksen palveluita käytetään. Rajapinnan dokumentaatio sisältää käyttöohjeet, joissa kuvaillaan tarkoin kerroksen ominaisuudet, toiminnallisuudet ja keinot, joilla ylempi taso voi niitä hyödyntää.

Kuvattua kerrosmaista rakennetta tai sen osaa pohjalta johonkin tiettyyn kirjastoon asti voidaan sanoa ohjelmistopinkaksi (engl. software stack). Abstraktisti voidaan puhua myös virtuaalikonehierarkiasta, koska jokainen rajapinta tavallaan määrittelee yhdenlaisen virtuaalisen koneen, piilottaen alempien kerrosten “astetta todellisemmat” koneet. Myös monen tietokonelaitteiston rajapinta on virtuaalinen: prosessoriarkkitehtuurissa dokumentoidun rajapinnan alla on vielä laitteen suunnittelijoiden rakentamia kerroksia, joita ei välttämättä ole dokumentoitu julkisesti. Tällä kurssilla emme käsittele asioita dokumentoidun prosessoriarkkitehtuurin alapuolella.

Tämän kurssin esitietona edellytämme jonkinlaisen ohjelmoinnin peruskurssin, jossa on nähty ensinnäkin jonkin ohjelmointikielen rajapinta: sopimus syntaksista, jolla kyseistä kieltä voidaan kirjoittaa, ja semantiikasta eli siitä, mitä kirjoitettu ohjelma tarkoittaa tietorakenteiden ja suorituksen kannalta. Lisäksi ohjelmoinnin peruskurssilla on varmasti nähty kurssilla käytössä olleelle ohjelmointikielelle tarjolla olevien peruskirjastojen rajapintoja, eli metodeita tai aliohjelmia, joilla tehdään joitakin usein tarvittavia operaatiota – yksinkertaisimmillaan esimerkiksi tekstin tulostaminen kuvaruudulle tai kirjoittaminen tiedostoon. Nykyisellä Ohjelmointi 1 -kurssillamme⁴ hyödynnetään C#-kielen ja .NET -alustan peruskirjastojen lisäksi paikallisen yhteisön kehittämää Jypeli-nimistä kirjastoa, jonka avulla voidaan luoda erilaisia kaksiulotteisia pelejä. Jypeli-kirjaston rajapinta määrittelee, miten ja millaisia peliobjekteja voidaan luoda ja miten niiden yhteistoimintaa voidaan koordinoida.

Tällä kurssilla kiinnostuksen kohteena on ensinnäkin käyttöjärjestelmän niin sanottu ydin (engl. kernel), joka käyttää alempaa tasoa eli fyysistä tietokonejärjestelmää niin sanotun käskykanta-arkkitehtuurin välityksellä ja tarjoaa ylemmälle tasolle eli ”matalan tason kirjasto-ohjelmistolle” niin sanotun järjestelmäkutsurajapinnan. Myös tuon matalan tason kirjasto-ohjelmiston voidaan ajatella olevan osa käyttöjärjestelmän ylöspäin tarjoamaa rajapintaa. Lisäksi käyttöjärjestelmän rajapinta voi sisältää apuohjelmistoja, erityisesti jonkinlaisen kuoren (engl. shell) eli komentokielen ja joukon apuohjelmia, joilla jopa käyttäjä itse voi kaikkein suorimmin päästä käsiksi ytimen hallitsemaan laitteistoon.

Käyttöjärjestelmäohjelmisto on käytännön syistä muodostunut välttämättömäksi välittäjäksi sovellusohjelman ja tietokonelaitteiston välille. Tehdäkseen mitään laitteistoon liittyvää, kuten näppäinpainallusten vastaanottaminen, sovelluksen on kuljettava käyttöjärjestelmän tarjoaman rajapinnan kautta. Käytännössä ohjelmistopinkan päällimmäisenä oleva sovellus käyttää kirjastoja, jotka käyttävät alemman tason kirjastoja, jotka käyttävät edelleen alemman tason kirjastoja…vasta aivan alimman tason kirjasto hoitaa teknisesti yhteyden käyttöjärjestelmän ytimeen.

Ylöspäin käyttöjärjestelmän ydin tarjoaa järjestelmäkutsurajapinnan, joka ei ole määrittelytavaltaan kovin erilainen kuin kirjastojen toisilleen ja sovellusohjelmille tarjoamat rajapinnat eli julkisten aliohjelmien/metodien nimet, parametrilistat ja luvatut vaikutukset dataan. Tämä kaikkein alin ohjelmistorajapinta tarjoaa välikirjastojen kautta sovellusohjelmien ainoat keinot vaikuttaa tietokonelaitteiston osiin ja sen resurssien (laskenta-aika, muisti, syöttö-, tulostus- ja tallennusvälineet, tietoverkkoyhteydet) käyttöön.

Käyttöjärjestelmä on ohjelmisto siinä missä muutkin – erotuksella että vain sillä on lupa tehdä tiettyjä resurssijakoon liittyviä toimenpiteitä. Tämä yksinoikeudellinen lupa on historian saatossa nähty tarpeelliseksi esimerkiksi tietoturvasyiden vuoksi, ja se on ehditty suunnitella sisään syvälle nykyisten tietokoneiden rakenteeseen. Nykyaikaisen laitteiston ylöspäin tarjoama rajapinta eli käskykanta-arkkitehtuuri (tai ”prosessoriarkkitehtuuri”) tukee suoraan nykyaikaisen käyttöjärjestelmäohjelmiston tarvitsemia erivapauksia tällä kurssilla vilkaistavin teknisin keinoin.

Joidenkin kurssin osaamistavoitteiden arvostaminen saattaa vaatia jonkin verran perustietoa, jota ei vielä tähän johdantoon mahdu – miksi esimerkiksi usean ohjelman toimiminen samaan aikaan on jotenkin mainitsemisen arvoista, kun käytännössä ”tarvitsee vain klikata ne kaikki ohjelmat käyntiin”… Jotta peruskäyttäjälle itsestäänselviä asioita (eli asioita, jotka käyttäjälle tulee tarjota että hän on tyytyväinen) osaisi arvostaa ohjelmien ja tietojärjestelmien toteuttajan näkökulmasta, täytyy ymmärtää jonkin verran siitä, millainen laite nykyaikainen tietokone oikeastaan on. Liite A tarjoaa “pullantuoksuisen pehmojohdannon”, joka on ehdottoman suositeltavaa alkulukemistoa, mikäli tekninen lähestymistapa pelottaa. Liitteessä käydään läpi tämän kurssin sisältöä yllättävän pitkälle menemättä lainkaan teknisiin yksityiskohtiin.

Varsinainen asia alkaa luvusta 2, joka kuvailee tiiviisti olennaiset piirteet fyysisestä tietokonelaitteistosta, jollaista käyttöjärjestelmillä ohjataan. Sen alku on kurssin Tietokoneen rakenne ja arkkitehtuuri kertausta tai ennakkopaljastusta, riippuen siitä, onko kurssi jo käyty vai ei. Samoin käydään läpi joidenkin muiden kurssien sisältöä niiltä osin kuin myöhempien lukujen seuraaminen vähimmillään vaatii. Kuvaan 2 on merkitty muita kurssejamme, joihin käyttöjärjestelmät vahvasti liittyvät. Ilman Ohjelmointi 1 -kurssin hyvää hallintaa tämän kurssin asiat menevät todennäköisesti ohi korkealta ja kovaa. Kuvaan on myös merkitty päämäärät: Tämän kurssin sisältö ja kädentaidot oletetaan kokonaisuudessaan tunnetuksi ainakin tietotekniikan maisteriohjelmien syventävillä kursseilla. Suoraa työelämärelevanssiakin tällä on, koska kurssin tietojen pohjalta on mahdollisuus tarttua nopeammin sellaisten ongelmien ratkaisemiseen, jotka liittyvät alimpiin ohjelmistokerroksiin.

Esitietojen varmistuksen jälkeen luku 3 käy läpi teknisiä näkökulmia ohjelmien tekemiseen ja suorittamiseen tietokoneessa. Luku 4 kuvailee konekieltä, joka on viime kädessä ainoa rajapinta, jonka kautta tehtaalta toimitettua tietokonelaitteistoa on mahdollista komentaa⁵ . Luvussa 5 käydään täsmällisesti läpi yksittäisen ohjelman konekielinen suoritus ja virtuaalimuistiavaruuden käyttö yhden prosessoitavan ohjelman näkökulmasta. Luvussa 6 käydään tietotekniikan historian kautta läpi ohjelmien suorittamiseen liittyviä tavoitteita ja haasteita, joiden ratkaisuna nykyaikaisen käyttöjärjestelmän piirteet ovat syntyneet. Luku 7 käsittelee käyttöjärjestelmän ja fyysisen laitteiston kättelypintaa eli keskeytysjärjestelmää ja käyttöjärjestelmän kutsurajapintaa konekielen tasolla. Luvussa 8 ryhdytään puhumaan omassa muistiavaruudessaan suorituksessa olevasta ohjelmasta prosessina, käydään läpi abstraktiin prosessin käsitteeseen liittyviä ominaisuuksia sekä tapoja, joilla ominaisuudet voidaan käytännössä toteuttaa käyttöjärjestelmän ohjelmakoodissa. Luvussa 9 havaitaan yhdenaikaisten prosessien tai säikeiden käytön hyötyjä sekä tällaisesta yhdenaikaisuudesta mahdollisesti aiheutuvia ongelmia ratkaisuineen. Viimeisissä luvuissa käydään läpi muutamia tärkeimpiä yksityiskohtia ja menettelytapoja, jotka liittyvät käyttöjärjestelmän tärkeimpiin osajärjestelmiin: luku 10 käsittelee muistinhallintaa, luku 11 syöttö- ja tulostuslaitteita ja luku 12 tiedostojärjestelmää. Luvussa 13 tehdään aiempien lukujen pohjatietoihin vedoten huomioita suunnitteluperusteista ja kompromisseista, joita käyttöjärjestelmän ja sen osioiden suunnitteluun liittyy. Luku 14 mainitsee sanan tai pari skripteistä, jotka kurssilla varsinaisesti käsitellään demotehtävien kautta.

2 Esitietoja

Osaamistavoitteet: Luvun luettuaan opiskelija:

• tietää, mitä hänen tulisi jo osata ennen tämän kurssin loppuosan seuraamista; osa asioista on tullut vastaan kaikille pakollisella esitietokurssilla Ohjelmointi 1, mutta osa käydään tässä välttämättömiltä osin läpi uutena asiana niille, joilla Ohjelmointi 1:n lisäksi muita suositeltuja esitietoja ei mahdu sivuaineopintopakettiin. Näiltä kursseilta (Ohjelmointi 2, Tietokoneen rakenne ja arkkitehtuuri, Algoritmit 1) tarvitaan vain muutamaa erityisasiaa, joita voidaan tällä kurssilla käsitellä soveltaen tai ennakoivasti, ilman mainituilla kursseilla tarjottavaa teoriapohjaa.

Tässä luvussa on joitakin esitietoja, joita myöhempien lukujen ja kurssin käytännön esimerkkien täysipainoinen ymmärtäminen luultavasti edellyttää. Nämä tiedot tarvitaan, että myöhemmistä luvuista, luennoista tai demotehtävistä voisi olla hyötyä. Ymmärryksen syntyminen on lopulta tärkeintä, ja se voi syntyä vain aiempien palasten päälle.

Aluksi luvussa 2.1 muistellaan, mitä ensimmäisellä ohjelmointikurssilla on opittu ohjelmien suunnittelusta ja kirjoittamisesta rakenteisella ohjelmointikielellä. Seuraavaksi luvussa 2.2 käydään pintapuolisesti läpi abstrakteja tietorakenteita, joita käyttöjärjestelmän toiminta ja sen ymmärtäminen edellyttää. Tällaiset asiat käydään tarkemmin läpi tietorakenteita ja algoritmeja käsittelevillä kursseilla. Lopuksi luvussa 2.3 esitellään tietokoneen fyysistä rakennetta ja toimintaperiaatteita, jotta voidaan tarkemmin nähdä, miksi käyttöjärjestelmää tarvitaan, mihin se sijoittuu tietotekniikan kokonaiskuvassa ja millaisia tehtäviä käyttöjärjestelmän tulee pystyä hoitamaan. Se on suppea läpileikkaus asioista, joita yleensä käydään läpi kursseilla, joiden nimet voivat viitata esimerkiksi tietokoneen rakenteeseen ja arkkitehtuuriiin tai digitaalilogiikkaan. Laitteiston esittelyn yhteydessä käydään läpi myös lukujärjestelmiä ja niiden notaatioita. Niitä on ehkä sivuttu Ohjelmointi 1 -kurssilla, mutta todennäköisesti kevyemmin kuin tällä kurssilla tullaan tarvitsemaan.

Tässä ei mennä minkään esitiedon osalta kovin syvälle yksityiskohtiin tai teoriaan, vaan käsitellään aiheet pintapuolisesti sen verran kuin tämä johdantokurssi vaatii. Tietotekniikan ammattilaiseksi haaveilevan tulee enemmin tai myöhemmin oppia näistäkin aiheista paljon enemmän kuin tällä kurssilla tarvitaan. Aloittelijalle tai sivuaineopiskelijalle tämä luku on selviytymisopas, jonka aiheisiin voi myöhemmin sukeltaa syvemmälle toisilla kursseilla, mikäli kiinnostus herää. ⁶

2.1 Pari sanaa ohjelmoinnista (välttämätön esitieto)

Oman tiedekuntamme kurssi Ohjelmointi 1 tai jokin vastaava ohjelmoinnin peruskurssi on ehdoton esitieto tämän kurssin seuraamiselle. Kertaa siis mahdollisimman pian, mikäli erityisesti seuraavat asiat (poimittuna suoraan kevään 2015 Ohjelmointi 1 -kurssin sisällysluettelosta⁷ ) eivät ole vähintään käsitteen ja C#/Java/C++/C -kielisen lähdekoodin kirjoittamisen tasolla tuttuja. Hakasulkeissa on lisätty kommentteja suhteesta tähän kurssiin:

• Ohjelman kääntäminen ja ajaminen [ainakin Visual Studiossa tai muussa IDE:ssä; tällä kurssilla tehdään samoja asioita komentoriviltä. Myös useissa IDEissä käännös tapahtuu konepellin alla loppujen lopuksi komentorivillä, jossa IDE:n graafisessa asetusikkunassa säädettyjen muutosten perusteella kääntäjäohjelmalle annetaan käännöskomennon yhteydessä argumentteja, jotka vaikuttavat siihen, millainen lopputuote pullahtaa ulos. Esimerkiksi julkaistava lopputuote tehdään eri argumenteilla kuin debugattava kehitysversio.]
• Ohjelman rakenne: nimiavaruus, luokka, pääohjelma, aliohjelmat [tämän kurssin työkaluilla periaatteessa ei ole käytettävissä nimiavaruuksia eikä luokkia, mutta pää- ja aliohjelmia on; eli siinä mielessä on jopa hiukan yksinkertaisempaa kuin Ohjelmointi 1:llä:)]
• Algoritmeista: Algoritminen ajattelu, Tarkentaminen, Yleistäminen, Algoritmin kirjoittaminen ja suunnittelu [liittyy kaikkeen ohjelmien tekoon, mukaan lukien käyttöjärjestelmiin]
• Kirjastot [käsitteen tasolla]
• Aliohjelmat: Kutsuminen, Kirjoittaminen [+erityisesti parametrien välitys kutsun yhteydessä]
• [Muuttujat]: Muuttujan määrittely, [esim. C#:n] alkeistietotyypit, Nimeäminen, Arvon asettaminen muuttujaan, Näkyvyys [erityisesti erot luokkamuuttujan, aliohjelman lokaalin muuttujan ja aliohjelman parametrien välillä], Vakiot, Aritmeettiset lausekkeet
• Oliotietotyypit: Mitä oliot ovat, Luominen, Oliotietotyypit vs alkeistietotyypit, Metodin kutsuminen. [Olion tuhoaminen ja roskienkeruu hyvä tietää; käyttöjärjestelmissä puhutaan näitä sivuavista asioista jonkin verran laiteläheisestä muistinhallinnan näkökulmasta]
• Aliohjelman paluuarvo
• Debuggaus [eli mistä debuggauksessa on kyse; mitä tarkoittaa ohjelman askeltaminen rivi kerrallaan, miten asetetaan pysähtymispisteitä eli breakpointteja ja tarkastellaan muuttujien/olioiden sisältöä ohjelman ollessa pysäytettynä; tällä kurssilla debugataan tekstipohjaisella gdb-ohjelmalla, jossa tehdään olennaisesti ihan samoja ykköskurssilta tuttuja asioita!]
• Syntaksivirheiden etsintä, Koodin täydennystyökalut ja koodimallit [napatkaa tästä idea tehokäytön tavoiteltavuudesta, näppäinyhdistelmistä, ympäristön lisäasetuksista ym.; tällä kurssilla emme käytä IDEä, mutta vastaavalla tavalla opetellaan bashin ja tekstieditorien tehokäyttöä]
• Merkkijonot [muistettava perusidea ”jonosta, joka muodostuu peräkkäisistä merkeistä” sekä lähdekoodiin kirjoitetun merkkijonoilmaisun (engl. string literal) kirjoittamisesta esim. C#:ssa lainausmerkkien väliin; tällä kurssilla käydään läpi merkkijonon mahdollista toteutusta laitteistotasolla ja erityisesti C-kielessä; shellin käytössä on ymmärrettävä merkkijonon rooli myös]
• Ehtolauseet: if, if-else, if-else if-...-else, switch-case. Vertailuoperaattorit. Loogiset operaatiot.
• Taulukot: Luominen, Alkioon viittaaminen, Moniulotteiset taulukot
• Toistorakenteet: while, do-while, for, for-each, Sisäkkäiset silmukat, break- ja continue -lauseet, ikuinen silmukka [näiden on oltava tarkasti selvillä käsitteen ja jonkin rakenteisen ohjelmointikielen koodin tasolla; tällä kurssilla sovelletaan samaa C-kielen ja bash-skriptikielen syntakseilla]
• Lukujen esitys tietokoneessa, ASCII-koodi (hmm, joko UTF pitäisi lisätä mukaan?)
• Rekursio [Tällä kurssilla on mahdollista saada oivallinen konkreettinen esimerkki, jolla aiempaa alustavaa ymmärrystä rekursiosta saataisiin ehkä syvennettyä; toivottavasti ehditään näkemään sellainen kurssin mittaan]
• Dynaamiset tietorakenteet [olennaista on idea dynaamisuudessa eli vaihtuvakokoisuudessa; tällä kurssilla tätä konkretisoidaan muistin tarpeen ja muistinhallinnan kannalta]
• (Tällä nimenomaisella kurssilla tarvitsemme todennäköisesti hyvin vähän seuraavia Ohjelmointi 1:n sinänsä tärkeitä osioita: Merkkijonojen pilkkominen, Järjestämisalgoritmi, Valmiit järjestysalgoritmit, Poikkeukset, Olioluokkien dokumentaatio)

  [Paitsi tarkemmin ajatelle…merkkijonoja ehkä tullaan pilkkomaan shellin työkaluilla tavalla tai toisella, työkaluohjelmaa sort käytetään jo ensimmäisessä demossa syöterivien leksikografiseen järjestämiseen, poikkeusten lähtökohtainen syy voi useimmitenkin olla käyttöjärjestelmän hallinnoimassa laitteistossa, …ja mitä tulee dokumentaatioon, niin tällä kurssilla silmäillään vähintään läpi POSIXia ja AMD64 -prosessoriarkkitehtuuria, joten kaukana ei tosiaankaan olla dokumentaation lukemisesta (ja omat ohjelmathan tulee aina dokumentoida tarpeen vaatimalla tavalla)]

Kerratkaa, kerratkaa, kaikki edellä mainitut kohteet ohjelmointi 1:n kurssimateriaalista tarvittaessa. Jatkossa oletetaan edellämainitut asiat tunnetuiksi sillä tasolla, millä ne on ehditty esitietokurssilla harjaannuttaa! – Aivan luonnollista on, että tässä vaiheessa käsitteet saattavat olla vielä sekaisin ja asiat levällään. Kokemus on tämän realismin näyttänyt, ja opettajat ymmärtävät sen kyllä. Olemme valmistautuneet auttamaan myös esitietojen kertaamisessa (ja mahdollisesti ymmärtämisessä ensimmäisen kerran, jos niikseen tulee…). Rohkeasti eteenpäin vain – kokonaisuus hahmottuu asia kerrallaan!

2.2 Abstrakteja tietorakenteita ja niiden toteutuksia

Seuraavassa tietorakenteiden esittelyssä tulee ensimmäistä kertaa vastaan tärkeä termi muistiosoite (engl. memory address), jolle haetaan tarkempaa ymmärrystä pitkin kurssia, kun puhutaan enemmän C-ohjelmoinnista, konekielestä ja käyttöjärjestelmän vastuulla olevasta muistinhallinnasta. Tämän aliluvun tarpeisiin riittää mielikuvamalli, jossa ymmärrät muistiosoitteen olevan kokonaisluku, joka ilmoittaa yhden pienen tietoalkion sijainnin tietokoneessa. Ajattele vaikka ruutupaperia, johon mahtuu jokaiseen ruutuun yksi kaksinumeroinen luku (siis 00–99). Ensimmäisen muistiruudun osoite on 0, seuraavan 1, sitä seuraavan 2 ja niin edelleen. Paperiarkissa on vain tietty määrä ruutuja, sanotaan N kappaletta, jolloin viimeisen paperiin mahtuvan tiedonmurusen osoite on N − 1. Peräkkäiset osoitteet vastaavat siis paperissa olevia peräkkäisiä ruutuja, joissa olevia tietoja voidaan osoittaa osoitenumeroinnin avulla. Mielikuvamalli tietokoneen muistista ja muistiosoitteista tarkennetaan kurssin mittaan teknisesti oikeellisemmaksi, mutta se vaatii pohjustusta enemmän kuin tähän esitietolukuun mahtuu.

Alkeistyyppinen data, oliot, tietorakenteet

Edeltävän ohjelmointikurssin pohjalta oletetaan täysin selväksi, miten yksittäistä muuttujaa tai tietoalkiota käsitellään. Puhutaan siis esimerkiksi seuraavanlaisesta ohjelmakoodista jollakin yleisesti tunnetulla tyypitetyllä ohjelmointikielellä kirjoitettuna:

Tässä esimerkissä annetaan nimi a muuttujalle, jonka tyypiksi tulee kokonaisluku (engl. integer) eli int ja arvoksi 10 koodinpätkän alussa. Koodia suoritetaan C:n tapaisissa kielissä, kuten C++:ssa, C#:ssa tai Javassa, peräkkäin, jolloin edellisten koodirivien jälkeen muuttujan a sisältö tulisi olemaan 3. Näissä kielissä suoritusjärjestystä muutellaan tarvittaessa kirjoittamalla ohjelmaan kontrollirakenteita, kuten ehtoja, silmukoita, aliohjelmakutsuja ja muita Ohjelmointi 1:ltä tuttuja syntaktisia rakenteita. Yksittäisen lohkon sisällä suoritus kulkee yleensä riviltä toiselle ylhäältä alaspäin.

Muuttujan tyyppi voi olla muutakin kuin kokonaisluku, esimerkkejä:

Esimerkin ensimmäinen rivi käsittelee liukulukutyyppiä, joka voi olla kokonaisluvun tapaan yksinkertainen, tietyllä tapaa koodattu datankappale, esim. 64 peräkkäistä bittiä, jotka kuvaavat reaalilukua mahdollisimman läheisesti vaikkapa IEEE 754 -standardin mukaisen koodauksen mukaan. Jälkimmäiset kaksi esimerkkiä ovat kuitenkin esimerkiksi C#:ssa ”vaikeampia” tapauksia⁸ : Ne ovat viitteitä (engl. reference) tiettyyn luokkaan (engl. class) kuuluviin olioihin (engl. object), joiden tarvitsema tallennustila on varattu omasta muistialueestaan, ns. keosta. Olion tilaa käsitellään luokan määrämiä menettelytapoja eli metodeja (engl. method) kutsumalla. Luokat määritellään yksinkertaisimmillaan alkeistietotyypeistä ja olioviitteistä koostamalla seuraavan esimerkin kaltaisesti:

Esimerkissä on käytetty jonkinlaisen C#-maisen oliokielen syntaksia määrittelemään kaksi erilaista tietorakennetta (engl. data structure), joita tosiaan oliokielessä sanotaan luokiksi. Ensimmäinen näistä kuvaa kokonaislukuparia, esimerkiksi ruutupaperin yhden ruudun sijaintia ruutupaperin vasemmasta yläkulmasta lukien (”10 ruutua oikealle ja 5 alaspäin, niin olet perillä”). Jälkimmäinen voisi kuvailla yhden henkilön henkilötietoja jonkin sovelluksen tarpeeseen.

Informaation piilottamista, perintää, rajapintoja ja muita oliokielten herkkuja varten tarvitaan menettelyjä, joihin voi syventyä erikseen muilla kuin tällä kurssilla. Ohjelmointi 2 kertoo perusasiat sovellusohjelmoijan näkökulmasta ja niiden hiomista jatketaan esimerkiksi kursseilla Web-käyttöliittymien ohjelmointi ja Web-palvelinohjelmointi. Olio-ominaisuuksien toteuttamiseen kääntäjäteknologian näkökulmasta meillä on (JY/kevät 2015) kokonainen maisteriohjelma nimeltä Ohjelmointikielten periaatteet, jossa saa lopulta vaikka gradun verran tutkia moniperinnän ihmeellistä maailmaa tai automaattista koodin generointia suunnitteludiagrammien perusteella… Tällä kurssilla päästään helpommalla, koska näitä oliomallinnuksen hienouksia ei tosiaankaan tarvitse juuri nyt miettiä.

Tämän kurssin oliot ovat pääasiassa yksinkertaisia, kiinteän mittaisia datapötköjä, joiden sisäinen rakenne määritellään C-kielessä seuraavankaltaisesti (toimivaksi varmistettuja, C99-standardin mukaisia koodiesimerkkejä tulee sitten demoissa):

Ero edelliseen olioesimerkkiin on, että luokan (class) sijasta puhutaankin yksinkertaisemmasta konseptista eli tietueesta (struct), joka luokan kaltaisesti määrittelee nimiä ja tyyppejä olion ominaisuuksille. Kuitenkaan esimerkiksi metodeja ei voisi määritellä, eikä väkisin piilottaa tietoja rajapinnan taakse (ts. private / protected -ominaisuudet eivät ole olemassa vaan kaikki on public eikä muuta voi), eikä uusia ominaisuuksia voisi helposti lisätä muuten kuin muokkaamalla rakenteen alkuperäistä määritelmää (perintää, engl. inheritance / engl. extends, tai luokkarajapintoja, engl. implements tmv., ei ole mukana kielessä).

Kokonaislukuparihan määritellään tässä olennaisesti samoin kuin aiemmin. Henkilötietojen merkkijonosisältö määritellään kuitenkin nyt kiinteän mittaiseksi: Nimelle ja työpaikalle on varattu tasan 15 merkkiä, joten pidemmät merkkijonot on esimerkiksi katkaistava keskeltä poikki. Sisältönä tässä rakenteessa voisi olla esimerkiksi seuraavaa⁹ :

Tällainen rakenteisen datan tallennusmuoto ei selvästi ole nykypäivän standardein ajateltuna ollenkaan riittävän monipuolinen: Esimerkiksi mielivaltaisen pitkiä merkkijonoja ei voi käyttää. Toisaalta lyhyen merkkijonon, kuten esimerkissä ”JY”, säilömiseen riittäisi vähempikin tila kuin mitä nyt on varattu. Onneksi sovellusohjelmia tehdään nykyään oliokielillä, joiden alustakirjastot tukevat muun muassa merkkijonojen käyttöä monipuolisesti!

Käyttöjärjestelmät saatetaan kuitenkin esimerkiksi tehokkuussyistä tehdä niin sanotusti matalamman tason kielillä, esimerkiksi ”1970-lukulaisella” C-kielellä. Se, että C on vuosikymmeniä vanha, ei tarkoita sitä, että se olisi hyödyttömäksi havaittu ohjelmointikieli – sitä myös kehitetään alati. Uusin standardiversio C18¹⁰ on vuoden 2018 paikkeilta. Uusin POSIX-standardi edellyttää vuonna 1999 kiinnitetyn C99-standardin mukaisen C-kääntäjän löytymistä järjestelmästä (ja käynnistymistä kuorikomennolla c99). Standardointisyistä keväästä 2015 alkaen tämän kurssin esimerkit yrittävät noudattaa C99-standardia. Ei ole kovin nopeaa lukea tarkoin noita monituhatsivuisia standardeja, joten valjastetaan nyt myös kaikkien kurssilaisten silmät varmistamaan standardinmukaisuus ja ilmoittamaan mahdollisista standardirikkomuksista, jotta ne saadaan korjattua! Osa kurssilaisista saattaa olla näiden speksien kanssa tekemisissä päivittäin, kun taas luennoitsija on vain pari kuukautta kerran vuodessa … vasta-alkajat ottakoon standardit kuitenkin vain silmäilyn tasolla, koska kurssin aika on rajallinen! Syventymiseen on aikaa koko loppuelämä.

Käyttöjärjestelmäkurssin osalta C-kielen ja kiinteän kokoisten datamöhkäleiden käyttö selkeyttää asioita – päästään nimittäin näkemään yksinkertaisesti, mutta konkreettisesti, miten rakenteisesti organisoitu data näyttäytyy tietokoneen muistissa. Silloin, kun kiinteänkokoiset datamöhkäleet riittävät sovelluksen tarpeisiin, ovat ne myös kaikkein nopeimpia. Laitteiston, mukaanlukien muistin, luonne ja käskyttäminen on käyttöjärjestelmän tehtävä ja siten tämän kurssin ydinasiaa! Siitä kertyy myös ymmärryspohja, jonka kautta myöhempien, korkeamman abstraktiotason kurssien seuraaminen on toivon mukaan miellyttävämpää tai ainakin vähemmän mystistä.

Siitä huolimatta, ja osittain sen ansiosta, että esimerkeissä käytetään laiteläheistä “matalan abstraktiotason” kieltä eli C:tä, tällä kurssilla saadaan toivon mukaan muun muassa vahva selvyys siihen, miten kaikki data täytyy loppuviimein olla tallennettuna tietokoneen muistissa, miten uusille olioille (tai ylipäätään uudelle datalle) täytyy konkreettisesti varata uutta tilaa muistista ja miten oliot voivat kaikkein yksinkertaisimmillaan viitata toisiin muistissa oleviin olioihin. C-kielen ja assemblerin katseleminen tekee tällaisten tarkastelujen tekemisen helpoksi välttämättömän ja toisaalta helposti nähtäville tulevan konkretian kautta. Prosessorin ja muistin toiminnan ymmärtäminen mahdollistaa myös jämerän ymmärryksen syistä, joiden takia yhdenaikaisten ohjelmien käyttö voi johtaa kilpa-ajotilanteisiin ja sitä kautta lukitusten tarpeeseen.

Perintää ja tiedon piilotusta ei helposti saada, mutta C-kielen tietorakenteeseen voidaan kyllä erittäin helposti määritellä viitteitä muihin rakenteisiin, kuten seuraavassa esimerkissä::

Nyt mielivaltaisen pitkät nimet olisivatkin mahdollisia! Tähtimerkki eli asteriski tietorakenteen kenttien *nimi ja *tyopaikka edessä tarkoittaa, että kyseessä on osoitin (engl. pointer) jossakin muualla sijaitsevaan dataan. Idea on periaatteessa täysin sama kuin olioviitteissä. Toteutus vain on sangen yksinkertainen ja tietokoneen perustoiminnan mukainen: Viimeisen esimerkin mukaisen tietorakenteen määrittelemässä oliossa on tasan kolme kokonaislukua: ensimmäinen on henkilön syntymävuosi, kaksi jälkimmäistä kokonaislukua ovat muistiosoitteita eli kertakaikkiaan sijaintipaikkoja tietokoneen muistissa, joihin voidaan varata tilaa vaikka miljoonan merkin mittaiselle merkkijonolle. Loppuun asti ei tarvitse asiaa ymmärtää vielä, mutta se on tavoite hahmottaa demojen ja luentoesimerkkien kautta heti, kun mahdollista.

Taulukot

Selvää aiemman kurssin pohjalta tulee olla muuttujista muodostettujen taulukoiden (engl. array) kayttö ohjelmissa. Esimerkiksi:

Taulukossa on peräkkäin samantyyppisiä tietoyksiköitä, joihin pääsee käsiksi indeksin perusteella. Esimerkissä tehdään ensin seitsemän kokonaislukua sisältävä taulukko, jossa on lottorivi. Sitten taulukon viimeiseen alkioon sijoitetaan uusi arvo. Taulukon olennainen piirre on, että se on kiinteän mittainen ja jokaiseen alkioon päästään käsiksi indeksillä (suoraan, kulkematta kiertoteitä eli todennäköisesti myös salamannopeasti). Indeksit alkavat C-mäisissä kielissä, kuten C#:ssa, nollasta, joten lottorivi[6] tarkoittaa seitsemättä alkiota ensimmäisestä eteenpäin laskien. Varmistu asiasta kynällä ja paperilla tarvittaessa.

Kuvassa 3 on esimerkit kahdesta taulukosta, jotka on koostettu kiinteänmittaisista tietotyypeistä. Ensimmäiseksi on kokonaislukutaulukko, joka kuvaa lottoriviä. Jokainen alkio on kokonaisluku. Yksinkertaisimmillaan taulukko voidaan tallentaa tietokoneen muistissa seitsemään peräkkäiseen kokonaisluvun mittaiseen tilaan (esim. 32 bittiä jokaista kokonaislukua kohden). Toisena esimerkkinä on taulukko, jossa on peräkkäin kahdesta kokonaisluvusta muodostettuja pareja. Kumpikin kokonaisluku vaatii esimerkiksi 32 bittiä tallennustilaa, joten jokainen kokonaisuus vaatii 2 × 32 = 64 bittiä. Koko taulukko voidaan tallentaa peräkkäisiin sijainteihin muistissa, samoin kuin lottorivikin. Kukin viidestä alkiosta on nyt kuitenkin tietorakenne, jossa on kaksi 32-bittistä kokonaislukua. Yhteensä se vaatii muistia siis 5 × 2 × 32 bittiä.

Kiinteän mittaisten C-kielisten tietorakenteiden tallennus muistiin kiinteän mittaisena taulukkona on selkeätä: ensimmäisen elementin kenttien arvot sijaitsevat peräkkäin ensimmäisestä muistipaikasta alkaen. Sen jälkeen tulevat samassa sisäisessä järjestyksessä kaikkien muiden taulukossa sijaitsevien elementtien kenttien arvot. Tällaisessa taulukossa kaikki elementit ovat samantyyppisiä, joten ne ovat myös keskenään saman mittaisia. Taulukon alusta voidaan siis erittäin helposti laskea, mikä on sen muistipaikan osoite, josta tietyn elementin tiedot alkavat:

Tietorakenteita, joita tällä kurssilla tarvitaan

Edellä mainitut alkeistietotyypit, alkeistietotyyppien ja mahdollisesti muistiosoitteina toteutettujen viitteiden muodostamat yhdistelmätietorakenteet sekä edellämainituista muodostuvat indeksoidut taulukot ovat kaikkein yksinkertaisimpia tapoja tiedon säilyttämiseen ja käsittelemiseen tietokonelaitteistossa. Ne otetaan tällä kurssilla selkäytimeen konkretian kautta C- ja konekielidemoissa. Lisäksi esimerkiksi tämän kurssin kaikkein keskeisimmät tietorakenteet, prosessielementti ja niistä muodostuva prosessitaulu voitaisiin toteuttaa jopa näillä erittäin simppeleillä rakenteilla. Arvosanan 1 perusvaatimukset ylittävänä päämääränä kurssilla on ymmärtää jotakin esim. oikean Linux-ytimen tietorakenteiden määrittelystä ja hyödyntämisestä tutkimalla konkreettista lähdekoodia.

Monissa sovelluksissa, mukaanlukien käyttöjärjestelmän joidenkin osioiden toiminta, tarvitaan kuitenkin aavistuksen verran monimutkaisempia tietorakenteita kuin pelkät peräkkäiset datapötköt. Tarkempi teoria monipuolisempiin tietorakenteisiin sekä niiden käsittelyyn käydään läpi jatkokursseilla nimiltään Algoritmit 1 ja 2. Tällä kurssilla pärjätään, kun ymmärretään vähintään käsitteellisellä ja kaaviokuvien tasolla aivan muutama ns. abstrakti tietorakenne (engl. abstract data structure). Teoriastakaan ei tarvitse toistaiseksi paljoa tietää, koska asiat ovat käyttöjärjestelmien osalta pitkälti arkijärjellä ymmärrettävissä¹¹ .

Termissä abstrakti tietorakenne osuus abstrakti tarkoittaa sitä, että tällaisella tietorakenteella halutaan yleistää eli abstrahoida jokin ilmenevä tai toivottu käyttäytymis- tai toimintamalli riippumatta siitä, millaisia olioita kyseiseen käyttäytymiseen osallistuu. Abstrakteista rakenteista tällä kurssilla tullaan käsittelemään ainakin kolmea: jono, pino ja puu. Käydään seuraavaksi läpi olennaisten piirteiden, reaalimaailman analogioiden, kaaviokuvien ja tähän kurssiin liittyvien ennakoivien mainintojen kautta läpi jokainen näistä. Kuvassa 4 näkyy ensimmäisenä lista, jonka erityistapauksia kuvassa myös esitettyjen jonon ja pinon voidaan ajatella olevan.

Lista (engl. list) on tietorakenne, joka kuvaa järjestettyä, vaihtuvankokoista, joukkoa joitakin olioita. Jos lista ei ole tyhjä, sen pää (engl. head) viittaa listan ensimmäiseen alkioon. Listan muut alkiot kuin ensimmäinen muodostavat listan hännän (engl. tail). Vaikkei välttämätöntä, on näppärää pitää yllä myös viitettä loppuun, eli listan viimeiseen elementtiin (engl. last). Reaalimaailman esimerkki on helppo löytää vaikkapa suomenkielisestä lauseesta ”Luentosalista löytyivät tiistaina henkilöt Tomi, Paavo, Seppo ja Jarno”. Kevään 2015 eräällä luennolla nimettyjä, salista löytyneitä henkilöitä on tässä listattu suomenkielisenä järjestettynä listana, jossa Tomi on keulassa eli kirjoitusjärjestyksessä ensimmäisenä mainittu. Jokaisen henkilön osalta voidaan ainakin lauserakenteen mukaisesti sanoa, kuka on seuraava (se on aina se, jonka nimi on kirjoitettu pilkun jälkeen). Listaa yleisesti ottaen voidaan muokata esimerkiksi poistamalla sieltä olio, esim. Paavon poistamisen jälkeen em. listaan jäisi järjestyksessä ”Tomi, Seppo, Jarno”. Listaan voi myös lisätä olioita eri kohtiin. Esimerkiksi voitaisiin lisätä ”Ismo” johonkin kohtaan, vaikkapa ”Sepon” jälkeen, jolloin lopputulemana olisi lista ”Tomi, Seppo, Ismo, Jarno”. Listan ominainen piirre on, että sitä voidaan käydä läpi ainoastaan järjestyksessä, keulasta alkaen, kustakin oliosta yksi kerrallaan seuraavaan selaamalla. Indekseillä ei voi peruslistan keskelle hypätä, vaan täytyy selata läpi indeksin mukainen määrä viitteitä aina seuraavaan elementtiin.

Jono (engl. queue) on lista, johon lisätään aina loppuun ja otetaan pois keulilta. Reaalimaailman esimerkki: Piato-ravintolan ruokajonossa on tällä hetkellä Tomi, Paavo, Seppo ja Jarno. Tomia palvellaan ja hän saa lounaan; poistetaan ruokajonosta, jolloin jonossa on Paavo, Seppo ja Jarno. Kaisa saapuu jonoon, jolloin jonossa on Paavo, Seppo, Jarno ja Kaisa. Ulla saapuu jonoon, jolloin jonossa on Paavo, Seppo, Jarno, Kaisa ja Ulla. Paavoa palvellaan ja hän saa lounaan, jolloin jonossa on Seppo, Jarno, Kaisa ja Ulla. Seppoa palvellaan ja hän saa lounaan, jolloin jonossa on Jarno, Kaisa ja Ulla …Tähän kurssiin liittyvä ennakoiva sovellus: (1) prosessoriaikaa odottavien prosessien jono (2) viestijono, jossa prosessille tarkoitetut viestit odottavat pääsyä prosessin käsittelyyn. (3) resurssin lukituksen aukenemista odottavien prosessien jono.

Pino (engl. stack) on lista, johon lisäys ja poisto tapahtuvat samasta päästä. On sitten toteutusyksityiskohta, tapahtuuko lisäys ja poisto listan alkuun vai loppuun. Esim. jos toteutustapa on taulukko, on edullisinta lisätä ja poistaa viimeinen alkio, mutta jos toteutustapa on linkitetty lista, kannattaa lisäys ja poisto tehdä listan alkuun. Reaalimaailman esimerkki: pelikorttipino, johon tietyn pasianssin sääntöjen mukaan saa laittaa kortin päällimmäiseksi – alempia kortteja ei saa alta edes nähdä. Vain päällimmäisenä näkyvän kortin saa ottaa käyttöön pelin sääntöjen mukaisesti. Tähän kurssiin liittyvä ennakoiva sovellus: (1) Aliohjelma-aktivaatioista muodostuva kutsupino abstraktina käsitteenä (2) pinon konkreettinen toteutus muistialueena prosessin virtuaalimuistissa (3) erillinen käyttöjärjestelmäpino järjestelmäkoodin aktivaatioille.

Puu (engl. tree) on matemaattisesti ”verkko, jossa ei ole yhtään silmukkaa”. Reaalimaailman esimerkki kuvasta 5: Puussa on juuri, haaroja ja lehtiä. Teknisesti näitä rakenteen solmupisteitä voi kutsua solmuiksi (engl. node). Kuvassa 6 on abstrakti puu piirrettynä tavanomaisella tavalla, jossa juurisolmu (engl. root node) on ylimpänä ja puu ”kasvaa” alaspäin kohti lehtisolmuja (engl. leaf node). Tähän kurssiin liittyvä ennakoiva sovellus: (1) hakemistopuu, esim. JY:n suorakäyttökoneilla toimii komento tree ~, jolla voi nähdä oman kotihakemiston haaromisen alihakemistoihin ja lehtisolmuina ilmeneviin tiedostoihin. (2) prosessipuu, esim. komennolla ps -ef --forest voi visualisoida suorakäyttökoneen kaikkien käyttäjien kaikki prosessit puurakenteena.

Abstraktit tietorakenteet voidaan kuvailla ohjelmointikielessä viitteiden – ja laiteläheisessä C-kielessä yksinkertaisesti muistiosoitteiden – avulla. Esimerkiksi listan elementti voisi olla seuraavanlainen:

Hieman helpommaksi listan käsittely saadaan laittamalla elementteihin tieto seuraajan lisäksi myös edeltäjästä:

Tämän viimeksi mainitun listaelementin koko on 64-bittisessä tietokoneessa 3 × 64 = 192 bittiä eli 24 kasibittistä tavua. Miksi? Siihen sisältyy kolme 64-bittisenä muistiosoitteena ilmenevää viitettä. Ensimmäinen viite osoittaa varsinaiseen olioon, jota tämä yleisen listamallin elementti käsittelisi. Se voi itsessään olla minkä tahansa kokoinen; lista toteuttaa vain abstraktin listamaisuuden ja itse oliot voivat olla mitä tahansa tarkoitusta varten.

Tämä riittänee meille toistaiseksi tietorakenteista. Demoissa ja luennoilla pitäisi tulla sitten lisää konkretiaa esimerkkien kautta. Paljon lisää erilaisista abstrakteista tietorakenteista ja niiden toteuttamisesta ja soveltamisesta tulee siis kursseilla Algoritmit 1 ja 2.

2.3 Tietokonelaitteisto

Digitaalinen laskin (engl. digital computer), jota on totuttu nimittämään sanalla tietokone, toimii tietyssä mielessä erittäin yksinkertaisesti. Kaikki niin sanottu tiedon tai varsinkin informaation käsittely, jota digitaalisella laskimella ilmeisesti voidaan tehdä, on täysin ihmisen toteuttamaa (ohjelmia ja järjestelmiä luomalla), eikä kone taustalla tarjoa paljonkaan tietoa tai älykkyyttä, vaikka onkin älykkäiden ihmisten luoma sähköinen automaatti, joka nykypäivänä sisältää suuren joukon apujärjestelmiä jo sisälläänkin. Tietokone ensinnäkin osaa käsitellä vain bittejä (engl. binary digit, bit) eli kaksijärjestelmän numeroita, nollia ja ykkösiä. Bittejä voidaan yhdistää – esim. kahdeksalla bitillä voidaan koodata 256 eri kokonaislukua. Bitit ilmenevät koneessa sähköjännitteinä, esimerkiksi jännite välillä 0 – 0.8V voisi tarkoittaa nollaa ja jännite välillä 2.0 – 3.3V ykköstä. Bittejä voidaan tallentaa myös pitkäaikaisiin tallenteisiin, jolloin esimerkiksi magnetoituvan materiaalin magneettikenttä käännetään enemmän tai vähemmän pysyvästi yhteen suuntaan silloin kun bitti on ykkönen ja vastakkaiseen suuntaan kun se on nolla – magneettinauhat ja kovalevyt perustuvat tähän. Vielä pidempiaikainen tallenne saadaan, kun fyysisesti kaiverretaan johonkin materiaaliin kuoppa nollabitin kohdalle ja jätetään kaivertamatta ykkösbitin kohdalta. Kiveen kaiverrettuna peräkkäiset bitit säilyisivät käytännössä ikuisesti, toisin kuin nykyisissä magneettisissa välineissä, joiden magneettikentillä on taipumus jollain aikavälillä palautua fysiikan lakien mukaisesti epämääräiseen, satunnaiseen orientaatioon¹² .

Bittien käsittelyltä ei voida tietokoneissa välttyä, joten käydään seuraavaksi lyhyesti läpi lukujärjestelmien perusteita.

2.3.1 Lukujärjestelmät

Ihmiset ovat tottuneet laskemaan kymmenjärjestelmän luvuilla, mutta kun ollaan tietokoneiden kanssa tekemisissä, on ymmärrettävä myös binäärijärjestelmää. Idea on helppo ja sama kuin kaikissa kantalukuun perustuvissa lukujärjestelmissä: yksi bitti on ykkönen tai nolla. Jos luvussa on useampia bittejä, ilmoittaa jokainen bitti (0 tai 1) aina, kuinka monta vastaavaa kantaluvun kaksi potenssia lukuun sisältyy. Kymmenjärjestelmän luvuissahan jokainen numero (0, 1, 2, 3, 4, 5, 6, 7, 8 tai 9) ilmoittaa, kuinka monta vastaavaa kantaluvun kymmenen potenssia lukuun sisältyy. Esimerkki samasta lukumäärästä 123 kymmenjärjestelmän ja binäärijärjestelmän kirjoitusasussa: Kymmenjärjestelmässä 123₁₀ = 1 ⋅ 10² + 2 ⋅ 10¹ + 3 ⋅ 10⁰ = 100 + 20 + 3 = 123. Binääri- eli kaksijärjestelmässä 1111011₂ = 1 ⋅ 2⁶ + 1 ⋅ 2⁵ + 1 ⋅ 2⁴ + 1 ⋅ 2³ + 0 ⋅ 2² + 1 ⋅ 2¹ + 1 ⋅ 2⁰ = 64 + 32 + 16 + 8 + 0 + 2 + 1 = 123. Kantalukua ilmaiseva alaindeksi on tässä ja myöhemmissä esimerkeissä kirjoitettu pääsääntöisesti vain muihin kuin kymmenjärjestelmän lukuihin.

Binääriluvut ovat siis ainoa tietokoneen ymmärtämä lukujärjestelmä. Vähänkään suuremmat binääriluvut ovat pitkiä ja siksi tikkuisia tulkita ja kirjoittaa. Nykyiset tietokoneet käsittelevät monia asioita 64-bittisinä ja esimerkiksi salausavaimia sitäkin useammilla biteillä. Paljon helpompaa bittien tulkitseminen on kuusitoistajärjestelmässä eli heksadesimaalijärjestelmässä¹³ . Puhutaan ammattijargonilla lyhyesti heksaluvuista eli heksoista. Kyseessä on ihan samanlainen järjestelmä kuin muutkin lukujärjestelmät, jossa jokainen luvun numero (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E tai F) ilmoittaa, montako vastaavaa kantaluvun kuusitoista potenssia lukuun sisältyy. Kirjainten A-F (tai pienten kirjainten a-f) käyttäminen lukumääriä 10, 11, 12, 13, 14 ja 15 ilmaisevina heksanumeroina on vain käytäntö – yhtä hyvin symbolit voisivat olla sydämiä, peukkuja ja hymynaamoja. Pitäydytään kuitenkin vallitsevan käytännön mukaisissa heksanumeroissa, niin ei tule sekaannuksia. Esimerkiksi luku 123 on heksajärjestelmässä 7B₁₆ = 7 ⋅ 16¹ + 11 ⋅ 16⁰ = 123. Symboli ’B’ vastaa siis lukumäärää 11 meille tutuimmassa kymmenjärjestelmässä.

Miten niin heksaluvut ovat näppäriä, kun mietitään bittejä? Koska kantaluku 16 on kakkosen potenssi, tarkkaan ottaen neljäs potenssi, 16 = 2⁴, vastaa jokainen heksanumero yksi-yhteen neljää bittiä luvun binääriesityksessä, esim. 111 1011₂ = 7B₁₆. Nyt ei tarvitse muistella kerrallaan kuin jokaisen heksanumeron vastaavuutta neljän bitin sarjan kanssa, niin voidaan kuinka tahansa pitkiä bittilukuja muuttaa vaivatta pitkästä binääriesityksestä lyhyeen heksaesitykseen. Tässä kirjoittajan apinahakkauksella toteuttama satunnainen binäärilukuesimerkki muunnettuna heksoiksi päässälaskien: 10 1010 0101 1011 0001 0101₂ = 2A5B15₁₆. Tarkista itse, menikö muunnos oikein.

Joissain yhteyksissä voi olla mielekästä käyttää myös oktaali- eli kahdeksanjärjestelmää eli oktaalilukuja. Jokainen oktaaliluvun numero (0, 1, 2, 3, 4, 5, 6 tai 7) ilmoittaa tietenkin montako kertaa kantaluku kahdeksan vastaava potenssi esiintyy luvussa. Kantaluku kahdeksan on kakkosen kolmas potenssi, joten oktaaliluvun numerot vastaavat kolmen bitin yhdistelmiä. Edelliset esimerkit ovat siis 1 111 011₂ = 173₈ ja 1 010 100 101 101 100 010 101₂ = 12455425₈.

Ohjelmointikielissä ja kirjallisuudessa on vakiintunut useita erilaisia tapoja ilmoittaa, että jokin vakioluku on kirjoitettu jossakin tietyssä edellä käsitellyistä lukujärjestelmistä. Oletus on yleensä kymmenjärjestelmä, mikäli on kirjoitettu pelkkä luku, vaikkapa 123. Heksaluvut kirjoitetaan aika usein (esimerkiksi C#, Java, C++ ja C -lähdekoodeissa) niin, että niiden alkuun lisätään merkit 0x eli nolla ja pieni äksä, esimerkiksi 0x7B tai 0x2A5B15. Oktaaliluvut kirjoitetaan aika usein niin, että niiden alkuun lisätään merkki ”0” eli ylimääräinen nolla, esimerkiksi 0173. Varo siis vaaraa, kun ohjelmoit: lähdekoodissasi 0123 tarkoittaa luultavasti aivan erilaista lukumäärää kuin kymmenjärjestelmän 123! Jossain kielissä (tuskin kuitenkaan C:ssä ja jälkeläisissä…) binääriluvut kirjoitetaan laittamalla niiden perään pieni b-kirjain, esim. 1111011b. Binäärilukuja kuitenkin harvemmin kirjoitetaan sellaisenaan. Ohjelmoijalle on selvää, että 0xFF tarkoittaa 8-bittistä lukua, jonka kaikki bitit ovat ykkösiä, 0xFE tarkoittaa 8-bittistä lukua, jossa kaikki paitsi vähiten merkitsevä bitti ovat ykkösiä, 0xAAAA tarkoittaa 16-bittistä lukua, jossa joka toinen bitti on ykkönen ja joka toinen nolla (ja niin edelleen...). Jos käytössä on 64-bittinen tallennustila, suurin mahdollinen etumerkitön kokonaisluku, jota voidaan käsitellä on 0xFFFFFFFFFFFFFFFF. Yritys lisätä tähän ykkönen ja tallentaa syntyvä 65-bittinen tulos 0x10000000000000000 aiempaan 64-bittiseen tallennustilaan tyypillisesti pyöräyttää lukualueen vaivihkaa ympäri ja tuloksena onkin nolla¹⁴ .

Joissain yhteyksissä, varsinkin työkaluohjelmien tulosteissa tai salausavaimissa ymv., ei ole mitään erityistä merkintää siitä, että luvut ovat heksoja. Usein nämä tulosteet tulevat kuitenkin vastaan siinä vaiheessa, kun jo tiedät, että haluat nähdä tai kirjoittaa nimenomaan heksalukuja. Nykyisin bittejä on tyypillistä ajatella kahdeksan bitin paketteina eli tavuina. Jokaista tavua vastaa näppärästi kaksinumeroinen heksaluku. Tietokoneen datan tarkastelu mikrotasolla on helppoa juuri tavujen heksaesityksiä tutkimalla. Kurssin luennoilla ja demoissa tullaan tekemään tätä käytännössä työkaluohjelmien avulla.

2.3.2 Yksinkertaisista komponenteista koostettu monipuolinen laskukone

Tietokone valmistetaan yksinkertaisista elektroniikkakomponenteista koostamalla. Toki kokonaisuus sisältää erittäin suuren määrän komponentteja, jotka muodostavat monimutkaisen, osin hierarkkisen ja osin modulaarisen rakenteen. Suunnittelussa ja valmistusteknologiassa on tultu pitkä matka tietokoneiden historian aikana. Peruskomponentit ovat kuitenkin yhä tänä päivänä puolijohdetekniikalla valmistettuja, pienikokoisia elektronisia laitteita (esim. transistoreja, diodeja, johtimia) joista koostetaan logiikkaportteja (engl. logic gate) ja muistisoluja (engl. memory cell). Logiikkaportin tehtävä on suorittaa biteille jokin operaatio, esimerkiksi kahden bitin välinen AND (ts. jos portin kahteen sisääntuloon saapuu molempiin ykkönen, ulostuloon muodostuu ykkönen ja muutoin nolla). Muistisolun tehtävä puolestaan on tallentaa yksi bitti myöhempää käyttöä varten. Peruskomponenteista muodostetaan johtimien avulla yhdistelmiä, jotka kykenevät tekemään monipuolisempia operaatioita. Komponenttiyhdistelmiä voidaan edelleen yhdistellä, ja niin edelleen. Esimerkiksi 8-ytimisessä Intel Xeon 7500 -prosessorissa on valmistajan antamien tietojen mukaan yhteensä 2300000000 transistoria, joista koostuva rakennelma pystyy tekemään biteille jo yhtä ja toista. Kuitenkin pohjimmiltaan kyseessä on ”vain” bittejä paikasta toiseen siirtelevä automaatti.

Nykyaikainen tapa suunnitella tietokoneen perusrakenne on pysynyt pääpiirteissään samana yli puoli vuosisataa. Kuvassa 7 esitetään tietokone kaikkein yleisimmällä tasolla, jonka komponenteilla on tietyt tehtävänsä. Tietokoneessa on keskusyksikkö (engl. CPU, Central Processing Unit) eli suoritin eli prosessori (engl. processor), muisti (engl. memory) ja syöttö- ja tulostuslaitteita eli I/O-laitteita (engl. Input/Output modules). Komponentteja yhdistää väylä (engl. bus)¹⁵ . Keskusyksikkö hoitaa varsinaisen biteillä laskemisen, käyttäen apunaan muistia. I/O -laitteisiin lukeutuvat muiden muassa näppäimistö, hiiri, näytönohjain, kovalevy, DVD, USB-tikut, verkkoyhteydet, printterit ja monet muut laitteet. Toimintaa ohjaavalle prosessorille nämä erilaiset I/O -laitteet näyttävät kaikki hyvin samanlaisilta, mihin asiaan palataan kurssilla myöhemmin.

Väylää voi ajatella rinnakkaisina johtimina, eli kaapelina elektronisten komponenttien välillä. Kussakin johtimessa voi tietenkin olla kerrallaan vain yksi bitti, joten esimerkiksi 64 bitin siirtäminen kerrallaan vaatii 64 rinnakkaista sähköjohdinta. Kaapeleita tarvitaan useita, että väylän ohjaus ja synkronointi voi toimia, erityisesti ainakin ohjauslinja, osoitelinja ja datalinja. Näillä voi olla kaikilla eri leveys. Esimerkiksi osoitelinjan leveys voisi olla 38 johdinta (bittiä) ja datalinjan leveys 64 bittiä. Käytännössä tämä tarkoittaisi, että väylää pitkin voi päästä käsiksi korkeintaan 2³⁸ eri paikkaan ja kuhunkin osoitettuun paikkaan (tai sieltä toiseen suuntaan) voisi siirtää kerrallaan maksimissaan 64 bittiä.

Sanotaan, että prosessorin ulkopuolella kulkevan osoiteväylän leveys (bittijohdinten lukumäärä) määrittelee tietokoneen fyysisen osoiteavaruuden (engl. physical address space) laajuuden eli montako muistiosoitetta tietokoneessa voi olla. Muistia ajatellaan useimmiten kahdeksan bitin kokoelmien eli tavujen (engl. byte) muodostamina lokeroina, jollaista jokainen osoite osoittaa. Tästä aiheutuu se, että vaikka dataväylän leveys (bittijohdinten lukumäärä) mahdollistaisi useiden tavujen siirtämisen kerralla johonkin osoitteeseen, on osoitettavissa olevien yksittäisten bittien määrä tavallisissa järjestelmissä osoiteavaruuden koko × 8 bittiä. Esimerkiksi 64-bittinen siirto käyttäisi kahdeksaa peräkkäistä 8-bittistä muistipaikkaa, joista ensimmäisen paikan osoite annetaan ja seuraavia seitsemää peräkkäistä paikkaa käytetään automaattisesti.

Tietokoneen sananpituus (engl. word length) on termi, jolla kuvataan tietyn tietokonemallin kerrallaan käsittelemien bittien määrää (joka saattaa olla sama kuin ulkoisen dataväylän leveys). Tämä on hyvä tietää, kun lukee alan kirjallisuutta, prosessorimanuaaleja ja vastaavia. Kuitenkin tämän monisteen jatkossa tulemme käyttämään toista perinteistä määritelmää sanalle (engl. word): Sana olkoon meidän näin sopien aina kahden tavun paketti eli 16-bittinen kokonaisuus. Näin voidaan puhua myös tuplasanoista (engl. double word) 32-bittisinä kokonaisuuksina ja nelisanoista (engl. quadword) 64-bittisinä kokonaisuuksina. Muiden muassa esimerkkinä käytetyn AMD64-prosessorin dokumentaatio käyttää näitä määritelmiä.

Väylän kautta pääsee käsiksi moniin paikkoihin, ja osoiteavaruus jaetaan usein (laitteistotasolla) osiin siten, että tietty osoitteiden joukko tavoittaa ROM-muistin (engl. Read-Only Memory, joka on vain luettavissa, tehtaalla lopullisesti kiinnitetty tai ainoastaan erityistoimenpitein muutettavissa), osa RAM-muistin (engl. Random Access Memory, jota voi sekä lukea että kirjoittaa ja jota ohjelmat normaalisti käyttävät), osa prosessorin ulkopuolella sijaitsevat lisälaitteet. Nykypäivänä normaalit ohjelmat näkevät itse asiassa niitä varten luodun virtuaalisen osoiteavaruuden – tähän käsitteeseen palataan myöhemmin.

Tietokoneen prosessori toimii nopean kellopulssin ohjaamana: Aina kun kello ”tikittää” eli antaa jännitepiikin (esim. 1 000 000 000 kertaa sekunnissa), prosessorilla on mahdollisuus aloittaa joku toimenpide. Toimenpide voi kestää yhden tai useampia kellojaksoja, eikä seuraava voi alkaa ennen kuin edellinen on valmis¹⁶ .

Myös väylä voi muuttaa johtimissaan olevia bittejä vain kellopulssin lyödessä – väylän kello voi olla hitaampi kuin prosessorin, jolloin väylän toimenpiteet ovat harvemmassa. Ne kestävät muutenkin pidempään, koska sähkösignaalin on kuljettava pidempi matka perille oheislaitteeseen ja aikaa kuluu myös väylän ohjauslogiikan toimenpiteisiin. Operaatiot sujuvat siis nopeammin, jos väylää tarvitaan niihin harvemmin.

Jokainen mahdollinen toimenpide, jonka prosessori voi kerrallaan tehdä, on jotakin melko yksinkertaista — tyypillisimmillään vain rajatun bittimäärän (sähköjännitteiden) siirtäminen paikasta toiseen (”piuhoja pitkin”), mahdollisesti soveltaen matkan varrella jotakin yksinkertaista, ennaltamäärättyä digitaaliloogista operaatiota (joka perustuu siis komponenttien hierarkkiseen yhdistelyyn). Tai tältä se ohjelmien näkökulmasta näyttää. Todellinen toteutustapa on villi vekotin, yli 70-vuotisen digitaalielektroniikan kehitystyön kompleksinen tulos, mutta se on piilossa rajapinnan takana, eikä meidän tarvitse tietää kuin rajapinta voidaksemme käyttää järjestelmää! Rajapinta puolestaan on tarkoituksella suunniteltu (rajoitteiden puitteissa) mahdollisimman yksinkertaiseksi.

Kuva 8 tarkentaa vielä keskusyksikön jakautumista hierarkkisesti alemman tason komponentteihin. Näitä ovat kontrolliyksikkö (engl. control unit), aritmeettislooginen yksikkö (engl. ALU, Arithmetic Logic Unit) sekä tiettyihin tarkoituksiin välttämättömät rekisterit (engl. registers). Tästä alempia laitteistohierarkian tasoja ei tällä kurssilla tarvitse ajatella, sillä tästä kuvasta jo löytyvät esimerkit tärkeimmistä komponenteista joihin ohjelmoija (eli sovellusohjelmien tai käyttöjärjestelmien tekijä) pääsee käsiksi. Alempien tasojen olemassaolo (eli monimutkaisen koneen koostuminen yksinkertaisista elektronisista komponenteista yhdistelemällä) on silti hyvä tiedostaa.

Ylimalkaisesti sanottuna kontrolliyksikkö ohjaa tietokoneen toimintaa, aritmeettislooginen yksikkö suorittaa laskutoimitukset, ja rekisterit ovat erittäin nopeita muisteja prosessorin sisällä, erittäin lähellä muita prosessorin sisäisiä komponentteja. Rekisterejä tarvitaan, koska muistisoluthan ovat ainoita tietokoneen rakennuspalikoita, joissa bitit säilyvät pidempään kuin yhden pienen hetken. Bittejä täytyy pystyä säilömään useampi hetki, ja kaikkein nopeinta tiedon tallennus ja lukeminen on juuri rekistereissä, jotka sijaitsevat prosessorin välittömässä läheisyydessä. Rekisterejä tarvitaan useita, ja joillakin niistä on tarkoin määrätyt roolit prosessorin toimintaan liittyen. Rekisterien kokonaismäärä (välttämättömien lisäksi) ja kunkin rekisterin sisältämien bittien määrä vaihtelee eri mallisten prosessorien välillä. Esimerkiksi Intel Xeon -prosessorissa rekisterejä on kymmeniä ja kuhunkin niistä mahtuu talteen 64 bittiä. Prosessorin sisällä on sisäisiä väyliä, joita kontrolliyksikkö ohjaa ja jotka ovat tietenkin paljon ulkoista väylää nopeampia bitinsiirtäjiä.

2.3.3 Suoritussykli (yhden ohjelman kannalta)

Nyt voidaan kuvan 8 terminologiaa käyttäen vastata riittävän täsmällisesti siihen, mikä itse asiassa on se yksittäinen toimenpide, jollaisen prosessori voi aloittaa kellopulssin tullessa. Toimenpide on yksi kierros toistosta, jonka nimi on nouto-suoritus -sykli (engl. fetch-execute cycle)¹⁷ . Mikäli prosessori on suorittanut aiemman toimenpiteen loppuun, se voi aloittaa seuraavan kierroksen, joka sisältää seuraavat päävaiheet (tässä esitetään sykli vasta yhden ohjelman kannalta; myöhemmin tätä hiukan täydennetään):

• Käskyn nouto (engl. fetch): Prosessori noutaa muistista seuraavan konekielisen käskyn (engl. instruction) eli toimintaohjeen. Karkeasti ottaen käsky on bittijono, johon on koodattu prosessorin seuraava tehtävä. Konekieli (engl. machine language) on näiden käskyjen eli bittijonojen syöttämistä peräkkäin. Prosessori ”ymmärtää” konekieltä, joka on kirjoitettu peräkkäisiin muistipaikkoihin. Ohjelmat voivat olla pitkiä, joten ne eivät mahdu kokonaan talteen kovin lähelle prosessoria. Käskyt sijaitsevat siis muistissa, josta seuraava käsky aina noudetaan väylän kautta¹⁸ . Jotta noutaminen voi tapahtua, täytyy väylän osoitelinjaan kytkeä käskyn muistipaikan osoite. Jotta bittejä voidaan kytkeä johonkin, ne pitää tietenkin olla jossakin säilössä. Seuraavan käskyn osoite on tallessa rekisterissä, jonka nimi on käskyosoitin (IP, engl. instruction pointer). Toinen nimi samalle asialle (kirjoittajasta riippuen) voisi olla ohjelmalaskuri (PC, engl. program counter). Siis elektroniikka kytkee IP -rekisterin osoitelinjaan, odottaa että väylän datalinjaan välittyy muistipaikan sisältö, ja kytkee datalinjan rekisteriin, joka tunnetaan esimerkiksi nimellä käskyrekisteri (INSTR, IR, engl. instruction register). Seuraava käsky on nyt noudettu ja sitä vastaava bittijono on INSTR-rekisterin sisältönä. Prosessori noutaa muistista mahdollisesti myös käskyn tarvitsemat operandit eli luvut, joita operaatio tulee käyttämään syötteenään. Luonnollisesti operandien tulee sijaita sisäisissä rekistereissä tai suoraan väylän datalinjalta ALUn portteihin kytkettynä. ¹⁹
• Käskyn suoritus (engl. execute): Käskyrekisterin sisältö kytkeytyy kontrolliyksikön elektroniikkaan, ja yhteistyössä aritmeettisloogisen yksikön kanssa tapahtuu tämän yhden käskyn suorittaminen. Käsky saattaa edellyttää myös muiden rekisterien sisällön käyttöä tai korkeintaan muutaman lisätiedon noutoa muistista (väylän kautta, osoitteista jotka määräytyvät tiettyjen rekisterien sisällön perusteella; tästä on luvassa tarkempi selvitys myöhemmin esimerkkien kautta).
• Tuloksen säilöminen ja tilan päivitys: Ennen seuraavan kierroksen alkua on huomattava, että käskyn suorituksen jälkeen prosessorin ulospäin näkyvä tila muuttuu. Ainakin käskyosoitinrekisterin eli IP:n sisältö on uusi: siellä on nyt taas seuraavaksi suoritettavan konekielisen käskyn muistiosoite. Usein erityisesti laskutoimituksissa muuttuvat tietyt bitit lippurekisterissä (FLAGS, FLG, FR, engl. flag register), josta käytetään myös englanninkielistä nimeä engl. Program status word, PSW. Jotta laskutoimituksista olisi hyötyä, niiden tulokset täytyy saada talteen johonkin rekisteriin (tai suoraan muistiin, mikä taas edellyttää väylän käyttöä ja sitä että tulokselle tarkoitettu muistiosoite oli tallessa jossakin rekisterissä).
• Sykli alkaa jälleen alusta.

Kohdassa kolme sanottiin että käskyosoittimen sisältö on uusi. Se, kuinka IP muuttuu, riippuu siitä millainen käsky suoritettiin:

• Jokin peräkkäissuoritteinen käsky kuten laskutoimitus tai datan siirto paikasta toiseen → IP:ssä on juuri suoritettua käskyä seuraavan käskyn muistiosoite (siis siinä järjestyksessä kuin käskyt on talletettu muistiin).
• Ehdoton hyppykäsky → IP:n sisällöksi on ladattu juuri suoritetun käskyn yhteydessä ilmoitettu uusi muistiosoite, esim. silmukan ensimmäinen käsky tms.
• Ehdollinen hyppykäsky → IP:n sisällöksi on ladattu käskyssä ilmoitettu uusi osoite, mikäli käskyssä ilmoitettu ehto toteutuu; muutoin IP osoittaa seuraavaan käskyyn samoin kuin peräkkäissuorituksessa. (Ehto tulkitaan koodatuksi FLAGS-lippurekisterin johonkin/joihinkin bitteihin.)
• Aliohjelmakutsu →IP:n sisältönä on käskyssä ilmoitettu uusi osoite (jonka tulee olla kutsuttavan aliohjelman ensimmäinen käsky; aliohjelmakutsussa prosessori tekee muutakin, mitä käsitellään tällä kurssilla tarkemmin)
• Paluu aliohjelmasta →IP osoittaa taas siihen ohjelmaan, joka aiemmin suoritti kutsun, erityisesti kyseessä on aliohjelmakutsua välittömästi seuraava kutsuvan ohjelman käsky. (myöhemmin nähdään, miten tämä on voitu käytännössä pitää muistissa)

Aliohjelmakutsu ja paluu ovat normaalia käskyä hieman monipuolisempia toimenpiteitä, joissa prosessori käyttää myös ns. pinomuistia. Myös pinomuistin käyttöä tutkitaan tarkemmin tulevissa demoissa ja luennoissa.

Lippurekisteri (FLAGS tmv.) puolestaan tallentaa prosessorin tilaan liittyviä on/off -liputuksia, jotka voivat muuttua tiettyjen käskyjen suorituksen seurauksena. Prosessoriarkkitehtuurin määritelmä kertoo, miten mikäkin käsky muuttaa FLAGS:iä. Kolme tyypillistä esimerkkiä voisivat olla seuraavat:

• Yhteenlaskussa (bittilukujen ”alekkain laskeminen”) voi jäädä muistibitti yli, jolloin nostetaan engl. carry flag lippu – se on tietty bitti FLAGS-rekisterissä, ja sen nimi on usein kirjallisuudessa CF. Samalla nousee luultavasti ylivuodon (engl. overflow) OF joka tarkoittaa lukualueen ylivuotoa (tulos olisi vaatinut enemmän bittejä kuin rekisteriin mahtuu).
• Vähennyslaskussa ja vertailussa (joka on olennaisesti vähennyslasku ilman tuloksen tallentamista!) päivittyy FLAGS:ssä bitti, joka kertoo, onko tulos negatiivinen – nimi on usein engl. negative flag, NF, etumerkkilippu (tai vastaavaa…)
• Jos jonkun operaation tulos on nolla (tai halutaan koodata joku tilanne vastaavasti) asettuu nollalippu (engl. zero flag), nimenä usein ZF.

Liput ovat mukana prosessorin syötteessä aina kunkin käskyn suorituksessa, ja suoritus on monesti erilainen lippujen arvoista riippuen. Monet ohjelmointirakenteet, kuten ehto- ja toistorakenteet perustuvat jonkun ehtoa testaavan käskyn suorittamiseen, ja vaikkapa ehdollisen hyppykäskyn suorittamiseen testin jälkeen (hyppy tapahtuu vain jos tietty bitti FLAGS:ssä on asetettu). Käyttöjärjestelmälle varatut prosessoriominaisuudet eivät ole käytettävissä silloin kun FLAGS:n käyttäjätilalippu ei niitä salli.

Esitetään muutamia huomioita rekisterien rooleista. Käskyrekisteri INSTR on esimerkki ohjelmoijalle näkymättömästä rekisteristä. Ohjelmoija ei voi mitenkään tehdä koodia, joka vaikuttaisi suoraan tällaiseen näkymättömään rekisteriin – sellaisia konekielikäskyjä kun ei yksinkertaisesti ole. Prosessori käyttää näitä rekisterejä sisäiseen toimintaansa. Näkymättömiä rekisterejä ei käsitellä tällä kurssilla enää sen jälkeen, kun suoritussykli ja keskeytykset on käyty läpi. Jonkinlainen INSTR on olemassa jokaisessa prosessorissa, jotta käskyjen suoritus olisi mahdollista. Lisäksi on mahdollisesti muita käyttäjälle näkymättömiä rekisterejä tarpeen mukaan. Niiden olemassaolo on hyvä tietää lähinnä esimerkkinä siitä että prosessorin toiminta, vaikkakin nykyään monipuolista ja taianomaisen tehokasta, ei ole perusidealtaan mitään kovin mystistä: Bittijonoiksi koodatut syöttötiedot ja jopa itse käsky noudetaan tietyin keinoin prosessorin sisäisten komponenttien välittömään läheisyyteen, josta ne kytketään syötteeksi näppärän insinöörijoukon kehittelemälle digitaalilogiikkapiirille, joka melko nopeasti muodostaa ulostulot ennaltamäärättyihin paikkoihin. Sitten tämä vain toistuu aina seuraavan käskyn osalta, nykyisin sangen tiuhaan tahtiin.

Käytännössä olemme kiinnostuneempia ohjelmoijalle näkyvistä rekistereistä (engl. visible registers). Jotkut näistä, kuten käskyosoitin IP ja lippurekisteri FLAGS, ovat sellaisia, ettei niihin suoraan voi asettaa uutta arvoa, vaan ne muuttuvat välillisesti käskyjen perusteella. Jotkut taas ovat yleiskäyttöisiä rekisterejä (engl. general purpose registers), joihin voi suoraan ladata sisällön muistista tai toisista rekistereistä ja joita voidaan käyttää laskemiseen tai muistiosoitteen ilmaisemiseen. Joidenkin rekisterien päärooli voi olla esim. yksinomaan kulloisenkin laskutoimituksen tuloksen tallennus tai sitten yksinomaan muistin osoittaminen. Kaikki tämä riippuu suunnitteluvaiheessa tehdyistä ratkaisuista ja kompromisseista (mitä vähemmän kytkentöjä, sen yksinkertaisempi, pienempi ja halvempi prosessori – mutta kenties vaivalloisempi ohjelmoida ja hitaampi suorittamaan toimenpiteitä).

Yhteenveto: Ohjelmien suoritukseen kykenevässä prosessorissa on oltava ainakin IP, FLAGS ja lisäksi rekisteri, joka voi sisältää dataa tai osoittaa muistipaikkaa, jossa data sijaitsee. Tyypillisesti nykyprosessoreissa on joitain kymmeniä rekisterejä yleisiin ja erityisiin käyttötarkoituksiin.

Tässä vaiheessa pitäisi olla jo selvää, että yksi prosessori voi suorittaa kerrallaan vain yhtä ohjelmaa, joten monen ohjelman yhdenaikainen käyttö ilmeisesti vaatii jotakin erityistoimenpiteitä. Yksi käyttöjärjestelmän tehtävä ilmeisesti on käynnistää käyttäjän haluamia ohjelmia ja jollain tavoin jakaa ohjelmille vuoroja prosessorin käyttöön, niin että näyttäisi siltä kuin olisi monta ohjelmaa yhtäaikaa käynnissä.

2.3.4 Prosessorin toimintatilat ja käynnistäminen

Eräs tarve tietokoneiden käytössä on eriyttää kukin normaali käyttäjän ohjelma omaan ’karsinaansa’, jotta ohjelmat eivät vahingossakaan sotke toisiaan tai järjestelmän kokonaistoimintaa. Tätä tarkoitusta varten prosessorissa on erikseen järjestelmärekisterejä (engl. system registers) ja toimintoja, joihin pääsee käsiksi vain käyttöjärjestelmän suoritettavissa olevilla konekielikäskyillä eli järjestelmäkäskyillä (engl. system instructions). Koska sama prosessorilaite suorittaa sekä käyttäjän ohjelmia että käyttöjärjestelmäohjelmaa, joilla on eri valtuudet, täytyy prosessorin voida olla ainakin kahdessa eri toimintatilassa, ja tilan on voitava vaihtua tarpeen mukaan.

Ohimennen voimme nyt ymmärtää, mitä tapahtuu, kun tietokoneeseen laitetaan virta päälle: prosessori käynnistyy niin sanottuun käyttöjärjestelmätilaan eli ydintilaan (engl. kernel mode). Englanninkielinen nimi viittaa nimenomaan käyttöjärjestelmän ytimeen (engl. kernel) eli siihen osaan käyttöjärjestelmän ohjelmakoodia, jota suoritetaan ydintilassa. Osa käyttöjärjestelmän palveluista on vähemmän kriittisiä, joten niitä ei ole pakko suorittaa ydintilassa. Muita tunnettuja nimiä käyttöjärjestelmätilalle ovat (vapaahkosti suommennettuna) ’todellinen tila’ (engl. real mode) tai ’valvojatila’ (engl. supervisor mode). Käynnistyksen jälkeen prosessori alkaa suorittaa ohjelmaa ROM-muistista (kiinteästi asetetusta fyysisestä muistiosoitteesta alkaen). RAM-muisti on tyhjentynyt tai satunnaistunut virran ollessa katkaistuna. Oletuksena on, että ROM:issa oleva, yleensä pienehkö, ohjelma lataa varsinaisen käyttöjärjestelmän joltakin ulkoiselta tallennuslaitteelta²⁰ . Käynnistettäessä tietokone siis on vain prosessoriarkkitehtuurinsa mukainen digitaalinen laskin, eikä esim. ”macOS, Windows tai Linux -kone”.

Käyttöjärjestelmän latausohjelmaa etsitään melko alkeellisilla, standardoiduilla laiteohjauskomennoilla tietystä paikasta fyysistä tallennetta. Siellä pitäisi olla siis nimenomaiselle prosessorille käännetty konekielinen latausohjelma, jolla on sitten vapaus säädellä kaikkia prosessorin systeemitoimintoja ja toimintatiloja. Sen pitäisi myös alustaa tietokoneen fyysinen RAM-muisti tarkoituksenmukaisella tavalla ja ladata muistiin seuraavissa vaiheissa tarvittavat ohjelmiston osat.

Alkulatauksen (engl. bootstrapping, engl. booting)²¹ jälkeen käyttöjärjestelmäohjelmiston pitää vielä tehdä koko liuta muitakin valmisteluja sekä lopulta tarjota käyttäjille mahdollisuus kirjautua sisään koneelle ja alkaa suorittamaan hyödyllisiä tai viihteellisiä ATK-sovelluksia. Esimerkiksi ilman erillistä graafista käyttöliittymää varustettu Unix-käyttöjärjestelmä jää käynnistyttyään odottamaan ’loginia’ eli käyttäjätunnuksen ja salasanan syöttöä päätteeltä, minkä jälkeen käyttöjärjestelmän login-osio käynnistää tunnistetulle käyttäjälle ns. kuoren (engl. shell) jota vakiintuneesti (lue: ammattislangilla) kutsutaan ’shelliksi’ myös suomen kielellä. Englismi on jopa niin vakiintunut, että käytämme jatkossa ainoastaan sitä, kun puhumme kuoresta. Käyttöliittymältään ja toiminnallisuuksiltaan jonkin verran erilaisia shellejä on syntynyt aikojen saatossa monta (esimerkiksi bash, tcsh, ksh). Käyttöjärjestelmä ohjaa päätteen näppäinsyötteet shellille ja shellin tulosteet näytölle. Käyttöliittymä voi toki olla graafinenkin, jolloin puhutaan ikkunointijärjestelmästä (engl. windowing system). Ikkunointi voi olla osa käyttöjärjestelmää, tai se voi olla erillinen ohjelmisto, kuten Unix-ympäristöissä aiemmin paljon käytetty ikkunointijärjestelmä nimeltä X tai sen uudempi korvaaja Wayland. Nykypäivänä käyttäjä myös edellyttänee, että hänelle tarjotaan työpöytä (engl. desktop manager), joka on kuitenkin jo melko korkealla tasolla varsinaiseen käyttöjärjestelmän ytimeen nähden, eikä siten kovinkaan paljon tämän kurssin aihepiirissä.

Kirjautumisen jälkeen kaikki käyttäjän ohjelmat toimivat prosessorin ollessa käyttäjätilassa (engl. user mode) jolle käytetään myös nimeä suojattu tila (engl. protected mode). Jälkimmäinen nimi viitannee siihen, että osa prosessorin toiminnoista on tällöin suojattu vahingossa tai pahantahtoisesti tapahtuvaa väärinkäyttöä vastaan. Käyttäjätilassa toimii mahdollisesti myös osa käyttöjärjestelmän palveluohjelmista. Käyttöjärjestelmää, jossa suurin osa palveluista toimii käyttäjätilassa ja käyttöjärjestelmätilassa toimii vain minimaalinen määrä koodia, sanotaan ymmärrettävällä logiikalla mikroydinkäyttöjärjestelmäksi (engl. microkernel operating system). Vastakohta, jossa kaikki käyttöjärjestelmän palvelut toimivat prosessorin ollessa käyttöjärjestelmätilassa on nimeltään monoliittinen käyttöjärjestelmä (engl. monolithic operating system). Mikroydinjärjestelmä on turvallisempi ja toimintavarmempi. Monoliittisessa puolestaan on mahdollista maksimoida suorituskyky. Käytännön toteutuksissa haetaan näiden ääripäiden väliltä kompromissi, joka toimii riittävän tehokkaasti, mutta osa palveluista hoidetaan rajoitetussa käyttäjätilassa, missä esimerkiksi palvelukohtaisten oikeuksien määrittäminen on mahdollista.

Prosessorin tilaa (käyttäjä-/käyttöjärjestelmätila) säilytetään jossakin vähintään yhden bitin kokoisessa sähkökomponentissa prosessorin sisällä. Tämä tila (esim. 0==käyttöjärjestelmä, 1==käyttäjätila) voi olla esim. yhtenä bittinä lippurekisterissä. Itse asiassa kurssilla esimerkkinä käytettävä AMD64-arkkitehtuuri tarjoaa neljä suojaustasoa, 0–3, joista käyttöjärjestelmän tekijä voi päättää käyttää kahta (0 ja 3) tai useampaa. Olennaista kuitenkin on, että aina on olemassa vähintään kaksi – käyttäjän tila ja käyttöjärjestelmätila. Puhutaan jatkossa näistä kahdesta.

Nykyaikaisissa prosessoreissa on myös muita käyttäjän tai käyttöjärjestelmän vaihdeltavissa olevia toimintatiloja, jotka vaikuttavat esimerkiksi siihen, miten suurta osaa rekisterien biteistä käytetään operaatioihin, ollaanko jossakin taaksepäin-yhteensopivuustilassa tai vastaavassa, ja sen sellaista, mutta niihin ei ole mahdollisuutta eikä tarvetta syventyä tällä kurssilla. Olennaista on ymmärtää käyttöjärjestelmätilan ja käyttäjätilan erilaisuus fyysisen laitteen tasolla. Siihen perustuu moniajo, virtuaalimuistin käyttö ja suuri osa tietoturvasta. Yksityiskohtiin palataan myöhemmin. Tässä vaiheessa riittäköön vielä seuraava ajatusmalli:

• Käyttöjärjestelmä ottaa tietokoneen hallintaansa pian käynnistyksen jälkeen, mutta ei aivan heti; laitteen ROM-muistissa on oltava riittävä ohjelma käyttöjärjestelmän ensimmäiseksi suoritettavan osion lataamiseksi esim. kovalevyn alusta.
• Käyttöjärjestelmällä on vapaus käsitellä kaikkia prosessorin ominaisuuksia.
• Käyttöjärjestelmän täytyy käynnistää normaalit ohjelmat ja hoitaa ne toimimaan prosessorin käyttäjätilassa.
• Käyttöjärjestelmä isännöi tavallisia ”käyttäjämaan” ohjelmia ja mahdollistaa moniajon yhteistyössä prosessorin kanssa. Tästä kerrotaan myöhemmin lisää.

Käyttäjätilassa konekielisissä ohjelmissa saa olla vain käyttäjätilassa sallittuja käskyjä ja käskyjen operandeina voi käyttää vain käyttäjälle näkyviä rekisterejä (engl. user visible registers). Prosessorin ollessa käyttäjätilassa oheislaitteiden suora käyttäminen on mahdotonta, samoin kuin muiden sellaisten muistiosoitteiden käyttö, joihin käyttäjätilan ohjelmalle ei nimenomaisesti ole annettu lupaa. Lupia voi muuttaa vain, kun prosessori on käyttöjärjestelmätilassa. Mitä luvat käytännössä tarkoittavat, on kurssin loppupuolen asiaa…pienenä spoilerina voidaan tässä vaiheessa todeta, että ne ilmenevät muistiosoitteisiin liittyvinä yksittäisinä bitteinä, esim. 0 = ei saa käyttää; 1 = saa käyttää. Suoranainen yllätys tämä asia toivottavasti ei kuitenkaan enää ollut, kun on puhuttu tietokoneen luonteesta yksinkertaisena bittiautomaattina.

2.3.5 Käskykanta-arkkitehtuureista

Tietty prosessoriarkkitehtuuri tarkoittaa niitä tapoja, joilla sen mukaisesti rakennettu fyysinen prosessorilaite toimisi: Mitä toimenpiteitä se voisi tehdä (eli millaisia käskyjä sillä voisi suorittaa), mistä ja mihin mikäkin toimenpide voisi siirtää bittejä, ja miten mikäkin toimenpide muunnettaisiin (tavallisesti muutaman tavun mittaiseksi) bittijonoksi, joka sisältää operaatiokoodin, (engl. opcode, engl. operation code) ja tiedot operoinnin kohteena olevista rekistereistä/muistiosoitteista. Prosessoriarkkitehtuurissa kuvataan mahdollisten, prosessorin ymmärtämien käskyjen ja operandiyhdistelmien joukko. Tätä kutsutaan nimellä käskykanta tai käskyjoukko (engl. instruction set). Toinen nimi prosessoriarkkitehtuurille onkin käskykanta-arkkitehtuuri (engl. ISA, instruction set architecture).

Tarkkaavainen lukija huomasi, että edellinen kappale oli kirjoitettu konditionaalissa: ’toimisi’, ’voisi tehdä’, …Tämä johtuu siitä, että arkkitehtuuri on nimenomaan sopimus siitä, kuinka laitetta voitaisiin käyttää. Se, onko arkkitehtuurin mukaisia laitteita olemassa, on eri asia. Luultavasti uusi prosessorimalli on olemassa ensin arkkitehtuuridokumentaationa, sen jälkeen elektroniikkasuunnitelmana ja simulaattorina ja vasta lopputulemana fyysisenä laitteena tehtaan paketissa. Laitteelle voidaan periaatteessa tehdä konekielisiä ohjelmia ja kääntäjiä jo ennen kuin yhtään laitetta on valmistettu. Ei tarvita kuin dokumentoitu prosessoriarkkitehtuuri.

Prosessoriarkkitehtuureita ja niitä toteuttavia fyysisiä prosessorilaitteita on markkinoilla monta, ja niissä on merkittäviä eroja, mutta kaikissa on jollakin tavoin toteutettu edellä kuvaillut pakolliset piirteet. Yleisrakenteeltaan ne vastaavat tänä päivänä sekä näköpiirissä olevassa tulevaisuudessa 1940-lukulaista perusarkkitehtuuria! Kunkin prosessorin käskykanta ja muu konekieliseen ohjelmointiin tarvittava kuvataan prosessorivalmistajan toimittamassa manuaalissa, jonka tarkoituksena on antaa riittävä tieto minkä tahansa toteutettavissa olevan ohjelman tekemiseen niitä nimenomaisia piinkappaleita käyttämällä, joita prosessoritehtaasta pakataan ulos.

Mainittakoon myös nimeltä matemaatinen ala nimeltä laskennan teoria, joka antaa muurinlujia tuloksia siitä, mitä nykyisenkaltaisella tietokoneella voidaan tehdä ja mitä sillä toisaalta ei yksinkertaisesti voida tehdä. Esimerkiksi jokainen tietokone pystyy ratkaisemaan samat tehtävät kuin mikä tahansa toinen tietokone, jos unohdamme sellaiset pikkuseikat kuin ratkaisuun kuluva aika tai tarvittavan muistin määrä. Tästä lisää algoritmikursseilla!

2.3.6 Hieman realistisempi kuva: moniydinprosessorit, välimuistit

Kuvassa 9 on hieman edellistä realistisempi kuva nykyaikaisesta tietokoneesta. Olennainen ero on, että tässä kuvassa keskusyksiköitä eli CPUita on monta rinnakkain. Kutakin niistä sanotaan ytimeksi (engl. core) ja kokonaisuutta moniydinprosessoriksi (engl. multicore processor). Mikäli prosessorit ovat keskenään samanlaisia (’symmetrisiä’), niin tällaisen tietokoneen yhteydessä puhutaan symmetrisestä moniprosessoinnista (engl. symmetric multiprocessing, SMP). Moniydinprosessorien suunnittelu ja valmistaminen on tietysti monimutkaisempaa kuin yhden yksittäisen prosessorin. Myös käyttöjärjestelmien suunnitteluun moniprosessointi tuo omat detaljinsa. Osoittautuu kuitenkin, että normaalien sovellusohjelmien tekijälle ei ole suurtakaan väliä sillä, onko alustalaitteessa yksi vai monta ydintä. Myöskään tällaisen johdantokurssin asioihin ei tuo merkittävää eroa, onko prosessoreita yksi vai kaksi. Yksinkertaisuuden mielessä voidaan siis jatkossa käsitellä suurimmaksi osaksi yhden prosessorin (tai prosessoriytimen) toimintaa.

Kuvassa on myös täsmennetty muistilaitteiston jakautumista rekistereihin, välimuisteihin, keskusmuistiin ja massamuisteihin. Niistä on syytä kertoa seuraavaksi aivan erikseen.

2.3.7 Muistilaitteistosta: muistihierarkia, prosessorin välimuistit

Havaittiin, että prosessorissa tarvitaan ns. rekisterejä, jotka ovat nopeita muistikomponentteja prosessorin sisällä, mahdollisimman lähellä laskentaa hoitavia komponentteja. Rekisterien määrää rajoittaa kovasti hinta, joka niiden suunnitteluun ja toteutukseen liittyy. Muistia tarvitaan tietokoneessa kuitenkin paljon, koska tietojenkäsittelyn tehtävät tarvitsevat lyhyt- ja pitkäaikaista tietojen tallennusta. Nykyisin keskusmuistiin mahtuu varsin paljon tietoa, mutta se on kaukana ulkoisen väylän päässä, joten sen käyttö on maailmallisista syistä johtuen hidasta. Kompromissina prosessoreihin valmistetaan ns. välimuisteja (engl. cache memory), eli nopeampia (ja samalla kalliimpia) muistikomponentteja, jotka sijaitsevat lähempänä prosessoria ja joissa pidetään väliaikaisesti osaa keskusmuistin sisällöstä. Tämä on järkevää, koska ohjelmat käyttävät useimmiten lähellä toisiaan olevia muistiosoitteita aika pitkään, ennen kuin ne siirtyvät taas käsittelemään joitakin toisia (nekin taas lähellä toisiaan olevia) osoitteita. Riittää vaihtaa tuo uusi ’lähimaasto” välimuistiin edellisen ’lähimaaston’ tilalle. Tälle havainnolle on nimikin, lokaalisuusperiaate (engl. principle of locality). Käytännön tasolla ilmiön taustat on helppo ymmärtää: Ajattele esim. koodin osalta peräkkäin suoritettavia käskyjä, muutamien käskyjen mittaisia silmukoita ja usein toistettavia aliohjelmia. Datan osalta taas käsitellään suhteellisen pitkään tiettyä tietorakennetta ennen siirtymistä seuraavan käsittelyyn. Metodien sisäiset paikalliset muuttujat ovat nimensä mukaisesti myös paikallisia, koodissa lähekkäin määriteltyjä ja ajallisesti lähekkäin käyteltyjä.

Rekisterejä voi siis olla kustannussyistä vain muutama. Välimuistit maksavat enemmän kuin keskusmuisti, mutta nopeuttavat kokonaisuuden toimintaa. Nykyinen tietokonelaitteisto hoitaa välimuistien toiminnan automaattisesti. Sovellusohjelmien tekijän ei tarvitse huolehtia siitä, ovatko muistiosoitteiden osoittamat tiedot keskus- vai välimuistissa. Välimuistien olemassaolo ja rajallinen koko on kuitenkin ymmärrettävä tiettyjä laskenta-algoritmeja tehdessä: Ohjelmat toimivat todella paljon nopeammin, jos suurin osa tiedoista löytyy välimuistista suurimman osan aikaa. Siis kannattaa tehdä algoritmit siten, että käsitellään dataa mahdollisuuksien mukaan pieni lohko kerrallaan ennen siirtymistä seuraavaan – eli hyppimättä kaukana toisistaan olevien muistiosoitteiden välillä.

Ns. massamuistia(engl. mass memory), kuten kovalevytilaa, on käytettävissä käytännön tarpeisiin lähes rajattomasti ilman äärimmäisiä kustannuksia. Voidaan puhua ns. muistihierarkiasta (engl. memory hierarchy), jossa muistikomponentit listataan nopeasta hitaaseen, samalla kalliista halpaan, seuraavasti:

• Rekisterit
• Välimuistit (Level 1, Level 2, joissakin prosessoreissa myös Level 3; prosessori- ja muistiteknologia hoitaa välimuistin käytön; ohjelman ei tarvitse, eikä se viime kädessä edes pysty huolehtimaan siitä, onko sen tarvitseman muistiosoitteen sisältö jo välimuistissa vai onko se toistaiseksi kauempana)
• Keskusmuisti
• Massamuistit kuten kovalevyt

Koska on mahdotonta saavuttaa täydellistä tilannetta, jossa kaikki muisti olisi prosessorin välittömässä läheisyydessä, tarvitaan suunnittelussa kompromissiratkaisuja. Kalliita ja nopeita rekisterejä suunnitellaan järjestelmään muutamia, Level 1:n välimuistia jonkin verran ja Level 2 (ja mahdollisesti Level 3) -välimuistia vielä vähän enemmän. Suunnittelu- ja tuotantokustannukset, mutta samalla muistien käytön nopeus, putoavat sitä mukaa kuin etäisyys prosessoriin kasvaa. Keskusmuistia on nykyään aika paljon, mutta ohjelmatkin tuppaavat kehittymään siihen suuntaan että niiden uudemmat ja hienommat versiot lopulta käyttävät niin paljon keskusmuistia kuin kulloisellakin aikakaudella on saatavilla. Ohjelmia halutaan siis tyypillisesti suorittaa enemmän kuin keskusmuistiin mahtuu ohjelmien tarvitsemaa dataa. Massamuistit ovat äärimmäisen suuria ja halpoja, mutta myös keskusmuistiin nähden äärimmäisen hitaita. Tästä seuraa tarve jollekin fiksulle järjestelmälle, joka hyödyntää hidasta levytilaa nopean, mutta rajallisen, keskusmuistin apuna. Avain on käyttöjärjestelmän ja prosessorin yhteisesti hallitsema sivuttava virtuaalimuisti, johon syvennytään myöhemmässä luvussa.

2.3.8 Virtuaalikoneet ja kontit

Ohjelmisto, myös käyttöjärjestelmä, käskee laitteistoa prosessoriarkkitehtuurin määrittämän rajapinnan kautta. Sen alla voi olla todellisuudessa lisää kerroksia, ja koko laitteisto voi olla enemmän tai vähemmän näennäinen eli virtuaalinen. Tavallisesti yhdessä datakeskuksen palvelintietokoneessa toimii samaan aikaan useita virtuaalikoneita, jotka kaikki näyttävät asiakkaiden suuntaan erillisiltä. Palvelinkoneiden teknologia ja oma käyttöjärjestelmä tai tarkemmin sanottuna virtuaalikonemonitori (engl. hypervisor) mahdollistaa erillisten virtuaalikoneiden pystyttämisen siten, että niissä jokaisessa voi olla kokonaan omat käyttöjärjestelmänsä.

Myös kotioloissa jokainen voi asentaa omalle tietokoneelleen virtuaalikoneita ja niihin käyttöjärjestelmiä. Se on oikein suositeltava ja opettavainen harrastus. Tällainen virtuaalikone on ohjelmisto, joka näyttäytyy sen päällä suoritettavalle käyttöjärjestelmälle ja sovelluksille ihan samanlaisena kuin todellisempi kone. Kaikenlaisia hurjiakin kokeiluja voi tehdä turvallisesti virtuaalikoneessa, jossa ei ole mitään tärkeää tallessa.

Tehokkainta virtuaalikoneen toiminta on, mikäli sen alla oleva fyysinen laite ja käyttöjärjestelmä tukevat virtualisointia eli virtuaalikoneohjelmien suorittamista. Yhtä hyvin ohjelmistolla voidaan kuitenkin emuloida minkä tahansa tietokoneen toimintaa – jopa sellaisen, jota ei ole vielä valmistettu tai joita ei ole enää maailmassa ehjänä.

Tällä kurssilla rajoitutaan ajattelemaan yhtä käyttöjärjestelmää, joka toimii todellisen tai virtuaalisen tietokonelaitteiston päällä. Toimintojen kannalta ei ole väliä, onko laite todellinen vai virtuaalinen. Virtuaalisuuteen kuuluu se, että voidaan ainakin kuvitella laitteiston olevan todellinen, fyysinen vehje²² .

Lähivuosina, mutta ei vielä 2023, tämän kurssin osaksi tullee pieni lisäosuus harjoitteineen pilvipalveluista ja etenkin konteista, jotka ovat vielä virtuaalikonettakin kevyempi virtualisointikeino. Kontit toimivat samassa tietokoneessa ja käyttöjärjestelmässä konttikoneiston (engl. container engine) päällä siten, että ne saavat toisistaan erilliset käyttöoikeudet ja kirjastoympäristöt. Vielä kevään 2023 kurssilla emme todennäköisesti kovin laajamittaisesti palaa kontteihin tai konttikoneistoihin. Käsittelemme käyttöjärjestelmää, jollainen konttikoneistonkin alla ohjelmistopinkassa aina on.

3 Hei maailma – johdattelua tietokoneeseen

Avainsanat: ikkunointijärjestelmä, graafinen shell, tekstimuotoinen shell, tiedosto, lähdekoodi, kohdekoodi (objekti), kääntäminen, linkittäminen, lataaminen, kirjastot, jaetut objektit, tulkkaus, skripti, IDE

Osaamistavoitteet: Luvun luettuaan opiskelija:

• (alustavasti) ymmärtää ohjelman suorituksen muistissa sijaitsevien konekielisten käskyjen jonona sekä tyypillisten ohjelmointirakenteiden ilmenemisen konekielessä; tunnistaa konekielisen ohjelman sellaisen nähdessään (AT&T tai Intel -tyyppisenä assemblynä tai disassemblynä) [ydin/arvos2]
• osaa selittää vaiheet ja mahdolliset ongelmatilanteet suoritettavan ohjelmatiedoston lataamisessa, dynaamisessa linkittämisessä ja käynnistämisessä [ydin/arvos2]

Tässä luvussa kirjoitetaan, jälleen kerran, sovellusohjelma nimeltä ”Hei maailma!”. Ohjelma on sopivan yksinkertainen koeputkiesimerkki, jonka avulla päästään tutkimaan näkymiä tietokoneen osien toimintaan ja käyttöjärjestelmäohjelmiston vastuulla oleviin tehtäviin. Tässä luvussa tehdään vasta esityö ja kerätään havaintoja. Tarkempi ymmärrys on tarkoitus hankkia vasta seuraavissa luvuissa, joissa käydään yksityiskohtia tarkemmin läpi.

3.1 Peruskäyttäjän näkökulma: ikkunat, työpöytä, ”resurssienhallinta”

Totuttu tapa ohjelmien käynnistämiseen on klikata niiden kuvaketta jonkinlaisessa valikossa, joka näyttää mahdollisia ohjelmia. Ohjelmat aukeavat sitten yleensä kukin omaan ikkunaansa, jota voi siirrellä näytöllä. Ohjelmilla käsitellään useimmiten tiedostoja, esimerkiksi tekstidokumentteja, valokuvia tai videoita, joita voi tallentaa levyille, muistitikuille ym. tai siirtää verkon yli. Näitä tiedostoja voi selata, siirrellä hakemistosta toiseen, poistaa ym., erityisellä ohjelmalla, jonka nimi on esimerkiksi ”resurssienhallinta”. Tiedostot sijaitsevat hakemistopuussa, jossa niillä on kaikilla yksilöivä nimi ja ”tiedosto-osoite” eli sijainti puussa, joka alkaa jonkin alipuun juuresta – laajimmillaan koko tiedostojärjestelmän juuresta. Toisaalta osoite voi olla suhteessa myös esimerkiksi omaan kotihakemistoon tai vaikkapa yhden kurssin tehtävien vastaustiedostoja sisältävän alipuun juureen. Tiedoston osoitteen sanotaan olevan absoluuttinen tiedostonimi (engl. absolute file name), jos se ilmoitetaan suhteessa ylimpään juureen ja suhteellinen tiedostonimi (engl. relative file name), jos se ilmoitetaan suhteessa johonkin muuhun hakemistoon.

Graafisten ikkunoiden hallitseminen tapahtuu tyypillisimmin niin sanotun ikkunointijärjestelmän (engl. window manager) kautta. Vaikka kyseinen järjestelmä saattaa olla osa käyttöjärjestelmää, se on jo niin korkealla tasolla ytimen yläpuolella, ettei meitä tällä kurssilla liiemmin sen yksityiskohdat kiinnosta.

Nämä tutut ohjelmien käynnistämiseen ja yleiseen tiedostojen hallintaan liittyvät graafiset välineet ovat esimerkki graafisista kuoriohjelmista (engl. graphical shell), joissa voidaan hiirellä klikkailemalla tai kosketusnäyttöä näppäimellä päästä käsiksi järjestelmässä sijaitseviin kohteisiin. Kuori (engl. shell) ylipäätään tarkoittaa matalamman tason järjestelmän ympärille rakennettua rajapintaa, jonka kautta järjestelmän hallitsemia kohteita on yhden pykälän verran helpompi käsitellä.

3.2 Käyttäjän näkökulma tällä kurssilla: tekstimuotoinen shell

Tällä kurssilla käsitellään tekstimuotoista kuorta, koska teksti on rajapintana lähempänä tietokoneen ja käyttöjärjestelmän sisäistä ”totuutta” kuin kuvakkeet, joten teoreettiset asiat tulevat tekstikuoren kautta konkreettisemmiksi. Toisekseen tekstimuotoisia kuorikomentoja on helpompi kirjoittaa ylös, toistaa ja varioida kuin graafisia klikkailusekvenssejä. Niistä voidaan rakentaa skriptejä, joilla toimintojen sarjoja voidaan yhdistellä, parametrisoida ja toistaa aina tarvittaessa tai automaattisesti tietyin väliajoin. Tekstimuotoiselle kuorelle on myös vakiintuneita käytäntöjä, jotka on mm. POSIX-standardissa kiinnitetty yhteensopivien sovellusten tekemisen pohjaksi. Yhteensopivilla menettelyillä voidaan siis tehdä järjestelmänhallintaan liittyviä automaatioita, jotka toimisivat samalla tavoin esim. Mac OSX:ssä, FreeBSD:ssä ja joissain riittävän hyvin POSIXia tukevissa Linux-jakeluissa.

Keväällä 2015 kuoren eli shellin käyttöä opetellaan ensimmäistä kertaa demoissa 1 ja 2, nimiltään ”Superpikaintro interaktiivisen Unix-shellin käyttöön” ja ”Superpikajatko interaktiivisen Unix-shellin käyttöön”. Kyseiset demot olisi hyvä olla tehtynä siinä vaiheessa, kun tämä luentomonisteen vaihe on käsittelyssä.

3.3 ”Hello world!” lähdekooditiedostona

C-kieli kiinnostaa tällä kurssilla ainakin neljästä syystä:

• Konkreettisen tietokonelaitteiston toimintaan päästään sen avulla käsiksi ilman käsienheiluttelua, koska C:n lähtökohtainen tavoite ja nykyinen rooli on olla abstraktiotasoltaan matala kieli, joka käsittelee dataa melkein kuin tietokonelaite.
• C-kieli on ollut vahva vaikuttaja myöhemmin kehitettyjen lohkorakenteisten oliokielten, kuten C#:n ja Javan, määrittelyssä, joten C-kieleen tutustuminen antaa historiallista perspektiiviä nykypäivään sekä selityksiä ilmiöille, joita ei oikein pysty selittämään muuten kuin että ”C:ssä tämä piti kirjoittaa näin, joten kirjoitetaan se edelleen näin, vaikka se olisi ehkä fiksumpaa tehdä jollain muulla tavalla”. Yksi esimerkki ”vahvasti C-mäiseksi” tehdystä kielestä on myös esim. tietokonegrafiikassa tarpeellinen GLSL-varjostinkieli.
• Käyttöjärjestelmät saatetaan tehokkuussyistä (ja suoremman laiteohjauksen toteutumiseksi) haluta tehdä C-kielellä. Mm. Linux on pääosin C-kieltä, joten olemassaolevaa käyttöjärjestelmäkoodia C:llä löytyy paljon. Puhtaalta pöydältä aloitettaviin laiteläheisiin projekteihin kannattanee nykyään tutustua korkeamman tasoon kieliin, joille löytyy kääntäjä halutulle prosessoriarkkitehtuurille.
• POSIX-standardi, jota kurssilla käytetään esimerkkinä laiteriippumattomasta käyttöjärjestelmän sovellusrajapinnasta, määrittelee sovellusohjelmien tekemiseksi nimenomaan C-kääntäjän ja tiettyjen alemman tason kirjastojen ominaisuudet.

Seuraavassa on esimerkki perinteisestä, yksinkertaisesta sovellusohjelmasta C-kielellä:

Erot esimerkiksi C#:lla tehtyyn vastaavaan sovellukseen ovat pieniä, ja niitä mietitään tarkemmin tämän kurssin demossa 3. Demossa 2 havaituin keinoin voidaan varmistua siitä, miltä esimerkiksi tällainen lähdekooditiedosto näyttää tietokoneen näkökulmasta. Kevään 2015 luennoilla käytiin läpi jotakuinkin seuraavaa komentorivisessiota vastaavat esimerkit. Mukana on tässä sekä komennot että niiden tulosteet, jotta lukija voi seurata esimerkin kulkua:

Alussa tulostetaan shellin nykyinen työhakemisto (komento pwd, ”print current working directory”). Se kertoo lähdekooditiedoston sijainnin hakemistopuussa, jolla ei ole oikeastaan mitään tekemistä tiedoston sisällön kanssa. Tiedostojahan voi siirrellä paikasta toiseen hakemistopuussa tai vaikka eri tietokoneelle verkon yli. Olisi ihan suotavaa, että sisältö ei näissä operoinneissa muutu.

Koko sisältö näkyy seuraavaksi apuohjelman ”hexdump” avulla tasan siten kuin se on: Vasemmassa sarakkeessa on 8-bittisten tavujen juokseva numerointi tiedoston alusta alkaen heksalukuna (indeksit alkavat nollasta, ja koska rivillä näytetään aina 16 tavua, on seuraavan rivin ensimmäinen indeksinumero aina 16 suurempi kuin edellinen - heksana siis 10₁₆ eli 0x10 suurempi. Kaikki tiedoston sisältämät tavut, ei mitään vähemmän eikä enemmän, on tässä vedoksessa mukana heksoina. Oikeanpuoleisessa sarakkeessa joka rivillä on tavuja vastaavat 16 merkkiä, mikäli tavujen ilmoittamat luvut osuvat ASCII-merkistöstandardin mukaisiin ”tulostettaviin merkkeihin”. Ei-tulostettavien merkkien kohdalla on piste. Tässä tapauksessa melkein kaikki merkit ovat tulostettavia, mutta rivinvaihtojen kohdalla nähdään koodaus 0x0a, joka siellä tyypillisesti tulee, kun tiedosto on tehty unixiin pohjautuvassa järjestelmässä ASCII- tai UTF8-merkistökoodauksella. Rivinvaihdon, kuten tekstimerkkienkin, koodaus vaihtelee järjestelmien välillä, joten tiedon tuottamisessa käytetty koodaus tulee tuntea. Tavallisen tekstitiedoston sisältöön tieto koodauksesta ei nähtävästikään sisälly! Jos koodauksesta on epäselvyyttä, ei auta kuin katsoa sisältöä vaikkapa heksavedoksena ja yrittää tehdä johtopäätöksiä.

Havaitaan, että myöskään tiedoston nimi ei kuulu sisältöön. Samalle numeroina koodatulle datapötkölle voidaan antaa mikä tahansa nimi, eikä se vaikuta sisältöön. On siis aivan sama, onko tiedoston nimi ”helloworld.c”, ”helloworld.cs”, ”helloworld.txt” tai pelkkä ’helloworld”, vaikka monissa sovelluksissa (mukaanlukien monet ohjelmointikielten kääntäjät) onkin sovittu, että nimen pitää olla tietyn muotoinen erityisesti loppuosastaan.

Nimi tai mitään muutakaan kuvailevaa lisätietoa eli metatietoa ei tiedoston sisällössä kuitenkaan ole mukana. Ymmärrettävistä syistä tärkeitä tietoja ovat mm. tiedoston käyttöoikeudet, luonti- ja muokkausajankohdat ja koko. Nämä saadaan selvästi kaivettua esille komennolla ls tai Linuxissa komennolla stat kuten esimerkissä yllä. Käyttöjärjestelmän täytyy ylläpitää kaikkia näitä tietoja, kuten myös tiedoston nimeä ja sisältöä jollakin tavalla. Tapa, jolla kaikki tarvittava tiedostoihin liittyvä tieto organisoidaan ja tallennetaan, on nimeltään tiedostojärjestelmä (engl. file system), johon liittyy sopimukset tallennustavasta, osoitteista ja mahdollisuuksista asettaa metatietoja. Tiedostojärjestelmiä on kehitetty useita. Niiden ominaisuudet ja käyttötarkoitukset poikkeavat toisistaan, ja uudemmissa on tietysti laajemmat mahdollisuudet kuin vanhemmissa. Järkevän käyttöjärjestelmän täytyy tukea ainakin yhtä tiedostojärjestelmää, koska tiedostojen käsittely on ymmärrettävästi aika tärkeä sovellus. Yleiskäyttöinen käyttöjärjestelmä tukee oletettavasti useitakin erilaisia tiedostojärjestelmiä, jotta vanhoja tai muutoin muissa järjestelmissä tallennettuja tietoja pystytään lukemaan. Osa metatiedoista saattaa tietenkin hukkua matkalla, mikäli tiedosto siirretään yhdestä tiedostojärjestelmästä toiseen, joka ei osaakaan tallentaa juuri samoja metatietoja. Tämän kurssin loppupuolella käsitellään, jos aikaa jää, yhtä konkreettista tiedostojärjestelmää esimerkinomaisesti.

Nyt toivottavasti on poistunut kaikki epäselvyys ja mystisyys siitä, miten tiedostot, esimerkiksi tavallinen teksti ja aivan samalla tavalla myös ohjelmointikielellä kirjoitettu lähdekoodi (engl. source code), näyttäytyvät tietokoneen näkökulmasta ja miten niitä voi halutessaan tutkia ”konepellin alta”.

Korostettakoon nyt vielä tässäkin, että laitteisto ei ”ymmärrä” tiedosta tai tiedostoista mitään muuta kuin pötkön bittejä. Kaikki sitä korkeamman tason asiat hoitaa ohjelmisto – matalimmalla tasolla siis käyttöjärjestelmäohjelmisto. Erityisesti tuollainen ihmisen ymmärtämällä korkean abstraktiotason kuvauskielellä kirjoitettu Hei maailma -lähdekoodi ei sellaisenaan pysty ohjaamaan tietokoneen toimintaa. Se pitää kääntää lähteestä kohdekoodiksi (engl. object code), joka on tyypillisesti jonkin yksinkertaisemman järjestelmän ymmärtämää. Esimerkiksi C-kääntäjän tehtävänä on kääntää lähdekoodi kohde- eli objektikoodiksi, jota jokin tietty tietokonelaitteisto ymmärtää suoraan, ts. tietyn prosessoriarkkitehtuurin mukaiseksi konekielikoodiksi.

3.4 ”Hello world!” lähdekoodista suoritukseen

Ohjelmia ei voi kirjoittaa kerralla alusta loppuun, sana sanalta järjestyksessä. Sen sijaan ohjelmaan saatetaan tehdä ensin runko, jonka sisältöä myöhemmin muokataan ja siihen lisätään aina pätkä kerrallaan, kunnes ohjelman oikeellisesta ja tavoitteen mukaisesta toiminnasta voidaan olla riittävän varmoja²³ . Tavoitteet puolestaan muuttuvat, joten luonnostaan ohjelmia täytyy muokata sieltä täältä aina seuraavaa versiota varten, eivätkä ne siten ole koskaan valmiita²⁴ . Ihminen tekee luonnostaan huolimattomuus- ja ajatusvirheitä, aina väärien näppäimien painamisesta lähtien. Näin ollen ohjelmakoodia pitää riittävän usein testata käytännössä. Vähintäänkin se pitää kääntää (engl. compile) ja ajaa (engl. run), ennen kuin voi tietää, että ohjelma on edes syntaksiltaan oikein.

Kevään 2015 luennolla esiteltiin koeputkiesimerkkinä vaiheittain C-kielisen Hei maailma -ohjelman synty ja mm. kääntäjän varoitukseen reagoiminen korjaamalla ohjelmaa. Lopputuloksena lopulta ohjelma vielä kerran käännettiin ja suoritettiin seuraavan komentorivisession mukaisesti:

IDEssä tällainen sekvenssi on tietysti automatisoitu klikkauksen tai pikanäppäimen taakse. Tällä kurssilla nähdään, mitä konepellin alla tapahtuu: kääntäjätyökalu suoritetaan ja sitä ohjataan jollain tapaa, esimerkiksi komentoriviargumenttien avulla. Tässä optiolla ”-g” pyydetään sisällyttämään käännettyyn tiedostoon lisätietoja debuggausta varten, mm. viittaukset lähdekooditiedostoon. Kaupan hyllylle toimitettavassa ohjelmassa esim. tätä vipua kenties ei olisi, mutta ohjelmistokehittäjän omissa käännöksissä kylläkin. Esimerkiksi juuri tällaisia eroja IDE saattaa konepellin alla tehdä riippuen tehdäänkö käännös ”Release” -valinnalla tai ”Development” / ”Debug” -valinnalla. Lisäksi argumenttiparilla ”-o helloworld.suoritettava” valitaan kuvaava nimi käännetylle ohjelmalle.

Edellä katsottiin, miten tiedostossa oleva lähdekoodi näyttäytyy tietokoneen näkökulmasta – sehän oli numeroita, jotka kuvaavat merkkejä tietyn merkistökoodauksen mukaisesti. Miten sitten näyttäytyy suoritettava konekielinen ohjelma? Tiedoston sisältöä voidaan tietenkin tutkia jälleen komentoriviltä esimerkiksi hexdump-ohjelmalla. Tiedoston ensimmäiset 64 tavua näyttävät seuraavalta:

Tiedoston alussa on neljä ”taikamerkkiä”, jotka lupailevat sen lukijalle, että loppuosa koostuu täsmälleen tietyssä standardissa (Executable and Linkable File Format, ELF) määrätyistä osioista, joilla on sovittu sisältö. Kiinnostunut lukija löytänee tarkempia tietoja esimerkiksi Internetistä hakemalla. Heksavedoksen selailustakin voi päätellä, että tiedostossa on mm. toisteisia osioita, jotka itse asiassa ovat määrämittaisten tietorakenteiden muodostamia taulukoita. Lisäksi siellä on selväkielisiä merkkijonoja, kuten versiotietoja käytetystä kääntäjäohjelmasta. Osa merkkijonoista näyttäisi olevan tiedostosijainteja. Käyttöjärjestelmien mielessä mielenkiintoinen suoritettavaan ohjelmatiedostoon sisältyvä merkkijono on mm. ”/lib64/ld-linux-x86-64.so.2”, joka löytyy luentoesimerkissä ”jännästi” tasan 512 tavun päässä (heksana 0x200) tiedoston alusta lukien:

Tietysti myös teksti “Hello world” löytyy suoritettavan tiedoston sisältä jostakin kohtaa, kuten olettaa sopii.

Nyt voidaan ennakoivasti hahmottaa muutamaa yksityiskohtaa vaille, mitä esimerkiksi Linux tekee, kun shellin kautta annetaan komentona suoritettavan ohjelmatiedoston nimi: Se nimittäin

• koettaa hakemiston ja nimen perusteella etsiä tiedostoa tiedostojärjestelmästä
• varmistaa tiedostojärjestelmän erikseen tallennetuista metatiedoista, että käyttäjällä on suoritusoikeus tiedostoon
• tutkii tiedoston sisällön alusta muutaman taikanumeron ja päättää minkä ohjelman se käynnistää seuraavaksi:
  • Jos tiedoston alussa on heksat 0x23 0x21 eli ascii-merkistön merkit #!, käyttöjärjestelmä lukee tiedostoa ensimmäiseen rivinvaihtoon asti ja käynnistää ohjelman, jonka nimi löytyy huutomerkin ja rivinvaihdon välistä. Kyseiselle ohjelmalle käyttöjärjestelmä antaa koko tiedoston syötteeksi. Nyt ymmärretään, miksi demossa 2 piti aloittaa skripti kirjoittamalla ensimmäiselle riville #!/bin/bash. (Tämä ei ole POSIXin mukaan aivan sallittua, mutta se tekee jotkut meidän Linux-esimerkeistä helpommiksi)
  • Jos tiedoston alussa on heksat 0x7f 0x45 0x4c 0x46, joista viimeiset siis merkkijono ”ELF”, käyttöjärjestelmä käynnistää lataajaohjelman, jolla ohjelma haluaa itsensä ladattavan. Esimerkkimme tapauksessa ohjelmaan on tallennettu merkkijono ”/lib64/ld-linux-x86-64.so.2” juuri tätä tarkoitusta varten. Kyseinen lataajaohjelma sitten käynnistyy ja koko suoritettava tiedosto menee syötteeksi lataajalle. Nyt ehkä myös ymmärretään, miksi yhdelle käyttöjärjestelmälle käännettyä suoritettavaa ohjelmakoodia ei ainakaan suoraan pysty käynnistämään toisessa käyttöjärjestelmässä. (Toki esimerkkinä on nyt vain Linux, mutta vastaavia määritelmiä ja komponentteja on muissakin käyttöjärjestelmissä, eivätkä ne tosiaan ole keskenään suoraan yhteensopivia).
  • Muussa tapauksessa ainakin jotkut Linuxit nähtävästi olettavat, että ohjelma on tavallinen shell-skripti, olipa sen alussa #! tai ei.

Jokainen näistä vaiheista voi epäonnistua monista syistä. Esimerkiksi:

• Pyydetyn nimistä tiedostoa ei löydy paikoista, joita sitä etsitään. (virheilmoitus esim. ”command not found”)
• Käyttäjällä ei ole suoritusoikeutta tiedostoon. (virheilmoitus esim. ”Permission denied”)
• Löytyneen ELF-tiedoston muoto ei vastaa sitä, mitä Linux edellyttää. Näin käy esimerkiksi, jos ohjelma on käännetty eri prosessoriarkkitehtuuria varten kuin millä sitä yritetään suorittaa.
• ELFissä ilmoitettua latausohjelmaa tai skriptissä #!:lla ilmoitettua tulkkia ei syystä tai toisesta ole olemassa tai sitä ei pysty käynnistämään. (virheilmoitus esim. ”bad interpreter”)
• Muita ongelmia voidaan ymmärtää myöhemmin paremmin, kun ymmärretään lisää järjestelmän rajoitteista (mm. tarvittavia kirjastoja ei välttämättä ole asennettu, maksimimäärä prosesseja saattaa olla jo käynnissä, muisti voi olla täynnä, laitevika on aina mahdollinen…)

Suoritettava ohjelmakoodikin on tiedostossa ollessaan vielä vain pötkö määrämuotoon (tässä ELF) aseteltua dataa. Jotta päästään näkemään, miltä ohjelma näyttää lataamisen jälkeen tietokoneen muistissa, on käytettävä ”intrusiivista” työkalua, joka kertakaikkiaan antaa käyttöjärjestelmän ladata ohjelman suoritusvalmiiksi, mutta ottaa ohjelman sitten kontrolliinsa analysointia varten. Päätarkoitus on virheiden etsiminen ja korjaaminen, joten historiallisista syistä tällaista ohjelmaa sanotaan ”virheenpoistajaksi” eli debuggeriksi (engl. debugger). Muita käyttötarkoituksia voi olla esimerkiksi hakkerointi, toimintaperiaatteen selvittäminen ilman alkuperäistä lähdekoodia (”reverse-engineering”). Äärimmäisessä hätätilanteessa, jos jonkin elintärkeän ohjelman toiminta ei jostain syystä saa missään nimessä katketa hetkeksikään, voi siitä debuggerilla periaatteessa korjata vian tai toimintahäiriön ronkkimalla suoraan muistiin ladattua ja toiminnassa olevaa koodia tai dataa. Tehotyökalu siis on kyseessä. Arvatenkin tällä kurssilla käytämme debuggeria komentoriviltä. Tarkempia ohjeita tulee demoissa. Luennolla nähtiin seuraavanlainen debuggerilla tehty tuloste Hei maailma -ohjelmasta:

Tässä tulosteessa näkyy rivinumeroin varustettuna pääohjelman C-kieliset koodirivit. Kunkin koodirivin alla on siihen riviin liittyvät konekieliset käskyt, jotka kääntäjäohjelma on tuottanut. Vasemmassa sarakkeessa on heksanumerona muistiosoite, eli 8-bittisten tavujen juokseva numerointi, niistä muistipaikoista, joissa ohjelman konekieliset käskyt suorituksen aikana sijaitsevat. Lukemista helpottaa suluissa kymmenjärjestelmän lukuna ilmoitettu siirros aliohjelman ensimmäisen käskyn sijainnista alkaen. Seuraavassa sarakkeessa on konkreettiset konekieliset käskyt, eli tavun tai muutaman tavun mittaiset numerosarjat, joiden perusteella prosessori tekee aina jotakin hyvin yksinkertaista kerrallaan. Konkreettisten konekielisten tavusarjojen jälkeen tulosteessa on sama käsky symbolisella konekielellä eli assemblerilla (engl. assembly language) ilmaistuna.

Symbolinen konekieli käyttää käskyistä symboleita, joiden on tarkoitettu olevan ihmisen ymmärrettävissä ja kirjoitettavissa. Käyttöjärjestelmästä täytyy kirjoittaa assemblerilla aivan kaikkein matalimman abstraktiotason osuus, jonka tarvitsee kajota suoraan laitteiston konkreettisiin osiin, kuten esimerkiksi juuri tiettyyn rekisteriin. Myös prosessoriarkkitehtuurin dokumentaatio käyttää tyypillisesti assembleria selväkielisenä versiona prosessorin ominaisuuksien ja käskyjen toiminnan selittämiseksi. Manuaali kertoo tietenkin myös, miten nämä assemblerin tasolla kuvatut toiminnot muutetaan konkreettiseksi konekieleksi, jota valmistajan tekemä laite pystyy suorittamaan. Konekielisten tavujonojen tasolla laitteen rajapinta tarvitsee tuntea käytännössä vain, kun tehdään laitteelle kääntäjäohjelmistoa tai yritetään selvittää metatietojen puutteessa jostakin konekielisestä ohjelmanpätkästä, että millähän laitteella sitä mahdollisesti olisi tarkoitus ajaa. Esimerkiksi kaikissa ohjelmissa yleinen aliohjelmiin siirtyminen tai ns. pinomuistin käyttö voi tapahtua kussakin prosessoriarkkitehtuurissa leimallisella tavuyhdistelmällä, josta voi päätellä, mikä prosessoriarkkitehtuuri on kyseessä.

3.5 Ohjelman kääntäminen, objekti, kirjasto, linkittäminen ja lataaminen

Edellä nähtiin, kuinka tekstitiedostosta saatiin luotua suorituskelpoinen ohjelma, joka selvästi toimii niin kuin sen pitikin. Lisäksi katseltiin, miltä nämä tiedostot päällisin puolin näyttivät. Kaivetaan nyt vielä kerrosta syvemmältä: Mitä oikein tapahtui missäkin vaiheessa ja miksi?

Kääntäjäohjelma käynnistettiin komennolla c99. Tämän nimisen työkalun olemassaolohan on jotakin, minkä POSIX-standardi lupaa yhteensopivassa järjestelmässä. Komennolla pitää käynnistyä nimenomaan C99-standardin toteuttava C-kääntäjä.

Käytännössä Jyväskylän yliopiston suorakäyttökoneella keväällä 2015 tämä komento on itse asiassa shell-skripti! Kyseinen skripti löytyy tiedostosijainnista /usr/bin/c99, ja voit vaikka tulostaa skriptin sisällön ja ihmetellä, miten se on toteutettu. Se varmistaa, että käyttäjä ei ole argumenteillaan pyytänyt minkään muun standardiversion kuin C99:n mukaista C-käännöstä. Sitten se käynnistää GNU-projektin tekemän työkalun nimeltä gcc ja varmistaa, että kyseiselle ohjelmalle annetaan argumenttina -std=c99 sekä muut skriptin suorittajan antamat argumentit. Tuo varsinainen konekielinen kääntäjäohjelma tiedostosijainnissa /usr/bin/gcc hoitaa sitten loput ja käyttäytyy kuin C99-kääntäjä, koska sille on annettu standardin määrittävä argumentti.

Kääntäjäohjelma gcc tekee tässä tapauksessa konepellin alla muutakin kuin pelkän käännöksen. Hieman tarkemmin sanottuna:

• Yksittäinen C-kielinen lähdekooditiedosto käy ensin läpi ns. esikäännöksen, jossa poistetaan kommentit ja avataan ja muokataan koodia aika paljon. Yksinkertaisimpana esimerkkinä ”Hei maailma” -ohjelman ensimmäisen rivin sisältö #include<stdio.h> korvautuu tässä vaiheessa koodilla, joka luetaan otsikkotiedostosta ”stdio.h”. Myös otsikkotiedosto voi lukea muita otsikkotiedostoja, jotka kertakaikkiaan liitetään mukaan siihen kohtaan, missä tulee vastaan #include<tiedostonimi>. Tässä tapahtuu myös ns. makrojen avaaminen, mutta siitä lisää myöhemmin ja demojen yhteydessä. Esikäännöksen jälkeen koodi voi olla paljon alkuperäistä pidempi, eikä se sisällä enää yhtään kommenttia eikä yhtään esikääntäjän ohjauskomennoksi tarkoitettua riviä, jotka alkavat risuaidalla #. Tämä on aina C-käännöksen ensimmäinen vaihe.
• Samaan aikaan tai heti sen jälkeen koodi jäsennetään C:n syntaksin mukaisesti yhdellä läpikäynnillä koodin alusta sen loppuun – tämä on syy siihen, että C:ssä on pakko määritellä kunkin nimen luonne (eli onko se tyyppi, muuttuja vai aliohjelma) ennen kuin nimeä käytetään muihin tarkoituksiin kuin ensimäärittelyyn. C-kääntäjä ei yksinkertaisesti tiedä, mitä nimi tarkoittaa, mikäli sen määrittely tulee koodissa jäljempänä. Siksi on tyypillistä kirjoittaa aliohjelmat ennen pääohjelmaa, kirjastojen otsikkotiedostot on luettava mukaan #include:lla heti lähdekooditiedoston alussa jne.
• Kääntäjä saattaa muodostaa jonkin laitteistoriippumattoman välikielisen muodon eli jonkinlaisen ”meta-assembler” -koodin, joka vastaa melko läheisesti nykyisten tietokoneiden konekielten yhteisiä piirteitä, mutta on kuitenkin vielä hieman yleisemmässä muodossa. Välikielen käyttö helpottaa kääntäjän muokkaamista uuden prosessoriarkkitehtuurin mukaiseksi, koska konkreettinen konekieli on tuotettavissa välikielestä pienin muunnoksin verrattuna siihen, että pitäisi tuottaa sitä suoraan C-koodista. Välikieli selkeyttää myös uusien ohjelmointikielten lisäämistä kääntäjäinfrastruktuuriin: jos mille tahansa ohjelmointikielelle saadaan aikaan välikielinen käännös, niin ohjelmat saadaan välittömästi toimimaan kaikissa konkreettisissa prosessoriarkkitehtuureissa, joille välikieltä voidaan käyttää. Tämä on jälleen yksi esimerkki kerrosmaisen rakenteen käyttökelpoisuudesta.
• Kääntäjä tuottaa välikielestä kohteena olevan konkreettisen prosessoriarkkitehtuurin mukaista konekieltä. GNU-kääntäjä itse asiassa lisää tähän kohtaan vielä yhden kerroksen: se tuottaa ensin prosessoriarkkitehtuurin mukaista assembleria, joka lopulta käännetään konekieleksi assembler-kääntäjällä.
• Lopullinen objektitiedosto on assembler-kääntäjän tuottama. Siihen mennessä C-koodin (tai muun kielen) semantiikka on muuttunut ”putkiaivoisen” assembler-kääntäjän ymmärtämään muotoon, jossa ohjelma on jaettu dataa ja koodia sisältäviin pätkiin, joissa jokainen rivi muuttuu pienehköksi pötköksi peräkkäisiä tavuja joko dataosioon tai koodiosioon²⁵ . Objektitiedoston sisältämät tavut on organisoitu tiettyjen muotosääntöjen mukaan – meidän esimerkissämme ELF-formaatin mukaan.
• Objektitiedoston ei välttämättä tarvitse vielä olla suoritettavissa. Viimeisenä vaiheena tapahtuu nimittäin objektien, eli ohjelmaosioiden, liittäminen toisiinsa eli linkitys eli linkittäminen (engl. linking).
• Varsinkin kirjastot on suotuisaa liittää mukaan vain ennakoivana pyyntönä lataus- tai suoritusvaihetta varten.

Kunkin vaiheen suorittaa erillinen osio kääntäjäohjelmasta tai jopa erillinen apuohjelma, jonka kääntäjän julkisivuohjelma gcc käynnistää kunkin vaiheen tarpeisiin. Useimmiten ohjelmat ovat niin laajoja, että ne on tarkoituksenmukaista jakaa useisiin lähdekooditiedostoihin. Tyypillistä on, että kukin lähdekooditiedosto käännetään ensin erilliseksi, ei vielä suoritettavaksi, objektitiedostoksi, ja sitten lopuksi kaikki nämä objektitiedostot liitetään toisiinsa linkitysvaiheessa. Välivaiheissa syntyviä tiedostoja kääntäjä säilyttää järjestelmän hakemistossa /tmp/, mutta tuhoaa ne siinä vaiheessa, kun lopulliset objektit on kirjoitettu käyttäjän haluamaan paikkaan.

Edellä mainittiin, että linkitys voidaan tehdä ohjelman viimeistelyvaiheen lisäksi myös ennakoivana pyyntönä latausvaiheen osalta. Tämä on tärkeää varsinkin kirjastojen osalta. Olisi suurta resurssihukkaa liittää isot ja yleisesti käytetyt apukirjastot, mukaanlukien C:n standardikirjastot tai monessa ohjelmassa käytettävät graafiset kirjastot mukaan kaikkiin niitä tarvitseviin ohjelmiin! On paljon kompaktimpaa, jos kirjastot asennetaan tietokoneelle yhteiskäyttöön ja ne liitetään ohjelmiin vastsa siinä vaiheessa, kun ohjelmat ladataan muistiin suoritettavaksi prosessiksi – siinä vaiheessahan niitä vasta tarvitsee käyttää. Tällöin puhutaan dynaamisesta linkittämisestä (engl. dynamic linking) ja siitä on tullut nykyinen maailman tapa. Unix-maailmassa dynaamisesti linkitettävän kirjaston nimi on ”jaettu objektitiedosto” (engl. shared object, ”so”) ja Windows-puolella ”dynaamisesti linkitettävä kirjasto” (engl. dynamically linked library, DLL). Molempien termien etymologia lienee edeltävän selostuksen perusteella järkeenkäypä. Kokenut ohjelmoija yleistää päässään kumman tahansa sanan samaan käsitteeseen.

Kun käyttöjärjestelmä käynnistää suoritettavan ohjelmatiedoston prosessiksi, se oikeastaan hyödyntää osiota tai työkaluohjelmaa nimeltä lataaja (engl. loader), jonka tehtäväksi käännöslinkkeri on jättänyt dynaamisten kirjastojen yhdistämisen. Käynnistysvaiheessa tapahtuu jotakuinkin seuraavaa:

• Ensinnäkin tutkittuaan suoritettavaksi tarkoitettua tiedostonimeä, käyttöjärjestelmä on tullut siihen tulokseen, että nimen mukainen tiedosto aivan oikeasti on suoritettavissa (se on olemassa ja luettavissa tiedostojärjestelmässä, tunnistetussa suorituskelpoisessa formaatissa ja käyttöoikeuksiltaan suoritusta pyytäneen käyttäjän sallituissa rajoissa). Meidän esimerkissämme formaatti on ELF, kuten Linuxissa yleensä. Windowsissa formaatti olisi Portable Executable eli PE-formaatti.
• Sitten alkaa lataaminen: ELF (ja Windowsissa PE) -formaatti määrittelee merkityksen tiedoston datapötkön osioille, jotka lataaja lukee ja tulkitsee.
• ELF-tiedostoon sisältyy paljonkin tietoja, elintärkeimpinä datan ja koodin sijainti tiedostossa, nämä ovat kokonaislukuja, jotka kuvaavat tavujen sijaintia tiedoston alusta lukien sekä vaatimukset siitä, mihin muistiosoitteisiin nämä pätkät tulisi sijoittaa.
• Lataaja varaa järjestelmästä muistia niin paljon kuin ohjelma ilmoittamiensa tietojen mukaan tarvitsee. Sitten se lukee kunkin ohjelmaosion muistiin ja laittaa osiot sijaitsemaan muistiosoitteissa, joihin ELF-tiedosto ne toivoo. Tässä vaiheessa täytyy herätä relevantti kysymys moniajosta: Eivätkö yhtäaikaa suoritettavat ohjelmat voi mennä ikävästi keskenään ristiin, jos ne vahingossa pyytävät niiden koodia latautumaan samoihin muistiosoitteisiin? Tämä ei ole kuitenkaan millään tavalla ongelma, koska muistiosoitteet ovat ns. virtuaalisia. Aiheeseen palataan vahvasti, mutta tässä vaiheessa on pakko vielä hetkeksi jättää kysymys kiusaamaan mieltä.
• ELFiin sisältyy myös tieto niistä dynaamisista kirjastoista, joita ohjelma haluaisi käyttää. Lataaja voi ladata myös pyydetyt dynaamiset kirjastot (”epälaiska linkittäminen”), tai vähintään se tallentaa niiden sijainnista tiedot, joiden perusteella lataamista voidaan yrittää siinä vaiheessa, kun ohjelma haluaa ensimmäisen kerran käyttää kirjaston palveluita (”laiska linkittäminen”). Lataaja päättää, mihin muistiosoitteeseen kirjastojen koodi ja data tulevat niitä hyödyntävän prosessin käytettäviksi. Kirjastotiedostot ja niistä tarvittavat aliohjelmat ja vakiodatat ilmaistaan ELFissä merkkijonosymboleina (”selväkieliset” nimet, joita objektitiedostossa voi nähdä)
• Objektitiedostossa ei voi olla konkreettisia numeroita muistiosoitteina, ainakaan kirjastoihin viittaavia osoitteita, koska kirjastojen muistisijaintia ei ole mahdollisuutta tietää siinä vaiheessa, kun ohjelma käännetään. Lataajan tehtävänä on siis samalla yhdistellä oikein kaikki ohjelman tarvitsemat muistiosoiteviitteet. Osa sovellusohjelman koodista voi viitata ennalta laskettuihin osoitteisiin, mutta tämä edellyttää, että ohjelma ladataan aina juuri tiettyyn osoitteeseen; dynaamisten kirjastojen koodissa ei mitenkään voi olla konkreettisia ”kovakoodattuja” muistiosoitteita, koska ne ladataan aina tilanteen mukaan vapaana oleviin osoitteisiin.
• Kun kaikki on valmista, lataaja päästää ohjelman rullaamaan muistiosoitteesta, jonka ELF ilmoitti halutuksi sisäänmenopisteeksi (engl. entry point). Siis prosessorin IP-rekisteriin (meidän esimerkkilaitteessamme nimeltään RIP) ladataan sisällöksi ELFissä ilmoitettu aloitusosoite, jolloin kontrolli siirtyy ladatulle käyttäjän ohjelmalle. Tässä vaiheessa ohjelman suoritusta sanotaan prosessiksi, kun koodi on ladattu ja käynnistetty ja se rullailee omana instanssinaan.

Tässä listassa oli melko karkea yleistys tapahtumista ohjelmakoodin käynnistämisessä. Mieleen pitäisi jäädä, että ohjelman tie lähdekoodista suoritukseen on monivaiheinen ja että ohjelma ilmenee matkalla varsin erilaisissa muodoissa vielä senkin jälkeen, kun se on käännetty suoritettavaksi. Lopullinen konekielimuoto on olemassa vasta sen jälkeen, kun lataaja on käynnistyksen yhteydessä laittanut paikoilleen oikeat muistiosoitteet, kuten esimerkiksi ”Hei maailma”:n ensimmäisen H-kirjaimen osoitteen. Linkittämisen ja lataamisen yksityiskohtia voi halutessaan opiskella vaikkapa kirjasta Linkers and Loaders [7], mikäli aihe alkaa kiinnostaa enemmän.

3.6 Käännös- ja linkitysjärjestelmät, IDE:t

Ohjelmointi 1:ltä tuttu tapa ohjelmien tekemiseen on C#:n IDE²⁶ . Ohjelmointi 2:lla vastaan tulee uusi erilainen, mutta toiminnoiltaan hyvin samankaltainen IDE. Tieteellistä laskentaa tehdään paljon Matlabilla, joka on yhdenlainen IDE. IDE:t organisoivat ja visualisoivat koodia ohjelmakehittäjän kannalta hyödyllisellä tavalla ja automatisoivat mahdollisimman pitkälti toimintoja, kuten kääntämistä, linkittämistä, lataamista.

Tällä kurssilla päästään näkemään konkreettisesti mitä myös IDE:t tekevät konepellin alla: Lähdekoodi, debuggaustieto, suoritettavat kehitys- ja tuotantoversiot sijaitsevat tiedostojärjestelmässä paikoissa, joista IDE pitää huolta grafiikkansa takana. Ohjelmat tarvitsevat toimiakseen kirjastoja, joiden sijainnista ja löytymisestä IDE:n on pidettävä huolta. Erilaisia säätöjä tarvitaan vähintään kehitys- ja tuotantoversion välillä. Nämä klikataan graafisen käyttöliittymän kautta, mutta varsin usein lopputulemana IDE käynnistelee kääntäjä- ja linkitysohjelmia erilaisilla komentoriviargumenteilla. IDEn tarvitsemat säädöt ja tieto kuhunkin projektiin liittyvien tiedostojen sijainneista ovat tallessa jonkinlaisessa kuvaustiedostossa tai useammassa.

Samat vaiheet on mahdollista, ja joskus pakkokin, tehdä suoraan komentoriviltä, jos vaikka jonkun ongelman syy liittyy välivaiheeseen, jonka tulosta on vaikea hahmottaa IDE:n käyttöliittymästä. Demossa 4 käydään läpi useita lähdekooditiedostoja sisältävän C-kielisen ohjelman kääntämistä suoraan komentoriviltä. Käytännössä homma kuitenkin tarvitsee apuvälineitä, kun ohjelman laajuus kasvaa mielenkiintoisemmaksi. Minimaalinen apu ohjelman lähdekooditiedostojen automaattiseen kääntämiseen ja linkittämiseen on ohjelmantekotyökalu make, jonka käyttöä demossa 4 myös katsotaan alustavasti. Projektin sisältö kuvataan silloin tietyn muotoisessa ns. tekemisohjetiedostossa, jonka nimi on tyypillisesti ”Makefile”. Kun tämä tiedosto on kunnossa, isommankin ohjelman muunnos lähdekoodikasasta toimivaksi ohjelmaksi tapahtuu komentamalla shellissä make – ja muuta ei tarvita. Ilman IDEä tehtävään ohjelmien kääntämiseen on yleisessä käytössä vielä make-työkaluakin tehokkaampia välineitä, mutta jätetään ne sitten omatoimisen tai työtehtävissä tapahtuvan täsmäopiskelun varaan. Suurin osa ohjelmistokehityksestä tapahtuu kuitenkin todennäköisesti jossakin IDEssä²⁷ .

3.7 Ohjelman toimintaympäristö

Ohjelman toimintaan voi vaikuttaa käynnistyksen yhteydessä komentoriviargumenteilla ja lisäksi ympäristömuuttujilla. Näiden käyttö on tarkoitus oppia C-kielen osalta esimerkin kautta demossa 3 ja shell-skriptien osalta myöhemmässä demossa.

3.8 Käännettävät ja tulkattavat ohjelmat; skriptit

Edellä nähtiin, että C-kielinen ohjelma täytyy kääntää konekielelle ennen kuin sitä voidaan suorittaa tietyssä prosessorissa ja käyttöjärjestelmässä. Kieli on siis käännettävä ohjelmointikieli (engl. compiled programming language). Kun käännös on fyysisen tietokonelaitteen konekieltä, puhutaan lähdekoodista tehdystä ”natiivikäännöksestä”, ”natiivikoodista” ja ”natiivista ohjelmasta” (engl. native code). Toinen yleinen esimerkki natiivikäännöksiä tukevasta kielestä on olio-ohjelmointiin tarkoitettu C++, joka on täysin eri kieli kuin C, vaikka se historiansa johdosta sisältää C:n osajoukkonaan ja kykenee tarvittaessa samanlaiseen laiteläheisyyteen.

Jotkut käännettävät kielet, kuten C# ja Java, käännetään muotoon, joka ei ole natiivia koodia vaan kuvitteellisen (ts. näennäisen, virtuaalisen) prosessorin konekieltä, joka on määritelty vastaamaan läheisesti tyypillisten prosessorien toimintaa, mutta on hiukan simppelimpi käyttää ja mm. muistinhallinnan osalta ”älykkäämpi” kuin mitä oikea kone pystyisi olemaan. Lisäksi se mahdollistaa käännettyjen ohjelmien suorittamisen uudella laitealustalla, mikäli virtuaalikone saadaan toteutettua kyseiselle alustalle. Ohjelma käynnistetään ja suoritetaan virtuaalisen laitteistorajapinnan toteuttavan ohjelman eli virtuaalikoneen kautta. Virtuaalikone tulkitsee virtuaalista konekieltä käsky käskyltä lennosta ja kääntää sitä natiivikoodiksi ”juuri ajoissa” ajonaikaisella kääntämisellä (engl. just-in-time compilation, JIT). Näissäkin käännös tavukielelle ja kirjastojen linkittäminen tapahtuvat samantyyppisillä mekanismeilla kuin natiiveissa konekielisissä ohjelmissa. Virtuaalikoneen itse on oltava natiivi ohjelma, joka käyttää allaan olevaa laitteistoa ja käyttöjärjestelmää ja välittää sen palveluita sovellukselle, jota sen päällä puolestaan ajetaan. Nämä virtuaalikoneet ovat yksi hyvä esimerkki kerrosmaisesta rakenteesta laitteiston ja sovellusten välillä. Rakenne voi nykyisellään olla hyvinkin syvästi kerrostunut.

Jotkut kielet ovat vielä tätäkin puhtaammin tulkattavia kieliä (engl. interpreted languages) siinä mielessä, että niissä ihmisen ymmärtämässä muodossa oleva lähdekoodi tulkitaan rivi kerrallaan lennosta, ilman välttämätöntä tarvetta kääntää lähdekoodia natiiviksi eikä edes minkään virtuaalikoneen tavukoodiksi ennen ohjelman suorittamista. Tunnettuja ja tiettyihin tarkoituksiin suosittuja tulkattavia kieliä ovat esimerkiksi Python, Perl ja PHP – nämäkin tosin voivat hyödyntää konekielimäistä välikieltä toimintanopeuden optimoimiseksi. Tulkattavat kielet mahdollistavat luonnostaan niiden interaktiivisen käyttämisen: käyttäjä voi antaa kielen syntaksin mukaisia komentoja rivi kerrallaan ja nähdä tulokset välittömästi. POSIXin määrittelemä shell syntakseineen ja pakollisine apusovelluksineen on yksi esimerkki tulkattavasta kielestä. Syntaksiltaan se on rankempaan sovellusohjelmointiin suunniteltuja sukulaisiaan jäykempi, ja suorituskyky ei ole kummoinen, mutta se taipuu helposti moniin käyttöjärjestelmän ylös- ja alasajoon, ylläpitoon ja ohjelmien asennusten tarvitsemiin tehtäviin. Ja se on määritelty rajapintastandardissa, joten yhteensopivassa järjestelmässä se on aina asennettuna ja toimii tunnetulla tavalla!

Tässä kohtaa on hyvä tehdä myös lisähuomio sovellusten ja kirjastojen kerroksellisuudesta.. Tulkattavan kielen tulkkiohjelma voisi itsekin toimia tulkin tai virtuaalikoneen päällä, virtuaalikone toisen virtuaalikoneen päällä. Kerroksia voi olla päällekkäin vaikka kuinka monta ihan suorituksen aikanakin. Sovelluksen tekijän tarvitsee olla kiinnostunut vain tarpeeseen valitun alustan rajapinnasta.

Natiivikaan koodi ei voi ”tietää”, toimiiko se virtuaalisessa tai simuloidussa prosessorissa vai ”oikeassa”. Viimeisessä lauseessa ”oikea” on lainausmerkeissä, koska nykyisessä prosessorissa itsessään on kerrosmainen ja osin rinnakkainen rakenne, jossa todellisuudessa suoritetaan välissä vielä erilaista konekieltä eli ns. mikrokoodia (engl. micro code). Virtuaalikoneen tavoin myös oikea fyysinen prosessori palastelee ja optimoi sille syötettyä tavukoodia, eikä esimerkiksi käskyjen todellista suoritusjärjestystä voi tarkkaan määrätä. Rajapinta lupaa kuitenkin, että kaikkien ulkomaailmaan näkyvien ilmiöiden suhteen näyttää aina siltä, että suoritusjärjestys olisi se, mitä prosessorille on manuaalin ohjeiden mukaan syötetty.

4 Konekielisen ohjelman suoritus

Avainsanat: symbolinen konekieli eli assembler, käskysymboli, operandi, lähde ja kohde (käskyn), takaisinkääntäminen (engl. disassembly), suorituspino, peräkkäisjärjestys, ehtorakenne, toistorakenne, aliohjelma, poikkeus, kontrollin siirtyminen, ehdoton ja ehdollinen hyppykäsky

Osaamistavoitteet: Luvun luettuaan opiskelija:

• ymmärtää ohjelman suorituksen muistissa sijaitsevien konekielisten käskyjen jonona sekä tyypillisten ohjelmointirakenteiden ilmenemisen konekielessä; tunnistaa konekielisen ohjelman sellaisen nähdessään (AT&T tai Intel -tyyppisenä assemblynä tai disassemblynä) [ydin/arvos2]
• osaa lukea lyhyitä (so. 2-10 käskyä) suomen kielellä rivi riviltä kommentoituja konekielisiä ohjelmanpätkiä ja muodostaa mielessään (tai kynällä ja paperilla) niiden jäljen sekä niiden suorittamisen aiheuttamat tilapäiset ja pysyvät vaikutukset tietokoneen rekistereihin ja muistiin [edist/arvos4]

Edellisessä luvussa kerrattiin varsin yleisellä tasolla esitietoja siitä, millainen laite tietokone yleisesti ottaen on. Tarkempi tietämys on hankittava oma-aloitteisesti tai tietotekniikan laiteläheisillä kursseilla. Tässä luvussa valaistaan konekielen piirteitä lisää käytännön esimerkkien kautta. Esimerkkiarkkitehtuuri on ns. x86-64 -arkkitehtuuri. Yhtä hyvin esimerkkinä voisi olla mikä tahansa, jolla olisi helppo pyöräytellä esimerkkejä. Valinta tehdään nyt tällä tavoin, koska Jyväskylän yliopiston IT-palveluiden tarjoamat palvelinkoneet, joihin opiskelijat pääsevät helposti käsiksi ja joissa kurssin harjoituksia voidaan tehdä, ovat tällä hetkellä malliltaan useampiytimisiä Intel Xeon -prosessoreja, joiden arkkitehtuuri on nimenomaan x86-64. Toivottavasti nykyaikaisen prosessorin käsittely on motivoivaa ja tarjoaa teorian lisäksi käytännön kädentaitoja tulevaisuutta varten.

Kurssin ydinaineksen osalta käytännön tekeminen ja ajattelu viedään loppuun demossa 5, jossa olisi tarkoitus ajella ohjelmaa debuggerilla ja katsella sen jälkeä lokitiedostosta.

4.1 Esimerkkiarkkitehtuuri: x86-64

Hieman x86-64:n taustaa: Prosessoriteknologiaan keskittyvä yritys nimeltä Intel julkaisi aikoinaan mm. toisiaan seuranneet prosessorimallit (ja arkkitehtuurit) nimeltä 8086, 80186, 80286, 80386, 80486 ja Pentium. Malleissa ominaisuudet laajenivat teknologian kehittyessä, sananleveyskin muuttui 80386:n kohdalla 16 bitistä 32 bittiin, mutta konekielitason yhteensopivuudesta aiempien mallien kanssa pidettiin huolta. Tämän tuote- ja arkkitehtuurijatkumon nimeksi on ymmärrettävistä syistä muodostunut ”x86-sarja”. Muiden muassa toinen tunnettu prosessorivalmistaja, nimeltään AMD, toteutti omia prosessorejaan, joiden ulkoinen rajapinta vastasi Intelin suosittua arkkitehtuuria. Samat ohjelmat ja käyttöjärjestelmät toimivat eri yritysten valmistamissa prosessoreissa samalla tavoin ihan konekielen tasolla.

Sittemmin juuri AMD kehitti sananleveydeltään 64-bittisen arkkitehtuurin, joka jatkaa Intelin x86-jatkumoa nykyaikaisesti mutta edelleen yhteensopivasti vanhojen x86-arkkitehtuurien kanssa. Tällä kertaa Intel on ’kloonannut’ tämän AMD64:ksi nimetyn arkkitehtuurin nimikkeellä Intel64 ja valmistaa prosessoreja, joissa AMD64:lle käännetty konekieli toimii lähes identtisesti. Intel64 ja AMD64 ovat rajapinnaltaan lähes samanlaisia, ja niille on ainakin linux-maailman puolella napattu AMD:n alkuperäisestä dokumentaatiosta yhteisnimeksi x86-64, joka kuvaa toisaalta periytymistä Intelin x86-sarjasta ja toisaalta leimallista 64-bittisyyttä (eli sitä, että rekistereissä ja muistiosoitteissa on 64 bittiä rivissä). Joitakin eroja Intelin ja AMD:n variaatioissa on, mutta lähinnä niillä on merkitystä yhteensopivien kääntäjien valmistajille sekä erityisten nopeusoptimointien tarvitsijoille. Muita käytössä olevia nimityksiä samalle arkkitehtuurille ovat mm. x64, x86_64. Käytettäköön tämän monisteen puitteissa jatkossa nimeä x86-64.

Muista erilaisista nykyisistä prosessoriarkkitehtuureista mainittakoon ainakin IBM Cell (mm. Playstation 3:n multimediamylly) sekä ARM-sarjan prosessorit (jollainen löytyy monista sulautetuista järjestelmistä kuten kännyköistä).

Haasteelliseksi x86-64:n käyttämisen kurssin esimerkkinä tekee muun muassa se, että arkkitehtuuria ei ole suunniteltu puhtaalta pöydältä vaan taaksepäin-yhteensopivaksi. Esimerkiksi 1980-luvulla tehdyt ja konekieleksi käännetyt 8086-arkkitehtuurin ohjelmat toimivat muuttamattomina x86-64 -koneissa, vaikka välissä on ollut useita prosessorisukupolvia teknisine harppauksineen. Käskykannassa ja rekisterien nimissä nähdään siis joitakin historiallisia jäänteitä, joita tuskin olisi tullut mukaan täysin uutta arkkitehtuuria suunniteltaessa.

Käyttäjän näkemät rekisterit x86-64 -arkkitehtuurissa

Nyt toivottavasti on riittävästi pohjatietoa, että voidaan vain esimerkinomaisesti listata eräässä prosessorissa käytettävissä olevia rekisterejä merkityksineen niillä lyhyillä nimillä, jotka prosessorivalmistaja on antanut. Taulukossa 1 on suurin osa rekistereistä, joita ohjelmoija voi käyttää Intelin Xeon -prosessorissa (tai muussa x86-64 arkkitehtuurin mukaisessa prosessorissa) aidossa 64-bittisessä tilassa. Yhteensopivuustiloissa olisi käytössä vain osa näistä rekistereistä, ja rekisterien biteistä käytettäisiin vain 32-bittistä tai 16-bittistä osaa, riippuen siitä monenko vuosikymmenen takaiselle x86-prosessorille ohjelma olisi käännetty.

Jokaisessa x86-64:n rekisterissä voidaan säilyttää 64 bittiä. Rekistereistä voidaan käyttää joko kokonaisuutta tai 32-bittistä, 16-bittistä tai jompaa kumpaa kahdesta 8-bittisestä osasta. Kuvassa 10 on esimerkiksi RAX:n osat ja niiden nimet; bitit on numeroitu siten, että 0 on vähiten merkitsevä ja 63 eniten merkitsevä bitti. Esim. yhden 8-bittisen ASCII-merkin käsittelyyn riittäisi AL, 32-bittiselle kokonaisluvulle (tai 4-tavuiselle Unicode-merkille) riittäisi EAX, ja 64-bittinen kokonaisluku tai muistiosoite tarvitsisi koko rekisterin RAX.

Jatkossa keskitytään lähinnä yleiskäyttöisiin kokonaislukurekistereihin. Käsittelemättä jätetään liukulukulaskentaan ja multimediakäyttöön tarkoitetut rekisterit (FPR0-FPR7, MMX0-MMX7 ja XMM0-XMM15). Esimerkiksi siinä vaiheessa, kun on kriittistä tehdä aiempaa tarkempi sääennuste aiempaa nopeammin, saattaa olla ajankohtaista opetella FPR0-FPR7-rekisterit ja niihin liittyvä käskykannan osuus. Siinä vaiheessa, kun haluaa tehdä naapurifirmaa hienomman ja tehokkaamman 3D-koneiston tietokonepelejä tai lentosimulaattoria varten, on syytä tutustua multimediarekistereihin. Aika pitkälle ’tarpeeksi tehokkaan’ ohjelman tekemisessä pääsee käyttämällä liukuluku- ja multimediasovelluksissa jotakin valmista kääntäjää, kirjastoa ja/tai virtuaalikonetta. Joka tapauksessa ohjelman suoritusnopeus perustuu kaikista eniten algoritmien ja tietorakenteiden valintaan, ei jonkun algoritmin konekielitoteutukseen. Lisäksi nykyiset kääntäjät pystyvät ns. optimoimaan käännetyn ohjelman, eli luomaan juuri sellaiset konekieliset komennot jotka toimivat erittäin nopeasti. Mutta älä koskaan sano ettei koskaan…voihan sitä päätyä töihin vaikka firmaan, joka nimenomaan toteuttaa noita kirjastoja, kääntäjiä tai virtuaalikoneita ²⁸.

Tällaisia rekisterejä siis x86-64 -tietokoneen sovellusohjelmien konekielisessä käännöksessä voidaan nähdä ja käyttää. Ne ovat esimerkkiarkkitehtuurimme käyttäjälle näkyvät rekisterit. Käyttöjärjestelmäkoodi voi käyttää näiden lisäksi systeemirekisterejä ja systeemikäskyjä, siis prosessorin ja käskykannan osaa, joilla muistinhallintaa, laitteistoa ja ohjelmien suojausta hallitaan. Systeemirekisterejä on esim. AMD64:n spesifikaatiossa eri tarkoituksiin yhteensä 50 kpl. Jos käyttäjän ohjelma yrittää jotakin niistä käyttää, seuraa suojausvirhe, ja ohjelma kaatuu saman tien (suoritus palautuu käyttöjärjestelmän koodiin). Tällä kurssilla nähdään esimerkkejä lähinnä käyttäjätilan sovellusten koodista. Käyttäjän ja käyttöjärjestelmän rekisterien lisäksi prosessorissa on oletettavasti sisäisiä rekisterejä väyläosoitteiden ja käskyjen väliaikaisia tallennuksia varten, mutta jätetään ne tosiaan tällä kertaa maininnan tasolle, koska niihin ei ole pääsyä ohjelmointikeinoin, eivätkä ne siten kuulu julkisesti dokumentoituun (laitteisto)rajapintaan.

4.2 Konekieli ja assembler

Konekielen bittijonoa on järkevää tuottaa vain kääntäjäohjelman avulla. Käsityönä se olisi mahdottoman hankalaa – kielijärjestelmiä ja automaattisia kääntäjäohjelmia on aina tarvittu, ja siksi niitä on ollut olemassa lähes yhtä pitkään kuin tietokoneita. Sovellusohjelmoija pääsee lähimmäksi todellista konekieltä käyttämällä ns. symbolista konekieltä eli assembleria / assemblyä (engl. assembly language), joka muunnetaan bittijonoksi assemblerilla (engl. assembler) eli symbolisen konekielen kääntäjällä. Jokaisella eri prosessorilla on oman käskykantansa mukainen assembler. Yksi assemblerkielinen rivi kääntyy yhdeksi konekieliseksi käskyksi. Rivi voi myös sisältää dataa, jonka assembler-kääntäjä sisällyttää objektitiedostoon sellaisenaan. Käyttöjärjestelmän ohjelmakoodista pienehkö mutta sitäkin tärkeämpi osa on kirjoitettava assemblerilla, joten tällä kurssilla ilmeisesti käsitellään sitä. Se on myös oiva apuväline prosessorin toiminnan ymmärtämiseksi (ja yleisemmin ohjelman suorituksen ymmärtämiseksi… ja myös korkeamman abstraktiotason kielijärjestelmien arvostamiseksi!). Assembler-koodin rivi voi näyttää päällisin puolin esimerkiksi tältä:

Kyseinen rivi voisi hyvin olla x86-64 -arkkitehtuurin mukaista, joskin yhden rivin perusteella olisi vaikea vetää lopullista johtopäätöstä. Erot joissain yksittäisissä assembler-käskyissä ovat arkkitehtuurien välillä olemattomia. Prosessorivalmistajan julkaisema arkkitehtuuridokumentaatio on yleensä se, joka määrittelee symbolisessa konekielessä käytetyt sanat. Jokaisella konekielikäskyllä on käskysymboli (vai miten sen suomentaisi, ehkä ’muistike’ tjsp., englanniksi kun se on mnemonic). Yllä olevan esimerkin tapauksessa symboli on movq. Käskyn symboli on tyypillisesti jonkinlainen helpohkosti muistettava lyhenne sen merkityksestä. Jos tämä olisi x86-64 -arkkitehtuurin käsky, movq (joka AMD64:n manuaalissa kirjoitetaan isoilla kirjaimilla MOV ilman q-lisuketta) olisi lyhenne sanoista ”Move quadword”. Sen merkitys olisi siirtää ’nelisana’ eli 64 bittiä paikasta toiseen. Tieto siitä, mistä mihin siirretään, annetaan operandeina, jotka tässä tapauksessa näyttäisivät x86-64:n määrittelemiltä rekistereiltä rsp ja rbp (AMD64:n dokumentaatiossa isoilla kirjaimilla RSP ja RBP). Käskyillä on useimmiten nolla, yksi tai kaksi operandia. Joka tapauksessa osa käskyn suoritukseen vaikuttavista syötteistä voi tulla muualtakin kuin operandeina ilmoitetusta paikasta – esim. FLAGS:n biteistä, tietyistä rekistereistä, tai jostain tietystä muistiosoitteesta. Jos operandina on rekisteri, jossa on muistiosoite, ja käskyn halutaan vaikuttavan muistipaikan sisältöön, puhutaan epäsuorasta osoittamisesta, (engl. indirect addressing). Tietyn prosessoriarkkitehtuurin dokumentaation käskykanta-osuudessa kerrotaan aina hyvin täsmällisesti, mitkä kunkin käskyn kaikki mahdolliset syötteet, tulosteet ja sivuvaikutukset prosessorin tai keskusmuistin seuraavaan tilaan ovat. Esimerkin tapauksessa nuo 64 bittiä kopioitaisiin prosessorin sisällä rekisteristä rsp rekisteriin rbp. Sanotaan, että käskyn lähde (engl. source) on tässä tapauksessa rekisteri rsp ja kohde (engl. destination) on rekisteri rbp. Koska siirto on rekisterien välillä, ulkoista väylää ei tarvitse käyttää, joten se on erittäin nopea toimenpide suorittaa. Siirtokäskyllä ei ole vaikutusta lippurekisteriin. Vaikka käskyn virallinen nimi viittaa siirtämiseen, on toimenpidettä syytä ajatella kopioimisena, sillä lähdepaikka ei siirtokäskyssä tyhjene tai muutu muutenkaan, vaan ainoastaan kohdepaikan aiempi sisältö korvautuu lähdepaikassa olleilla biteillä.

Prosenttimerkki % ylläolevassa on riippumaton x86-64:stä; se on osa tässä käytettyä yleisempää assembler-syntaksia, jota kurssillamme tänä kesänä käytettävät GNU-työkalut noudattavat.

Jotta ohjelmoijan maailmasta olisi saatu vaikeampi (tai ehkä kuitenkin muista historiallisista syistä), noudattavat jotkut assembler-työkalut ihan erilaista syntaksia kuin GNU-työkalut. GNU-työkalujen oletusarvoisesti noudattama syntaksi on nimeltään ’AT&T-syntaksi’ ja se toinen taas on ’Intel-syntaksi’. Ylläoleva rivi olisi siinä toisessa syntaksissa jotakuinkin näin:

Prosenttimerkki puuttuu, mutta merkittävämpi ero edelliseen on se, että operandit ovat eri järjestyksessä!! Eli lähde onkin oikealla ja kohde vasemmalla puolen pilkkua. Jonkun mielestä kai asiat ovat loogisia näin, että siirretään ’johonkin jotakin’ ja jonkun toisen mielestä taas niin, että siirretään ’jotakin johonkin’. Jonkun ikivanhan prosessoriarkkitehtuurin konekielen tavujen järjestys on saattanut vaikuttaa myös. Perimmäiset suunnitteluperusteet syntaksien luonteeseen, jos sellaisia ylipäätään on, ovat vaikeita löytää. Tänä päivänä käytetään molempia notaatioita, ja täytyy aina ensin vähän katsastella assembler-koodia ja dokumentaatiota ja päätellä jostakin, kumpi syntaksi nyt onkaan kyseessä, eli miten päin lähteitä ja kohteita ajatellaan. Tämän luentomonisteen kaikissa esimerkeissä lähdeoperandi on vasemmalla ja kohde oikealla puolella pilkkua. Käytämme siis AT&T-syntaksia, tarkemmin sen GNU-variaatiota [5], jota gas eli GNU Assembler käyttää.

Olipa syntaksi tuo tai tämä, assembler-kääntäjän homma on muodostaa prosessorin ymmärtämä bittijono symbolisen rivin perusteella. Paljastetaan tässä, että tuo ylläoleva rivi on ohjelmasta, johon se kääntyy kuten kuvassa 11 sivulla 111 on esitetty.

Assembler-käännös taitaa olla ainoa ohjelmointikäännös, joka puolijärjellisellä tavalla on tehtävissä toisin päin: Konekielinen bittijono nimittäin voidaan kääntää takaisin ihmisen ymmärtämälle assemblerille. Sanotaan, että tehdään takaisinkäännös (engl. disassembly). Tällä tavoin voidaan tutkia ohjelman toimintaa, vaikkei lähdekoodia olisi saatavilla. Työlästähän se on, ja ”viimeinen keino” debuggauksessa tai teollisuusvakoilussa, mutta mahdollista kuitenkin. Assembler-kielinen lähdekoodi sinänsä on kokeneen silmään ihan selkeätä, mutta ilman lähdekoodia tehdyssä takaisinkäännöksessä ei ole käytettävissä muuttujien tai muistiosoitteiden kuvaavia nimiä – kaikki on vain suhteellisia numeroindeksejä suhteessa rekisterien kullakin hetkellä sisältämiin muistiosoitteisiin. Kokonaisuutta on silloin aika mahdoton hahmottaa ilman suurta päättelytyötä. Sillä tavoin tietokone käsittelee ohjelman suoritusta eri tavoin kuin ihminen – ihminen tarvitsee käsinkosketeltavia nimiä asioille, kone taas vain numeroita.

4.3 ”Hello world!” suoraan assemblerilla

C-kielen sekaan voi useimmissa kääntäjissä lykätä kääntäjän omalla syntaksilla jonkin prosessoriarkkitehtuurin mukaista assembleria suoraan rivien väliin (engl. inline assembly). Esimerkkejä tästä löytyy kurssimateriaalin kevään 2015 esimerkkihakemistosta viidennen luennon kohdalta, mikäli niihin haluaa palata. Käyttötarkoituksia kielten sekoittamiselle löytyy kuitenkin hyvin harvoin. Kiinnostuneempia olemme standardin mukaisesta C:stä ja puhtaasta esimerkkiarkkitehtuurimme eli x86-64:n assemblerista. Pääasiassa kurssilla katsomme vain takaisinkäännöksiä, mutta niiden ymmärtäminen voi olla helpointa aloittaa katsomalla ensiksi konreettista, kokonaista assemblerilla tehtyä ohjelmaa. ”Hei maailma” soveltuu tähänkin tarkoitukseen.

Seuraavassa on suoraan x86-64:n assemblerilla, GNU-työkalujen ymmärtämällä syntaksilla toteutettu ”Hei maailma”, jonka avulla tartutaan kiinni käyttöjärjestelmän järjestelmäkutsurajapintaan (engl. system call interface). Se on käyttäjän oikeuksilla käynnistetyn prosessin ainoa tapa saada kutsuttua mitään laitteistoon liittyvää palvelua, joihin ”Hei maailmassa” kuuluu merkkien tulostaminen ja ohjelman oman elinkaaren lopettaminen hyvien tapojen mukaisesti:

Ensimmäinen rivi julkaisee ohjelmasta yhden nimen _start, jonka perusteella käännösvaiheen linkkeri osaa kirjata objektina syntyvään ELF-tiedostoon sen muistiosoitteen, josta ohjelmaa pitää alkaa suorittamaan. Koodissa tälle muistiosoitteelle on annettu tuo kyseinen nimi _start, ja tosiaan lopullinen muistiosoite riippuu myös siitä, mihin kohtaan muistia käännösvaiheen linkkeri haluaa ladatuttaa ohjelman koodin aina käynnistyksen yhteydessä. Muihin tarkoituksiin koodissa on pari muutakin symbolista osoitetta. Lopullisilla osoitteilla ei ole lähdekoodin kirjoittajalle väliä, koska työkalut hoitavat ne symbolisilla, selväkielisillä nimillä. Merkkijonon pituus voidaan tässä laskea kahden muistiosoitteen erotuksena, koska erotus ei riipu tavujen absoluuttisesta sijainnista, vaan siitä kuinka paljon kahden osoitteen välissä on tavuja. Lopulliset osoitteet ovat ylipäätään tiedossa vasta lataamisen ja käynnistyksen yhteydessä tapahtuvan linkittämisen jälkeen. Joissain kohdissa osoitteen tilalla voi olla ohjelmatiedostossa nollia, ja ELF-tiedostomuodon määräämässä paikassa on sitten tieto, mitkä nollat tulee latausvaiheessa täydentää milläkin lopullisella osoitteella. Tyypillistä on myös osoitteiden ilmoittaminen suhteessa ohjelmatiedoston tai sen osion alkuun. Tällöin lopullinen osoite on laskettavissa suhteellisen siirrosmäärän ja lopullisen alkuosoitteen summana.

Toinen rivi sanoo assembler-kääntäjälle, että sitä seuraavat tavut pitää sijoittaa ohjelman koodialueelle (nimeltään itseasiassa text). Sitten se tuuttaa sinne pötkön merkkejä ja konekielistä koodia, joka syntyy rivi riviltä minimaalisella, prosessoriarkkitehtuurin manuaalin mukaisella muunnoksella. Tässä ohjelmassa kaikki tavut, myös tulostettava merkkijono, ovat koodialueella, mikä on ihan OK. Ohjelman suoritus alkaa .string-määreellä lisätyn merkkijonon loppumista ilmaisevaa nollamerkkiä seuraavasta muistiosoitteesta, eivätkä merkkijonon merkit siis häiritse prosessorin toimintaa, vaikkei se niistä mitään ymmärtäisikään. Paha ohjelmointivirhe olisi hypätä suorittamaan tavujonoa Hello, hello, hello!\n\0 ikään kuin se olisi konekieltä. Onneksi kääntäjä ja linkkeri hoitavat ensimmäiseksi suoritettavaksi käskyosoitteeksi symbolin _start mukaisen paikan eikä varsinaista koodialueen alkua.

Näinhän siinä tosiaan käy, mikä voidaan verifioida debuggerin tulosteesta (tulostetta kaunisteltu ihan hieman):

Ohjelma on debuggerissa valmiiksi ladattuna, joten takaisinkäännös pystyy näyttämään ohjelman niissä peräkkäisissä muistiosoitteissa, joihin se on käytännössä ladattu tietokoneen muistiin. Takaisinkäännöksen kolmanteen käskyyn on viimeistään latausvaiheessa laskettu merkkijonon sijaintipaikka kokonaislukuna²⁹ . Toinen komento pyytää debuggeria tutkimaan (x, ’examine’) muistia kyseisestä muistipaikasta alkaen, tulkiten sisällön merkkijonona (s, ’string’). Kolmas komento pyytää debuggeria tutkimaan muistia 68 tavua eteenpäin samasta paikasta alkaen, tulkiten sitä vain peräkkäin sijaitsevina tavuina (x, ’hex format’; b, ’byte’). Tästä voidaan varsin konkreettisesti huomata, että assembler on tuutannut ulos merkkijonon, merkkijonon päättymistä tarkoittavan nollatavun, ja heti näiden perään suoritettavan koodin rivi kerrallaan käännettynä. ELF-objektiin se on kirjoittanut ylös, että suorituksen tulee alkaa muistiosoitteesta 0x4000ea.

Ensi töikseen tämä ohjelma pyytää käyttöjärjestelmää tulostamaan merkkijonon käyttäen Linuxin järjestelmäkutsua nimeltä write(). Mitään nimeähän tässä koodissa ei näy, vaan kutsulle sovittu järjestysnumero 1. Samalla kutsulla tulostettaisiin tiedostoihin ja muihin tietovirtoihin. Standardiulostulolle on sovittu järjestysnumero 1, ja se on sillä numerolla auki jo ohjelman käynnistymisvaiheessa. Siihen kirjoitetut tavut menevät pääteyhteydelle tai ne voi putkittaa toisen ohjelman syötteeksi tai ohjata tiedostoon esimerkiksi shellin kautta. Lisäksi write() tarvitsee tiedon kirjoitettavien tavujen sijainnista muistissa sekä lukumäärän tavuista, jotka sen on kirjoitettava. Lukumäärä tarvitaan, koska write() kirjoittaa vain tavujonoa, eikä ymmärrä mitään esimerkiksi rivinvaihdoista tai merkkijonon päättymisistä. Kutsu tarvitsee siis neljä parametria, joista yksi on itse kutsun identifioiva numero. Linuxin rajapinnassa on sovittu, että käyttöjärjestelmäkutsun parametrit toimitetaan käyttöjärjestelmän käyttöön laittamalla ne tiettyihin rekistereihin juuri ennen varsinaista kutsua (eli syscall -käskyn suoritusta). Järjestys, jossa rekisterit tässä täytetään on täysin ohjelman kirjoittajan päättämä; olennaista on, että siirtokäskyjen kohderekisterit ovat Linuxin rajapinnan mukaiset.

Varsinainen magiikka tapahtuu käskyn syscall kohdalla – tai ei siinä magiikkaa tapahdu, vaan tietyt tarkoin määritellyt toimenpiteet, joita AMD64-prosessorin manuaali kuvailee noin viiden sivun verran. Tässä kohtaa mm. käyttäjän prosessin suorittaminen keskeytyy ja prosessori hyppää suorittamaan käyttöjärjestelmän koodia. Toiveissa olisi, että osoitettu merkkijono ennemmin tai myöhemmin kopioituisi prosessin omasta muistista jonnekin kohteeseen, vaikkapa käyttäjän päätteelle ja että sen jälkeen Hei maailma -sovellus jatkuisi heti seuraavasta käskystä syscall’in jälkeen. Iso osa loppukurssista pyörii mm. sen parissa, mitä muita käyttöjärjestelmäkutsuja kuin write() tarvitaan, miten ne tekevät toimenpiteensä, missä vaiheessa keskeytynyt käyttäjän prosessi pääsee jatkumaan ja sen sellaista.

Tulostuksen jälkeen esimerkin ohjelma tekee vielä toisen käyttöjärjestelmäkutsun. Se on nimeltään exit() ja sen sovittu järjestysnumero on 60. Kutsun jälkeen Linux tulkitsee sovittuun rekisteriin laitetun lukuarvon olevan prosessin tiedottama virhekoodi ja tekee tarvittavat toimenpiteet prosessin sulkemiseksi ja sen varaamien resurssien vapauttamiseksi. Resurssien luonne ja niiden varaamiseen tarvittavat käyttöjärjestelmäkutsut ovat toinen iso teema loppukurssilla.

Huomautus: Kun alussa on näiden konkreettisten esimerkkien kautta ymmärretty prosessorin toiminta ja käyttäjän prosessin ja käyttöjärjestelmäkoodin yhteispeli, palataan järjestelmäkutsuissa POSIX-standardin mukaisiin C-kielen matalan tason kutsuihin. Osa niistä on toteutettu lähes sellaisenaan Linuxissa, mutta osa puolestaan tarvitsee väliin vielä yhteensopivuuskirjaston, joka muuntaa standardit palvelukutsut todellisiksi Linuxin käyttöjärjestelmäkutsuiksi ja saattaa tarvita jotakin ylimääräistä muunnostyötä ja kikkailua³⁰ . Tällainen yhteensopivuuskerros on jälleen yksi esimerkki kerrosmaisen rajapintoihin perustuvan suunnittelun hyödyistä. Haetaan tähän kohtaan ajatus siitä, että POSIXin määräämää C-kielistä käyttöjärjestelmärajapintaa käytetään kutsumalla oletettavasti C-kielellä toteutettua matalahkon tason kirjastoa, joka varsin oletettavasti kutsuu vielä käyttöjärjestelmätoteutuksen tarjoamaa vieläkin matalamman tason yhteensopivuuskirjastoa. Loppujen lopuksi kaikkein matalimman tason apukirjaston täytyy POSIXissa luvatun palvelun hoitamiseksi tehdä yksi tai useampia konkreettisia käyttöjärjestelmäkutsuja, esimerkiksi suorituttaa x86-64 -prosessorilla tämän ”Hei maailma” -esimerkin mukaisesti konekielikäsky syscall. Ilman käyttöjärjestelmäkutsun tapahtumista käyttäjän ohjelma ei kertakaikkiaan voi lukea eikä kirjoittaa mitään mistään/mihinkään oman rajatun pelikenttänsä ulkopuolella. Kerroksittaisen kirjaston olemassaolo ja käyttöjärjestelmäkutsun tekninen toteutus meidän tulee tuntea yleissivistyksen vuoksi, mutta korkeammalla abstraktiotasolla määritelty standardi rajapinta vapauttaa miettimästä näitä yksityiskohtia normaaleja sovelluksia kirjoitettaessa.

4.4 Esimerkkejä x86-64 -arkkitehtuurin käskykannasta

Edellä nähtiin esimerkki konekielikäskystä, movq %rsp,%rbp. Mitä muita käskyjä voi esimerkiksi olla? Otetaan muutama poiminta AMD64:n manuaalin [4] käskykantaosiosta, tiivistetään ja suomennetaan tähän. Todellisuus on rikkaampi. Tähän tiivistelmään voi palata demossa 5, jossa tutkitaan aliohjelmia sisältävän ohjelmakoodin toimintaa debuggerilla tuotetun lokitiedoston perusteella.

4.4.1 MOV-käskyt

Yksinkertainen bittien siirto paikasta toiseen tapahtuu käskyllä, jonka muistike (nimi, assembler-syntaksi) on useimmiten MOV. Ja GNU Assemblerissa tähän lisätään vielä bittien määrää ilmaiseva kirjain. Esimerkkejä erilaisista tavoista vaikuttaa käskyn lähteeseen ja kohteeseen:

Huomaa, että AMD64-prosessorissa MOV -käskyllä ei voi siirtää dataa suoraan muistipaikasta toiseen, vaan data pitää ensin tuoda rekisteriin, ja siitä sitten toiseen kohtaan muistia. Tässä on esimerkki 64 bitin kopioimisesta muistissa paikasta toiseen:

AMD64:n manuaalista löytyy datan siirtämiseen myös muita käskyjä kuin tämä esimerkiksi nostettu MOV. Manuaaleihin täytyy syventyä, mikäli konekieliohjelmointi alkaa kiinnostaa alkeita pidemmälle.

Esitellään tässä kohtaa vielä yksi hyvin tyypillinen käsky, LEA eli ”load effective address” eli ”lataa lopullinen osoite”:

Näin ollen käskypari lea 32(%rbp), %rdx ja sen perään movq (%rdx), %rax tekisi saman kuin movq 32(%rbp), %rax. Ja yksi käyttötarkoitus on siis esim. yhdistelmä:

4.4.2 Pinokäskyt

Tyypillinen lähde tai kohde siirtokäskyille on suorituspinon (engl. execution stack) huippu, jonka muistiosoite on rekisterissä RSP. Nimi tälle rekisterille voisi olla pinon huipun osoitin tai lyhyemmin pino-osoitin (engl. stack pointer, SP). Pinomaiseen käyttöön liittyy myös huipun siirtäminen ylös tai alaspäin samalla kun pinoon viedään tai sieltä tuodaan tietoa. Huipun käsittelylle ja tiedon siirrolle AMD64:ssä on erityiset käskyt push ja pop. Kun pinoon laitetaan jotakin tai sieltä otetaan jotakin pois näillä erityiskäskyillä, prosessori tekee automaattisesti siirron muistiin nimenomaan RSP:n osoittamaan kohtaan tai vastaavasti sieltä johonkin rekisteriin. Samalla se päivittää pinon huippua ylös tai alaspäin. (Huomaa, että koko ajan tarkoituksella ohitetaan välimuistiin liittyvät tekniset yksityiskohdat, koska sovellusohjelmoijan ei ole tarkoituskaan nähdä, miten muistijärjestelmä toimii konkreettisessa prosessorissa!). Pari esimerkkiä:

Kun pinoon laitetaan jotain, RSP tosiaan pienenee, koska pinon pohja on suurin pinolle tarkoitettu muistiosoite, ja pinon huippu kasvaa muistiosoitemielessä alaspäin. (Näin on siis useissa tyypillisissä prosessoreissa, mm. x86-64:ssä, oletettavasti joistakin historiallisista syistä; aivan kaikissa prosessoriarkkitehtuureissa suunta ei ole sama). Pinon päältä voi ottaa asioita vastaavasti:

Pinokäskyjen toimintaa havainnollistetaan kuvassa 12. Huomaa, että pino on käsitteellisesti samanlainen kuin normaali pinotyyppinen (eli viimeksi sisään – ekana ulos) tietorakenne, jota normaalisti käytetään kahdella operaatiolla eli ’painamalla’ (push) asioita edellisten päälle ja ’poksauttamalla’ (pop) päällimmäinen asia pois pinosta, mahdollisesti käyttöön jossakin muualla. Toisaalta pino on vain peräkkäisten muistiosoitteiden muodostama alue, ja sitä käytetään varsinaisen huipun lisäksi myös huipun lähistöltä (ns. aktivaatiotietueen/pinokehyksen sisältä, mikä selitetään myöhemmin). Kuvan esimerkissä on tyypillinen tapa esittää jokin alue muistiavaruudesta: muistiosoitteet kasvavat kuvan ylälaidasta alalaitaan päin. Näitä tulemme näkemään. Tässä kuvassa osoitteet ovat tavun kokoisten muistipaikkojen osoitteita, ja ne on ilmoitettu desimaalilukuina. Jatkossa siirrymme (tietokonemaailmassa) järkevämpään tapaan eli heksalukuihin, kuten nyt onkin jo tehty muistin sisällön osalta – tavu kun on näppärää esittää kahdella heksanumerolla.

Muistin sisältönä pinon huippuun saakka on jotakin, jolla yleensä on jokin merkitys. Kuvassa 12 tätä kuvaa satunnaisesti keksityt tavut. Muissakin osoitteissa on tietysti jotakin (aiemman historian mukaista) dataa, mutta niistä ei käytännössä välitetä, joten ne on kuvassa merkitty kysymysmerkeillä. Kuvan ensimmäinen tilanne vastaa tällaista alkutilannetta. Kuvan esimerkissä pinoon laitetaan push-käskyllä 16-bittinen luku. Kuten havaitaan, pino-osoitin SP on ensin saanut pienemmän arvon, jotta pinon huippu nousee, ja sitten huipulle on tallennettu luvun tavut. Keskimmäisessä vaiheessa siis pinoon on laitettu jotakin, sen huippu on noussut (joskin muistiosoitemielessä pienentynyt) ja se on valmiina vastaanottamaan taas jotakin uutta. Kolmannessa kuvassa puolestaan on esitetty pop-käskyn jälkeinen tilanne: 16-bittinen luku on kopioitu muistista jonnekin, oletettavasti johonkin rekisteriin, jotakin käyttötarkoitusta varten, ja pinon huippua on vastaavan verran laskettu (joskin muistiosoitemielessä kasvatettu). Tästä huomataan, kuinka pinon muistialueelle kyllä aina jää sinne laitettu data, mutta datan merkitys on hävinnyt, sillä heti seuraava push käyttäisi uudelleen samat muistipaikat. Tämä on olennaista ymmärtää, jotta myöhemmin on helpompi ymmärtää, miksi aliohjelman paikalliset muuttujat ovat ’unohtuneet’ aliohjelmasta palaamisen jälkeen.

4.4.3 Aritmetiikkaa

Edellä olevat siirto- ja pinokäskyt vain siirtävät bittejä paikasta toiseen. Ohjelmointi edellyttää usein bittien muokkaamista matkalla. Pari esimerkkiä: