Seite 1 von 1

dw-Direktive: Adressen versus Zahlen / Stackoperationen

Verfasst: 27. Nov 2007 23:39
von Red*Star
Erste Frage:

Was soll eigentlich dieses seltsame (und vor allem in der Praktikumsaufgabe völlig undokumentierte :evil:) Verhalten, dass der auf der HP zur Verfügung gestellte Assembler mir, wenn ich eine normale Zahl notiere

.data
dw 65535

diese im Datensegment in 0x0F0F0F0F übersetzt, anstatt, wie es "logisch" wäre, in 0xFFFF? (Logisch zumindest für mich. Vielleicht gibt es ja tatsächlich eine Situation, in der das Auseinanderziehen auf 4 Byte Sinn macht, in dem Fall fällt sie zumindest mir nicht ein.)

Obendrein behandelt er noch dazu Zahlen und Adressen unterschiedlich: Adressen wie

.data
dw buffer;
buffer: dw x

werden (so wie es für mich jetzt logisch erschiene) in einen 2 Byte langen Bitstring umgesetzt (in dem Beispiel oben müsste glaub ich 0x0002 rauskommen, aber das sei jetzt egal).

Bin ich froh, dass ich das durch Zufall rausgefunden habe, bevor ich irgendwann evtl. wirklich auf ein Problem gestoßen wäre, das auf diese Inkonsistenz zurückzuführen gewesen wäre (und bei dem ich garantiert ewig nach dem Fehler in meinem eigenen Code gesucht hätte, anstatt mit einem Blick ins svm file festzustellen, dass ich gar nicht Schuld bin).



Zweite Frage:

Aus der Aufgabenstellung geht auch nicht eindeutig hervor, welche Befehle den Stack nur peek()en und welche einen pop() durchführen. Ich habe es mir so gut es ging aus den Beispiel-Assembler-Dateien zusammengereimt und fasse es hier mal zusammen:

Vom Stack entfernt wird (das initiale) s0 bei:

JMP
JZ
POP

Zusätzlich wird s1 entfernt bei:

ADD
BSB
DIV
NOR

s0 bleibt bei (was nicht heißen muss, dass es danach noch oben liegt):

SYSCALL
LI
LB
LW
SB
SW
DUP
ROT
ROT3

Ich bitte mal jemanden "Offizielles", das zu bestätigen. Ansonsten kann ich beim Testat für nichts garantieren, denn der Herr Walther hat uns ja heute in FGdI schön erklärt, dass das Programmiererteam bei inkorrekter oder unvollständiger Spezifikation vom Kunden rechtlich nicht belangt werden kann ;). [Oder so ähnlich.]

Verfasst: 28. Nov 2007 00:05
von MisterD123
das mit dem s0 und s1 entfernen oder nicht kann ich soweit bestätigen, damit funktionieren die programme bei mir. (abgesehen davon, dass mir bei lw und sw noch die endian-kodierung fehlt)

Re: dw-Direktive: Adressen versus Zahlen / Stackoperationen

Verfasst: 28. Nov 2007 14:12
von chrschn
Red*Star hat geschrieben:Was soll eigentlich dieses seltsame (und vor allem in der Praktikumsaufgabe völlig undokumentierte :evil:) Verhalten, dass der auf der HP zur Verfügung gestellte Assembler mir, wenn ich eine normale Zahl notiere

.data
dw 65536

diese im Datensegment in 0x0F0F0F0F übersetzt, anstatt, wie es "logisch" wäre, in 0xFFFF?
Dieses Verhalten ist ein Bug im Compiler, natürlich wäre die korrekte Kodierung 0xFFFF. Sorry dafür, sowas kommt leider vor. Wir werden heute noch eine bereinigte Version des Compilers zur Verfügung stellen.

Wer nun schon ein fertiges Programm hat, das diesen Bug "umschifft", dem wird das natürlich nicht zum Nachteil gereicht.
Red*Star hat geschrieben:Aus der Aufgabenstellung geht auch nicht eindeutig hervor, welche Befehle den Stack nur peek()en und welche einen pop() durchführen. Ich habe es mir so gut es ging aus den Beispiel-Assembler-Dateien zusammengereimt und fasse es hier mal zusammen:
Soweit ich das hier aus dem Lösungsvorschlag entnehmen kann, ist es genau so, wie von Red*Star beschrieben.

Gruß,
Christian Schneider

Re: dw-Direktive: Adressen versus Zahlen / Stackoperationen

