Nicht angemeldet. · Kennwort vergessen · Registrieren

KlausFritz
Mitglied seit 02/2012
7 Beiträge
Betreff: SPiC Klausur August 2011 MultipleChoice
Hallo!

Bei den Fragen 1a & 1i der August Klausur 2011 auch nach Recherche im Skript nicht wirklich sicher was man da ankreuzen soll.

Zu Frage 1 i:
Welche Aussage über den Begriff MMU ist richtig?
   1. Die MMU rechnet Adressen des physikalischen Speichers in virtuelle Adressen um.
   2. Die MMU ist eine spezielle Einheit zur Verarbeitung von Mediendateien (Multi Media Unit), welche in den meisten Rechnern verbaut wird.
   3. Die MMU stellt sicher, dass Anwendungsprgoramme keinen Zugriff auf den Speicher des Betriebssystems haben.
   4. Die MMU ist eine Softwarekomponente...
Optionen 2 & 4 Fallen weg, denn  die MMU ( = "Memory Management Unit") ist durch Hardware realisiert.

Verbleiben noch 1 & 3, die meiner Meinung nach beide stimmen... aber es darf nur eine richtige Antwort geben.
"Jede durch einen Prozess angeforderte virtuelle Adresse wird zuerst durch die Memory Management Unit in eine physische Adresse umgerechnet [...]"
- aus Wikipedia: http://de.wikipedia.org/wiki/Memory_Management_Unit
Wenn virtuelle Adressen auf physikalischen Speicher umgerechnet werden, dann gilt das doch ebenso in andere Richtung!? -> 1. <=> wahr

Anderer seits:
"Virtueller Speicher wird durch das Betriebssystem auf physikalischen (Hintergrund-)Speicher abgebildet"
- Handout Kap 20, Folie 3 oder aus der .pdf: Folie 304
Da konkurrieren nun 2 unterschiedliche Aussagen. Naheliegend wäre aber das OS und MMU zusammenarbeiten, was aber noch nicht heißt, dass Option 1 falsch ist.

Und zu Option 3:
"MMU überprüft bei der Umrechnung, ob der Zugriff erlaubt ist"
- Handout Kap 20, Folie 5 oder aus der .pdf: Folie 306
Wenn die MMU generell Zugriffsrechte von Prozessen kontrolliert, dann tut sie das doch auch bei Speicherzugriffen auf OS-Speicherbereiche. -> 3. <=> wahr


Und noch eine Frage zur Frage 1a
Welche Aussage zur Speicherallokation ist richtig?
   1. Die dynamische Allokation von Speicher ist auf einem Mikrokontroller zu bevorzugen, da [...]
   2. Die Speicheradresse von statisch allokierten Variablen kann sich zur Laufzeit ändern
   3. automatic-Variablen werden im Heap allokiert
   4. Die Verwendung von statisch allokierten Variablen erlaubt den Speicherbedarf bereits nach dem Binden abzuschätzen.
Ich schwebe zwischen 3 & 4, mit Tendenz zu 3. Erläuterung:
1. Ist einfach falsch -> statische Allokation auf Mikrokontrollern FTW!
2. Die Variblen heißen wohl nicht um sonst statisch.
3. Laut Folie 303 der .pdf bzw Kapitel 20, Folie 2 stimmt das für lokale nicht-static (-> auto) Variablen. Ich bin mir allerdings nicht 100% sicher - Sind globale Variablen die nicht als static Deklariert werden auch automatisch auto Variablen oder gilt das nur für lokale nicht static Variablen? Weil dann wärs nämlich nicht richtig.
4. Stimmt vielleicht. Wobei ja nicht ausgeschlossen wird, dass es auch dynamisch allokierte Variablen gibt... was eine exakte Abschätzung ja wieder unmöglich macht.


Über hilfreiche Antworten wäre ich dankbar!

