Not logged in. · Lost password · Register

All posts by KlausFritz (7)

topic: Live von der Klausurkorrektur  in the forum: 2. Semester Grundlagen der systemnahen Programmierung in C
KlausFritz
Member since Feb 2012
7 posts
Die Bonuspunkte zu streichen wäre schon sehr schade, die motivieren wirklich sehr. Ich bezweifle, dass ich ohne sie ähnlich verbissen an den Hausaufgaben gearbeitet hätte, was sich dann sicherlich auch negativ auf meine Klausurleistung ausgewirkt hätte. Echt schade, dass ihr das bewehrte Korrekturverfahren nicht mehr anwenden dürft!
Die Bonuspunkte wirken sich vielleicht schon deswegen mehr aus, da es nun nicht mehr nur x,0 x,3 und x,7 noten gibt sondern das ganze nun feiner aufgelöst ist. Früher war es wohl in vielen Fällen praktisch egal ob man 7 oder 9 Bonuspunkte kriegt, denn man bleibt vielleicht sowieso unter der Notengrenze. Heut kriegt man eben keine 7 BP aber ist eben um 0,53 besser, mit voller Übungspunktzahl um 0,72. Diese Differenz von 0,2 wirkt sich nun immer aus, wohin gegen sie früher in einigen Fällen gar nicht beachtet wurde... Im Grunde ist das heutige aber System fairer.
Dass von Bonuspunkten außerdem in erster Linie Studenten provitieren die die Hausaufgaben gut hingekriegt haben und somit allein durch diese Praxiserfahrungen in der Klausur besser abschneiden liegt auch nahe. Das leistet bestimmt auch einen guten Beitrag, dass das gute Mittelfeld ausdünnt und der einser Bereich wächst.

Die Klausur war aus meiner Sicht übrigens an sich Inhaltlich sehr gut machbar. Es gab keine besonders fiesen Fragen im MC Teil bei denen mir irgendwie alle Optionen plausibel schienen. Die Programmieraufgaben waren von der Aufgabenstellung auch gut erläutert, ich wusste direkt was zu tun war. So verkette Listen, Bäume und Sortieralgorithmen haben wir in GDI schon intensiv in Java programmiert, dem entsprechend war die Linux Aufgabe auch nichts groß Neues. Zu Gute kam uns auch, dass man kaum Bibliotheksfunktionen gebraucht hat (stat(), opendir() etc...). Und den Frageteil zu Schluss kann man sowieso sehr gut aus Altklausuren lernen, da kann man schon gut abschätzen was und vorallem wie ihr denn gerne fragt.

@ Germar: Les dir den Thread hier mal ganz durch und auch die Homepage, da haben Morty bzw. der Lehrstuhl schon ausführlich erklärt wie die Noten zustande kommen.
http://www4.cs.fau.de/Lehre/SS12/V_SPIC/Pruefung/
Vom Einsichttermin habe ich jedoch auch noch nichts mitbekommen.
topic: Live von der Klausurkorrektur  in the forum: 2. Semester Grundlagen der systemnahen Programmierung in C
KlausFritz
Member since Feb 2012
7 posts
In reply to post ID 4802
Quote by morty:
Klausuren sind korrigiert. Ergebnisse gibt es evtl heute aber spätestens morgen im Waffel.

Schön, dass die Korrektur so flott hingekriegt habt, da ist man ja von den meisten Lehrstühlen anderes gewöhnt :D
Und im übrigen bitte ich vielmals um Entschuldigung für meine grauenhafte Schrift. Ich hoffe ihr seid das schon gewöhnt und hattet nicht all zu große Probleme es zu entziffern^^
topic: Prozesszustandsdiagramm nach Silberschatz  in the forum: 2. Semester Grundlagen der systemnahen Programmierung in C
KlausFritz
Member since Feb 2012
7 posts
Subject: Prozesszustandsdiagramm nach Silberschatz
Hallo!

Ich bin spät dran, ich weiß - aber vielleicht ist ja dennoch noch jemand anwesend.

Beim Prozesszustandsdiagramm ist mir der Übergang von laufend zu wartend unklar.
Da steht ja neben dem Pfeil: impliziter oder expliziter Warteaufruf. (Folie SPiC 19-10)

Explizit ist klar - der Thread führt irgendeine "wait()" Funktion aus.

Zum impliziten Zustandswechsel fällt mir jedoch kein Beispiel ein.
Zum Warten muss es doch stets einen Grund geben. Es kann doch höchstens passieren, dass der Prozess warten muss, dies aber nicht möchte. Dann ist der Prozess selber doch dennoch bestrebt direkt weiter zu laufen und somit eigentlich im Zustand bereit. Und solange er nicht kommuniziert (-> explizit) dass ihm etwas fehlt, kann ihn doch niemand urteilen ob der Prozess wartet oder bereit ist.

Ich hoffe man versteht mein Problem!?

EDIT: hat sich geklärt.
Der Zustand heißt nicht "wartend" sondern "blockiert", da hab ich mich vertan. Und blockiert kann ein Prozess ja auch von außen werden.
This post was edited on 2012-07-26, 22:54 by KlausFritz.
topic: MC Fragen  in the forum: 2. Semester Grundlagen der systemnahen Programmierung in C
KlausFritz
Member since Feb 2012
7 posts
In reply to post ID 4778
Quote by H³lm:
Quote by Femto on 2012-07-23, 18:25:
c) Was ist ein Stack-Frame?
❏ Der Speicherbereich, in dem der Programmcode einer Funktion
abgelegt ist.
❏ Ein spezieller Registersatz des Prozessors zur Bearbeitung von Funktionen.
❏ Ein Fehler, der bei unberechtigten Zugriffen auf den Stack-Speicher entsteht.
❏ Ein Bereich des Speichers, in dem u.a. lokale automatic-Variablen
einer Funktion abgelegt sind.

Hier tippe ich auf das vierte, da ja laut Skript lokale Variablen dort abgelegt werden, oder hab ich das falsch verstanden?


müsste das nicht Antwort 2 sein ?? im Stack-Frame befinden sich ja z.B. auch Framepointer. Somit ist ein Datenregister (Antwort 4) nur ein Teil davon.


Nach Christians Erklärung noch den finishing-move: Die Musterlösung zur Klausur aus dem Jahr 2007 sagt Option 3!
http://www4.cs.fau.de/Lehre/SS12/V_SPIC/Pruefung/Klausuren…
topic: SPiC Klausur August 2011 MultipleChoice  in the forum: 2. Semester Grundlagen der systemnahen Programmierung in C
KlausFritz
Member since Feb 2012
7 posts
In reply to post ID 4656
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. :)

Quote by 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^^

Quote by 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.

Quote by morty:
Quote by 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...

Quote by morty:
Quote by 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 :)
topic: SPiC Klausur August 2011 MultipleChoice  in the forum: 2. Semester Grundlagen der systemnahen Programmierung in C
KlausFritz
Member since Feb 2012
7 posts
In reply to post ID 4645
Quote by 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.)
Quote by 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"... :)

Quote by 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.^^

Quote by 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! :)
topic: SPiC Klausur August 2011 MultipleChoice  in the forum: 2. Semester Grundlagen der systemnahen Programmierung in C
KlausFritz
Member since Feb 2012
7 posts
Subject: 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
Close Smaller – Larger + Reply to this post:
Special characters:
Go to forum
Powered by the Unclassified NewsBoard software, 20110527-dev, © 2003-8 by Yves Goergen