Verfasst: 28. Nov 2007 16:35
von hcdenton
chrschn hat geschrieben:Wir werden heute noch eine bereinigte Version des Compilers zur Verfügung stellen.
Der Source Code zu dem Compiler waere auch nicht schlecht :wink:

Verfasst: 28. Nov 2007 19:32
von Red*Star
Ok, danke, v.a. @chrschn, für die Auskünfte :). Jetzt müssen wir hier nur noch herausfinden, warum wir dauernd Stack Underflows bekommen, aber das sollte mit einem kleinen selbstgeschriebenen Testprogramm auch nicht das Problem sein. Außer... tja, außer:

Wenn schon der Compiler (btw, heißt es hier nicht eigentlich Assemblierer? ;) ) einen Bug hat, gehe ich mal lieber auf Nummer sicher:
Gibt es schon jemanden, der das Praktikum fertig hat, und bestätigen kann, dass die Online-Testfälle fehlerfrei sind (also fehlerfrei ausgeführt werden, *sofern* die SVM ebenfalls fehlerfrei ist*) )?

(Anderenfalls bliebe ja nur die Variante der Pen&Paper-Validierung der Testfälle. ^^)


*) Effekte, wie dass sich zwei Fehler gegenseitig aufheben, wollen wir hier mal vernachlässigen :D

Verfasst: 28. Nov 2007 19:48
von Maradatscha
wir sind soweit, dass test.svm läuft, das spiel ist spielbar, hat aber bugs, die aber nicht von uns kommen.
hello.svm genauso, die endian_b.svm läuft denke ich auch richtig, endian_l.svm sagt noch es wäre big endian ^^

Verfasst: 28. Nov 2007 20:36
von Red*Star
Hehe, bei uns sagt das endian_b-Programm es sei little, und das endian_l-Programm es sei big endian, das ist schon fast wieder lustig ^^. Immerhin sagt das Hello-World Programm "Hello World".
Thx anyway.




Noch eine Frage: Alignment-Kriterien für die Wörter gibt es nicht, oder? (á la "Wortadresse muss durch 4 teilbar sein" bei MIPS)

Verfasst: 28. Nov 2007 21:55
von Red*Star
Toll, so eine einfache Lösung: Der syscall hat nichts auf den stack gepushed und das Wort-Speichern/Laden hat nur ein Byte gespeichert und geladen statt ein ganzes Wort. :/

Immerhin: Die Testfälle funktionieren jetzt soweit :). - Allerdings wird kein expliziter Exit-Syscall im "endian_l/b.svm"-file performed, sondern stattdessen nach 65535 gesprungen. [Nicht weil die VM Mist baut, sondern weil es so im "endian.s"-file steht.] Man hat uns doch mal erzählt, dies sei eine unschöne Methode, um ein Assemblerprogramm zu beenden, oder etwa nicht? ;)

Verfasst: 28. Nov 2007 22:49
von MisterD123
Unschön wie auch immer aber möglich auf jeden fall, ich hab mein beenden-kriterium einmal als command==0 && s0==0 || pc>csize, funktioniert wunderbar.

Und die Testfälle auf der Homepage sind bei mir zumindest fehlerfrei, kann ich bestätigen ;)

Verfasst: 29. Nov 2007 00:33
von Red*Star
pc < 0 auch nicht vergessen? Ich mein ja nur, man weiß ja nie ^^. Das ist zumindest mein Abbruchkriterium (allerdings mit "dropped off bottom"-Warnung als special service für meine ja ach so große und niemals zufriedene SVM-Usergemeinde :D ).

Verfasst: 29. Nov 2007 10:18
von Sascha
Eine korrigierte Version des SVMC steht auf der Homepage zur Verfügung. Ein dw wird jetzt auch so behandelt, wie man es erwartet. Die Testfälle waren davon nicht betroffen. Den Quellcode des SVMC würden wir gerne zur Verfügung stellen (zumal dann Bugs viel schneller gefunden würden), aber der Code enthält bereits sehr viel von dem, was die Lösungen des Praktikums benötigen.

Was das peek()/pop()-Verhalten der Opcodes angeht: Wenn was gepoppt werden soll, dann steht das auch im Aufgabentext. Wenn nichts drin steht, wird auch nichts vom Stack entfernt. Keiner der Opcodes soll etwas anderes tun als das, was in der Aufgabenstellung steht.

endian.s springt in der Tat zu einer ungültigen Adresse, und die VM sollte das abfangen und eine Fehlermeldung ausgeben. Das ist Absicht.