Liebe Grüße
Jakob
morty
SPiC-Meister
(Moderator)
Mitglied seit 05/2011
331 Beiträge
Zitat von KlausFritz:
Anderer seits:
"Virtueller Speicher wird durch das Betriebssystem auf physikalischen (Hintergrund-)Speicher abgebildet"
- Handout Kap 20, Folie 3 oder aus der .pdf: Folie 304
Da konkurrieren nun 2 unterschiedliche Aussagen. Naheliegend wäre aber das OS und MMU zusammenarbeiten, was aber noch nicht heißt, dass Option 1 falsch ist.
Naja, das OS konfiguriert die MMU.



Zitat von KlausFritz:
Und zu Option 3:
"MMU überprüft bei der Umrechnung, ob der Zugriff erlaubt ist"
- Handout Kap 20, Folie 5 oder aus der .pdf: Folie 306
Wenn die MMU generell Zugriffsrechte von Prozessen kontrolliert, dann tut sie das doch auch bei Speicherzugriffen auf OS-Speicherbereiche. -> 3. <=> wahr
Siehe oben. Etwas vereinfacht: Wenn ein Interrupt ausgelöst wird, wird die MMU ausgeschaltet. Um eine Funktion des OS aufzurufen wird durch das Programm ein Interrupt ausgelöst. Bevor das Programm fortgesetzt wird, wird die MMU wieder eingeschaltet und kann durch das Programm nicht mehr abgeschaltet werden.




Zitat von KlausFritz:
Und noch eine Frage zur Frage 1a
Welche Aussage zur Speicherallokation ist richtig?
   1. Die dynamische Allokation von Speicher ist auf einem Mikrokontroller zu bevorzugen, da [...]
   2. Die Speicheradresse von statisch allokierten Variablen kann sich zur Laufzeit ändern
   3. automatic-Variablen werden im Heap allokiert
   4. Die Verwendung von statisch allokierten Variablen erlaubt den Speicherbedarf bereits nach dem Binden abzuschätzen.
Ich schwebe zwischen 3 & 4, mit Tendenz zu 3. Erläuterung:
1. Ist einfach falsch -> statische Allokation auf Mikrokontrollern FTW!
2. Die Variblen heißen wohl nicht um sonst statisch.
3. Laut Folie 303 der .pdf bzw Kapitel 20, Folie 2 stimmt das für lokale nicht-static (-> auto) Variablen. Ich bin mir allerdings nicht 100% sicher - Sind globale Variablen die nicht als static Deklariert werden auch automatisch auto Variablen oder gilt das nur für lokale nicht static Variablen? Weil dann wärs nämlich nicht richtig.
4. Stimmt vielleicht. Wobei ja nicht ausgeschlossen wird, dass es auch dynamisch allokierte Variablen gibt... was eine exakte Abschätzung ja wieder unmöglich macht.

1) Dynamische Allokation ist durchaus üblich. Zum einen wird das im Timermodul der Libspicboard verwendet, zum anderen hat man häufig einfach nicht genug Speicher um alles statisch zu allokieren.
3) Schau dir Folie 20-1 nochmal genau an.
4) Steht da abschätzen oder bestimmen? ;)
KlausFritz
Mitglied seit 02/2012
7 Beiträge
Zitat von morty:
Naja, das OS konfiguriert die MMU.
[...]
Etwas vereinfacht: Wenn ein Interrupt ausgelöst wird, wird die MMU ausgeschaltet. Um eine Funktion des OS aufzurufen wird durch das Programm ein Interrupt ausgelöst. Bevor das Programm fortgesetzt wird, wird die MMU wieder eingeschaltet und kann durch das Programm nicht mehr abgeschaltet werden.
Also muss man diese Antwortmöglichkeiten wieder ganz penibel lesen. Mit "keinen Zugriff" ist gemeint, dass da gar nie in irgendeiner Art die Option vorhanden wäre, dass Anwendungen auf OS Dateien zugreifen können. Aber ja, das können Anwendungsprogramme über Signals dennoch, stimmt.
Wobei wenn dabei die MMU deaktiviert, dann ist das ja wie wenn auf die These "Eine Lampe verhindert, dass es im Zimmer dunkel ist."  antwortet: "Falsch! Wenn man die Lampe ausschaltet kann es bei Nacht dennoch dunkel im Zimmer sein." Naja, aber ok, dann wirds wohl Antwort 1 sein - da spricht ja nichts dagegen.

