3. Muistinhallintaa (12 pistettä) Selitä muistinhallintayksikön (MMU) rakenne. Kuvaa kaikki sen rakenneosat sekä kuinka se tekee osoitemuunnoksen, kun a) ei käytetä virtuaalimuistia ja prosessille on varattu yksi yhtenäinen muistialue b) muistinhallinta perustuu sivuttavaan virtuaalimuistiin. Pistejaottelu: a ja b tasavertaiset. a) Vaikka käytössä ei ole virtuaalimuistia, voivat ohjelmat päätyä eri paikkoihin muistia eri suorituskerroilla, joten osoitteenmuunnosta joudutaan tekemään lennossa. Looginen osoite on siirtymä ohjelman muistialueen sisällä (ns. suhteellinen osoite), fyysinen osoite taas muistipaikan varsinainen sijainti muistissa (ns. absoluuttinen osoite). MMU:n rakenne (3p): - BASE-rekisteri, joka sisältää nykyprosessin muistialueen alkuosoitteen +1,5p - LIMIT-rekisteri (kirjassa Bounds), joka sisältää nykyprosessin muistialueen loppuosoitteen (myös alueen pituus hyväksytty, kunhan arvoa käytetty konsistentisti) +1,5p - MAR/MBR: TiTo-asiaa joten niillä ei ole ollut vaikutusta vastauksen pisteytykseen. Rekisterien tarkkaa käyttöä ei ole määritelty, mutta TTK-91, joka ei tee minkäänlaista osoitteenmuunnosta, käyttää niitä suoraan viestintään fyysisen muistin kanssa. - Muita osia: yhteenlaskuri, vertailu - ei vaikutusta pisteytykseen, tarkkaan sijaintiin ei liene otettu kurssilla kantaa. - Asiaankuulumattomien rekisterien (PC, IR, jne) sekoittamisesta MMU:hun on rokotettu varsin kevyesti, -0,5p Osoitteenmuunnos (3p): - looginen osoite lisätään BASE-rekisterin arvoon (yhteenlasku) +1,5p - tulosta verrataan LIMIT-rekisterin arvoon: jos suurempi, aiheutetaan poikkeus (viittaus muistialueen ulkopuolelle), jos pienempi, osoite ok. +1,5p, jos myös vertailun *merkitys* selostettu ("tällöin viittaus muistialueen ulkopuolelle" ja/tai "aiheutetaan poikkeus/virhetilanne") Kuva 7.8 kirvoitti muutamia kommentteja (käyttäjä)pinon jäämisestä prosessin muistialueen ulkopuolelle. Tämä kuvan yksityiskohta jää hieman epäselväksi; jos käyttäjäpinoon osoitettaisiin tosiaan fyysisillä osoitteilla, pino-osoittimen SP käyttö tarvitsee aivan oman suojausjärjestelmän (esim. TTK-91-osoitus @50(SP) tulisi estää; SP:tä käytetään TiTossa mm. aliohjelmakutsujen yhteydessä yhteen- ja vähennyslaskua käyttävissä osoituksissa). Jos taas käyttäjäpinoon osoitetaan loogisilla osoitteilla, sen tulee olla prosessin muistialueella. Kaksi tulkintaa järkeistää kuvan ilman fyysisen pino-osoituksen tarvetta: a) pino kasvaa alaspäin, ja Bounds-rekisteriä päivitetään yhdessä SP:n kanssa, tai b) kyseinen pino on käyttöjärjestelmäpino, jonne käyttäjäprosesseilla ei olekaan asiaa. b) B-kohta on näistä kahdesta "erittelevämpi", eli sen pisteytys on a-kohtaa tiukempi. Oletetaan yksitasoinen sivutaulu. MMU:n rakenne (2p): - PTR - Page Table Register, sisältää sivutaulun alkuosoitteen. (Ei itse sivutaulua, joka voi olla muutaman megatavun kokoinen!) +1p - TLB - Translation Lookaside Buffer, sisältää viimeksi tarvittuja sivutaulualkioita. Lisäksi mukana kunkin (looginen) sivunumero ja datan validiusbitti. +1p Kaikissa virtuaalimuistijärjestelmissä ei TLB:tä ole, mutta koska sivutaulun käyttö lähes kaksinkertaistaa (tai n+1-kertaistaa n-tasoisella sivutaululla) muistiviittauksen keston, TLB puolustaa paikkaansa tunnetuksi osoitettavana mekanismina sekä yleisyytensä ("most virtual memory schemes make use of...") että hyödyllisyytensä vuoksi. Sen käsittelystä on ollut jaossa hieman alle 2 kohdan 6:sta pisteestä. Osoitteenmuunnos (4p): Osoitteenmuunnoksessa on niin monta jos-jos-ei -kohtaa, että suositamme suoraan algoritmista lähestymistapaa. Eksakti kielenkäyttö on tarpeen näin raudan pinnassa: "etsiminen" ei voikaan tapahtua ihan miten vain, ja tiedon lähteiden tulisi käydä ilmi. Pelkkä kuva ilman tarvittavia selityksiä on liian korkeatasoinen selvittämään, mitä aiheesta on todella opittu. Ylenmääräisen kevyestä "katsotaan TLB:stä, jos ei ole siellä niin katsotaan sivutaulusta, jos ei ole siellä niin katsotaan levyltä" on saanut 0,5-1 pistettä yksityiskohtien määrästä riippuen. Jos kuvauksesta kävi ilmi myös MMU:n rakenne, pisteitä on tullut 2,5-3. Tästä ylöspäin on käytetty ikävämpää "mistä rokotetaan" -laskutapaa. Kohtien perässä ovat yleisimmät virheet ja niistä viedyt pisteet. - Jaetaan looginen osoite kahtia. Sivukoolla 2^n (sivukoon tietolähde ei käynyt kurssilla ilmi, joten sitä ei tarvittu) ovat n osoitteen vähiten merkitsevää ("viimeistä", "oikeanpuoleista") bittiä siirtymää sivun sisällä ja loput ("ensimmäiset", "vasemmanpuoleiset") sivunumeroa. Huomaa, että koska siirtymän merkintään käytetään nämä n bittiä, minkään LIMIT-tarkistuksen kaltaiseen ei ole tarvetta - yliosoitus on fyysisesti mahdotonta. Sama sivunumerolle, sillä jokaiselle mahdolliselle sivulle on myös rivi sivutaulussa. * Jakoperuste unohtunut -1p - Katsotaan sivunumeron avulla, löytyykö TLB:stä sivunumeroa vastaavaa riviä (rivimuoto: sivunumero-validibitti-sivutaulun rivi jossain järjestyksessä). Jos ei löydy, siirrytään seuraavaan kohtaan. Jos löytyy, tarkastellaan validibittiä. Jos se ei ole asetettu, kyseessä on esim. viime prosessin vastaavan (loogisen) sivun tieto, eikä se kiinnosta meitä, joten siirrytään seuraavaan kohtaan. Jos validibitti on asetettu, kyseessä on ns. "TLB hit", sivutilan numero löytyi TLB:stä ja se katenoidaan fyysisen osoitteen aluksi (tästä operaatiosta lisää myöhemmin). * TLB:n käyttö tavalla tai toisella sekaisin -0,5p tai -1p vakavuudesta riippuen (perusideasta sai pisteen jo MMU:n rakenne -kohdassa). - Koska sivua ei löytynyt TLB:stä, joudumme tekemään muistihaun (tosin sivutaulun sisältävä sivu voi olla välimuistissakin) ja tarkastelemaan sivutaulua. Sivutaulun fyysinen osoite on PTR:ssä, ja lisäämällä siihen sopivasti kerrottuna (lähinnä 2:n potenssilla kertominen, eli right-shift, nopea operaatio) sivunumero saadaan sivutaulun oikean rivin osoite. Rivi on muotoa present-modified-muut kontrollibitit-sivutilan numero. Sivutilan numero on sivutilan alkuosoitetta hyödyllisempi, sillä sivutilan ollessa sivun kokoinen em. siirtymä sivun sisällä voidaan vain katenoida eli liittää sivutilan numeron perään (nopea operaatio), kun taas osoitteen kanssa jouduttaisiin tekemään yhteenlaskua (suhteessa hitaampaa). Huomaa, että jos fyysisen osoitteen perään katenoidaan vielä siirtymä, 32-bittisestä fyysisestä osoitteesta tulee 32+n-bittinen osoite, mikä ei enää edes mahdu osoiteväylälle! * Sivutaulusta saa alkuosoitteita -1p - Tarkastetaan kyseisen rivin läsnäolo- eli present- eli P-bitti: jos se on asetettu, rivi kelpaa (sivu on muistissa) ja siitä saatu sivutilan numero voidaan katenoida loogisesta osoitteesta erotetun siirtymän kanssa. Jos P-bittiä ei ole asetettu, aiheutetaan sivunpuutoskeskeytys. * Present-bitti tarkastamatta n. -1p (yleinen tarkastusten - muista TLB:n validibitti - unohtaminen on ollut 1 pisteen virhe) - P-bitin 0-arvo ei tarkoita sellaisenaan, että sivu on levyllä. Levy on kuitenkin selvästi yleisimpiä apumuisteja, ja suurin osa sivunpuutoksista päättyy onnellisesti siihen, että sivu haetaan levyltä muistiin. Keskeytyskäsittelyn aikana voidaan kuitenkin myös todeta, että prosessi on viitannut ihan minne sattuu, jolloin se tapetaan koruttomasti. Tämä aihe on kuitenkin käsitelty pisteytykseen vaikuttamattomissa marginaaliterveisissä, ellei asiaan ole liittynyt jotain tehtävän kannalta oleellisempaa epäselvyyttä. Harmillisen paljon pisteytyksessä jää kiinni siitä, onko kirjoittaja huomannut käyttää oikeaa yksityiskohtatasoa vastauksessaan. Koska KJ I on varsin tekninen kurssi, etenkin tällaiset osajärjestelmän toimintaa tenttaavat kysymykset painottavat tarkkuutta. Kuitenkin jo yleisperiaatteiden tuntemuksesta on saanut päälle puolet koko tehtävän pisteistä. Kenties jatkossa kokeen evästystä yritetään vieläkin selkeyttää lisäämällä muistutus tarkkuudesta => tärkeämpien "nippelitietojen" esiinkaivamisesta aina kun vastaaja huomaa käyttävänsä sanoja kuten * "etsiä", "hakea" - miten? mistä? mitä käyttäen? * "katsoa" (esim. katsotaan onko levyllä) - mistä? miten? ja joskus jopa * "lisätään" - yhteenlasketaanko vai liitetäänkö? miksi? (millainen tulos on?) Käyttöjärjestelmäkurssin yleisempi turmio, passiivitauti (niin, *kuka* tekee?), vaikutti tähän tehtävään varsin vähän, koska kaiken tekijänä on oletettavasti MMU eikä sen tarkemmasta tietoa juuri näissä puitteissa ole.