Was die Korrektheit der Testfälle angeht: Die Musterlösung funktioniert natürlich mit allen Testfälle. Ausserdem gibt es bereits einige Einreichungen im Upload-System, bei denen wir mal davon ausgehen, dass sie funktionieren. (Jedenfalls sind sie auf den ersten Blick zum Teil hervorragend programmiert.)

Verfasst: 29. Nov 2007 23:46
von tmx-master
Hi Sascha,

ja, da ist mal wieder. Die alles vernichtende Aussage: "Wir haben schon mal EINE Lösung, die alles erledigt, ....".

Als wir im letztes Semester in einem persönlichen Gespräch mit Hr. Weihe erklärten, dass wir > 15 Stunden an den Praktikaaufgaben sitzen, bekamen wir zur Antwort: "Ich habe gehört, dass es Studenten gibt, die die Aufgaben in 2 Stunden lösen."
Da kann ich nur sagen: Toll und Glückwunsch.
GDI I-III hören weit mehr als 300 Studenten. Da können doch 2-10 keinen Maßstab für alle anderen sein. Oder doch?

Hmm, wenn ich jetzt mal einen Vorschlag zur friedlichen Einigung machen dürfte: Verlängert dieses Praktikum um eine Woche, damit wirklich alle Unklarheiten beseitigt werden können. Auch ich finde die Aufgabe nicht schlecht und würde DIE AUFGABE gerne lösen und nicht Anforderungsmanagement betreiben.

Anhand der momentan vorliegenden Informationen hat sich meine / unsere Gruppe heute schon fast entschlossen, diese Aufgabe aufzugeben und mal die anderen Stapel auf dem Schreibtisch anzugehen. Die gibt es nämlich auch noch ...

Verfasst: 30. Nov 2007 00:32
von Red*Star
Auch wenn es uns eine Verlängerung nichts mehr brächte, da wir das Praktikum schon "fertig" haben (sprich wir müssen es nur noch gründlich testen - bzw. wir *müssten* es eigentlich testen, haben aber wohl keine Zeit mehr dazu, ich sage nur FGdI3 und SE und FoC und GdI HÜ und "Wochenende" [was ist das? ;)] ), kann ich mich der Kritik von tmx-master nur anschließen:

Man kriegt hier alle zwei Wochen einen größeren Hammer reingehauen, zumindest auf den ersten Blick. Nachdem man den ersten Schock überwunden hat, stellt sich zwar meist heraus, dass die Aufgabe doch nicht so unlösbar ist, wie sie am Anfang schien (und dass man vielleicht sogar im Nachhinein stolz darauf ist, eine vermeintlich unlösbare Aufgabe so gut gelöst zu haben), dennoch bleibt immer eine Menge zu tun.
Es ist ja nicht so, dass ich die Aufgabe nicht machen will - ganz im Gegenteil, ich finde gerade diese hier hoch spannend [ich meine, wer träumt nicht seit seinen ersten Berührungen mit dem Computer davon, so etwas wie einen "Computer im Computer" zu programmieren ^^] - aber mal gesetzt das Ziel, das Studium in der Regelstudienzeit zu schaffen, bekommt der Durchschnittsstudent ein ziemliches Arbeitspensum aufgehalst.
(Ob das an der Arbeitsmoral liegt, die von Uncle Sam zu uns herüberschwappe, wie das mein Vater in einer seiner philosophischen Anwandlungen meinte, oder nicht, sei mal dahingestellt. Man kann ja schließlich den Amis nicht die Schuld für alles geben ^^.)
Ich persönlich hatte in diesem Fall das Glück, C schon zu kennen, ich möchte nicht wissen, wie es mir ergangen wäre, hätte ich es noch nie gesehen.

[Merke: Es geht in diesem Post um mein persönliches Gefühl (mit dem ich aber offenbar nicht alleine bin), und keineswegs darum, irgendwelche "objektiven" Kriterien einzubringen á la "50% der Studenten, die das Praktikum bestehen, schaffen die Praktikumsaufgaben im Mittel in 8h, die statistische Streuung beträgt +/- 4h". Aber ich werde das Gefühl nicht los, dass es eventuell auch so ein ganz kleines bisschen wichtig sein kann, im Leben neben dem Objektiven auch auf das Individuelle zu schauen ;).]

So, genug ausgeführt.

Hm, mir fällt gerade auf, dass wir dabei sind, ziemlich ins Offtopic abdriften... vielleicht sollte hier mal ein Admin separieren?