Wobei mich dass nun doch ein wenig genauer interessiert.
Die MMU wird im Betriebssystem wirklich ganz ausgeschaltet? Das verblüfft mich, weil irgendwie muss das OS ja auch auf virtuellen Speicher zugreifen können!? Das OS kann doch nicht nur allein auf physikalischen Speicher arbeiten irgendwie muss es, wenn es die Prozesse kontrolliert ja auch auf deren Adressraum zu greifen können. Oder bezieht sich das Ausschalten der MMU nur auf ISR bzw Signalhandler!?

zu 1a.)
Zitat von morty:
1) Dynamische Allokation ist durchaus üblich. Zum einen wird das im Timermodul der Libspicboard verwendet, zum anderen hat man häufig einfach nicht genug Speicher um alles statisch zu allokieren.
Gut zu wissen. Aber wenn im Skript explizit steht "Bei der μC-Entwicklung wird statische Allokation bevorzugt"... :)

Zitat von morty:
3) Schau dir Folie 20-1 nochmal genau an.
Ach nöööö! Stack und Heap verwechselt - warum müssen das auch so ähnliche Wörter sein, die haben beide ein 'a' und sind kurz und so!
Aber ok dann fällt Option 3 wohl ebenso raus.^^

Zitat von morty:
4) Steht da abschätzen oder bestimmen? ;)
K, also reicht wenn nach "abschätzen" gefragt ist auch ein "größer als".

Schonmal danke für die ausführliche Antwort! :)
sicherha
Informatik-Veteran
Mitglied seit 10/2010
53 Beiträge
Zitat von KlausFritz:
Wobei mich dass nun doch ein wenig genauer interessiert.
Die MMU wird im Betriebssystem wirklich ganz ausgeschaltet? Das verblüfft mich, weil irgendwie muss das OS ja auch auf virtuellen Speicher zugreifen können!? Das OS kann doch nicht nur allein auf physikalischen Speicher arbeiten irgendwie muss es, wenn es die Prozesse kontrolliert ja auch auf deren Adressraum zu greifen können. Oder bezieht sich das Ausschalten der MMU nur auf ISR bzw Signalhandler!?
Du hast Recht, das war sehr stark (zu stark) vereinfacht. Natürlich arbeitet auch das Betriebssystem intern mit virtuellen Speicheradressen. Um zu erklären, wie das funktioniert, muss ich einen kleinen Bogen machen.

Ein Anwendungsprozess darf nur auf Speicheradressen zugreifen, die sich innerhalb seines eigenen virtuellen Adressraums befinden. Eine Speicherseite befindet sich genau dann in einem virtuellen Adressraum, wenn sie in die zugehörige Seitentabelle eingetragen ist. Bei jedem Speicherzugriff schlägt die MMU in der Seitentabelle nach, überprüft die eingestellten Zugriffsrechte und spuckt im Erfolgsfall die zugehörige physikalische Adresse aus - im Fehlerfall löst sie einen Trap aus.

Nun wollen wir mit Hilfe der MMU verhindern, dass ein Anwendungsprozess auf Speicherbereiche zugreift, die dem Betriebssystem gehören. Die naheliegende Möglichkeit ist hier: Wir sorgen dafür, dass keine Seite des Betriebssystem-Speichers in einem Anwendungsprozess eingeblendet ist. Wenn das Betriebssystem "angesprungen" wird (entweder durch einen Interrupt von außen oder durch einen Trap im Anwendungsprogramm), müssen wir folglich die MMU so umkonfigurieren, dass sie eine andere Seitentabelle benutzt, in die der Betriebssystem-Speicher eingetragen ist. Und das ist richtig teuer: Das Umkonfigurieren an sich ist zwar eine sehr simple Operation, aber als Folge eines Seitentabellen-Wechsels sind alle möglichen Caches nicht mehr gültig und müssen invalidiert werden.

Folglich wird in der Praxis ein anderes Verfahren benutzt, das ein besonderes Feature der MMU ausnutzt: Man kann jeden Eintrag in der Seitentabelle mit einem speziellen Bit markieren, welches angibt, dass diese Seite nur zugreifbar sein soll, wenn der Prozessor im privilegierten Modus (sprich: im Betriebssystemmodus) läuft. Jetzt kann man für jeden Anwendungsprozess den Betriebssystem-Speicher in die Seitentabelle eintragen (und zwar überall an exakt der selben Stelle), aber man markiert alle diese Einträge mit dem genannten "Supervisor-Bit". Dann ist dieser Speicher zwar nominell die ganze Zeit eingeblendet, aber die Anwendung selber kann nicht drauf zugreifen. Nur wenn das Betriebssystem drankommt, wechselt der Prozessor in den privilegierten Modus, alle benötigten Seiten sind sofort da (juhu, kein teures Umkonfigurieren der MMU!) und das Betriebssystem kann auf seinen eigenen Speicher zugreifen, ohne dass die MMU ihm auf die Finger haut.

Nachtrag zur ursprünglichen Frage ganz oben:
Nein, eine "umgedrehte" Abbildung von physikalischen auf virtuelle Adressen ist nicht möglich - die Seitentabelle funktioniert nur in die eine Richtung! Die Abbildung muss auch gar nicht unbedingt bijektiv sein. Theoretisch wäre es möglich, dass zwei unterschiedliche virtuelle Adressen auf ein und dasselbe physikalische Stück Speicher verweisen (Preisfrage: wie? ;-)).

Nachtrag 2:
Vorsicht, Signalbehandlung ist eine Sache, die rein innerhalb der Anwendung abläuft! Das Betriebssystem kümmert sich ums Zustellen, Blockieren usw., aber das Abarbeiten der Signalbehandlungsfunktion selber läuft immer im Anwendungskontext ab.
Dieser Beitrag wurde am 18.07.2012, 01:54 von sicherha verändert.
morty
SPiC-Meister
(Moderator)
Mitglied seit 05/2011
331 Beiträge
Antwort auf Beitrag #3
Auch wenn der sicherha das schon recht ausführlich erklärt hat gehe ich nochmal auf ein paar Kleinigkeiten ein. Hab die Reihenfolge mal ein wenig umgedreht.

Zitat von KlausFritz:
Die MMU wird im Betriebssystem wirklich ganz ausgeschaltet? Das verblüfft mich, weil irgendwie muss das OS ja auch auf virtuellen Speicher zugreifen können!? Das OS kann doch nicht nur allein auf physikalischen Speicher arbeiten irgendwie muss es, wenn es die Prozesse kontrolliert ja auch auf deren Adressraum zu greifen können.
Um auf den virtuellen Adressraum des Programms zuzugreifen braucht das OS die MMU nicht, da es ja die Konfiguration der MMU kennt. Es kann also selbst die virtuelle Adresse des Programms in die physikalische Adresse umrechnen und dann dort hin zugreifen. Ist je nach System nicht besonders effizient, funktioniert aber genauso.
Wenn die Speicherseite auf der Festplatte ausgelagert ist, muss die eh ersteinmal geladen werden, aber ab dann funktioniert es genauso.
Das es natürlich auf modernen Systemen reichlich bescheuert wäre, wenn das OS die MMU nicht verwenden würde, ist eine andere Sache, zumal bei sehr wenig Speicher sogar teile das Betriebssystems ausgelagert werden und das wäre ohne MMU nicht (bzw sehr schwer) möglich.



Zitat von KlausFritz:
Zitat von morty:
Naja, das OS konfiguriert die MMU.
[...]
Etwas vereinfacht: Wenn ein Interrupt ausgelöst wird, wird die MMU ausgeschaltet. Um eine Funktion des OS aufzurufen wird durch das Programm ein Interrupt ausgelöst. Bevor das Programm fortgesetzt wird, wird die MMU wieder eingeschaltet und kann durch das Programm nicht mehr abgeschaltet werden.
Also muss man diese Antwortmöglichkeiten wieder ganz penibel lesen. Mit "keinen Zugriff" ist gemeint, dass da gar nie in irgendeiner Art die Option vorhanden wäre, dass Anwendungen auf OS Dateien zugreifen können.
Nein, das Programm kann nie und auf keine Weise auf den Speicher des OS zugreifen. Wobei Speicherbereich evtl. das bessere Wort wäre.

Um Daten vom OS zu bekommen funktioniert das etwas anders. Ich hab es jetzt auch mal wieder etwas vereinfacht um nicht zu sehr in Detail zu gehen. Das Programm legt die ID der Betriebssystemfunktion - die Speicheradresse kennt es ja nicht - und einen Zeiger auf eine (virtuelle) Speicheradresse im eigenen Speicherbereich, an die das OS die Daten hinschreiben soll auf den Stack (sowie weitere Parameter). Dann löst es einen Interrupt (aus Sicht des Programms(!) ist es ein Trap(!), weil das ja Synchron ist) aus und springt ins Betriebssystem. Das Betriebssystem kann jetzt (mit oder ohne Hilfe der MMU) die Parameter vom Stack des Programms auswerten und schreibt die Antwort in den Speicherbereich des Programms.
Wenn du die Manpages anschaust, wirst du feststellen dass kein Eintrag aus der Gruppe 2 (Systemfunktionen) (z.B. stat) dir einen Pointer auf Speicher zurück gibt den du nicht selber reserviert hast. Bei der Gruppe 3 (Bibliotheksfunktionen) (z.B. readdir) ist das andres, da diese nicht direkt ins Betriebssystem springen können sie Speicher reservieren.

Zitat von KlausFritz:
Wobei wenn dabei die MMU deaktiviert, dann ist das ja wie wenn auf die These "Eine Lampe verhindert, dass es im Zimmer dunkel ist."  antwortet: "Falsch! Wenn man die Lampe ausschaltet kann es bei Nacht dennoch dunkel im Zimmer sein." Naja, aber ok, dann wirds wohl Antwort 1 sein - da spricht ja nichts dagegen.
Die Schlussfolgerung kann ich jetzt nicht nachvollziehen. Aber evtl hilft ja meine längliche Erklärung.
KlausFritz
Mitglied seit 02/2012
7 Beiträge
Oha, ganz ehrlich vielen, vielen Dank an euch beide morty & sicherha für die detailierte Erklärungen! Ich bilde mir ein Alles soweit verstanden zu haben, zumindest sind alle Fragen & Unklarheiten geklärt. Und die Hintergrunddetails finde ich auch interessant & aufschlussreich. :)

Zitat von sicherha:
Nachtrag zur ursprünglichen Frage ganz oben:
Nein, eine "umgedrehte" Abbildung von physikalischen auf virtuelle Adressen ist nicht möglich - die Seitentabelle funktioniert nur in die eine Richtung! [...]
Naja, in der Frage stand ja "umrechnen" und nicht "abbilden", rechnen hab ich dann auch anders interpretiert - mit so sprachlichen Feinheiten hab ich echt die meisten Probleme bei diesem Multiple Choice. Aber offensichtlich gelingt es dadurch ganz gut das Beantworten der Fragen durch Halbwissen und Ausschlussprinzip zu verhindern^^

Zitat von sicherha:
[...] Theoretisch wäre es möglich, dass zwei unterschiedliche virtuelle Adressen auf ein und dasselbe physikalische Stück Speicher verweisen (Preisfrage: wie? ;-)).
Auch auf die Gefahr hin, dass die Frage eher rethorisch Natur ist (in Hoffnung auf einen großen, tollen, goldenen Preis :D) :
Diese Funktionalität stellt ich mir analog zu Zeigern vor: Mehrere virtuelle Memory Pages zeigen auf einen physikalischen Page Frame.

Zitat von morty:
Zitat von KlausFritz:
[...] Also muss man diese Antwortmöglichkeiten wieder ganz penibel lesen. Mit "keinen Zugriff" ist gemeint, dass da gar nie in irgendeiner Art die Option vorhanden wäre, dass Anwendungen auf OS Dateien zugreifen können.
Nein, das Programm kann nie und auf keine Weise auf den Speicher des OS zugreifen. Wobei Speicherbereich evtl. das bessere Wort wäre.
Ja gut, mein Fehler. Du hast (natürlich) recht, ich hatte an Stelle von "zugreifen" eher "abfragen" interpretiert. Den Speicher Inhalt abfragen ist ja möglich wie du auch im Folgenden noch erklärt hast - aber das war ja nicht Gegenstand der Frage...

Zitat von morty:
Zitat von KlausFritz:
<Lampen Vergleich>
Die Schlussfolgerung kann ich jetzt nicht nachvollziehen. Aber evtl hilft ja meine längliche Erklärung.
Jap, hat sich geklärt.

Es war übrigens auch aufschlussreich, dass du nochmal so explizit Interrupts & Traps unterschieden hast. Bisher hatte ich gedacht, dass der wesentliche Unterschied zwischen Interrupts und Traps darin liegt, dass erstere generell von der Hardware ausgelöst werden, letztere nur Software-Signale sind. Aber die Auffassung hab ich jetzt auch lieber verworfen und nochmal die Folien genauer studiert :)
sicherha
Informatik-Veteran
Mitglied seit 10/2010
53 Beiträge
Zitat von KlausFritz:
Zitat von sicherha:
[...] Theoretisch wäre es möglich, dass zwei unterschiedliche virtuelle Adressen auf ein und dasselbe physikalische Stück Speicher verweisen (Preisfrage: wie? ;-)).
Auch auf die Gefahr hin, dass die Frage eher rethorisch Natur ist (in Hoffnung auf einen großen, tollen, goldenen Preis :D) :
Diese Funktionalität stellt ich mir analog zu Zeigern vor: Mehrere virtuelle Memory Pages zeigen auf einen physikalischen Page Frame.
Genau, man lässt in der Seitentabelle zwei unterschiedliche Einträge auf dieselbe physikalische Adresse verweisen. :-)
morty
SPiC-Meister
(Moderator)
Mitglied seit 05/2011
331 Beiträge
Antwort auf Beitrag #6
Zitat von KlausFritz:
Es war übrigens auch aufschlussreich, dass du nochmal so explizit Interrupts & Traps unterschieden hast. Bisher hatte ich gedacht, dass der wesentliche Unterschied zwischen Interrupts und Traps darin liegt, dass erstere generell von der Hardware ausgelöst werden, letztere nur Software-Signale sind. Aber die Auffassung hab ich jetzt auch lieber verworfen und nochmal die Folien genauer studiert :)

Ja, da bin ich mit der didaktischen Aufbereitung auch nicht so ganz glücklich, weil eigentlich alle Traps aus Sicht der CPU Interrupts sind; wenn man es aber auf Softwareebene betrachtet, muss man da unterschieden.
Dieser Beitrag wurde am 19.07.2012, 10:19 von morty verändert.
Begründung: Satzzeichen
Schließen Kleiner – Größer + Auf diesen Beitrag antworten:
Prüfcode: VeriCode Gib bitte das Wort aus dem Bild ins folgende Textfeld ein. (Nur die Buchstaben eingeben, Kleinschreibung ist in Ordnung.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O :troll:
Weitere Zeichen:
Gehe zu Forum
Powered by the Unclassified NewsBoard software, 20110527-dev, © 2003-8 by Yves Goergen