Wie kommen die auf diese Call Func Lösung in der Reihe? 0x0ffe 0x1000 0x0fff 0x1c 0x00 Kann mir das jemand erklären ?
Angehängte Dateien:
:
Bearbeitet durch User
Schau dir an was Call macht, dann kommst du drauf. Zum Thema Hausaufgaben: Wo ist dein Problem? Stell definitive Fragen, dann bekommst du Antworten. Die vollständige Lösung gibt dir keiner, hoffe ich, denn dann müsste der auch die Note bekommen.
Beitrag #6350179 wurde von einem Moderator gelöscht.
Hi Die Frage ist gar nicht so unbegründet. Meines Wissens wird bei einem Call- Befehl der Programmcounter auf den Stack geschrieben und soweit ich weiß, ist das bereits die Adresse nach dem Call. Hier aber wird die Adresse des Call auf den Stack gelegt. Das bedeutet aber, das bei einem Ret wieder die Adresse des Call im Programmcounter landet. Sicher bin ich mir nicht so ganz, wann der PC erhöht wird, aber ich meine, sofort nach dem Einlesen des Befehls und vor seiner Ausführung. Ansonsten ist klar, es ist die Adresse des Call. Gruß oldmax
> Hier aber wird die Adresse des Call auf den Stack gelegt.
Verstehe ich nicht - der call liegt auf 1a, also ist die Folgeadresse
1c, und genau das steht laut Tabelle im Stack.
Hi S. Landolt schrieb: > Verstehe ich nicht - der call liegt auf 1a, also ist die Folgeadresse > 1c, und genau das steht laut Tabelle im Stack. Soweit hast du recht, wenn da nicht stehen würde Adresse nach CALL 1E ! Also muß noch ein Befehl fehlen, denn erst nach einem weiteren, der auf 1A steht kann 1C folgen. Der Call steht demnach auf 1C, und ich meine, der PC hat sofort nach dem Einlesen noch vor der Befehlsausführung die nächste Adresse, und die sollte dann auch auf dem Stack stehen. gruß oldmax
:
Bearbeitet durch User
(ich dreh' mich einmal um, und plötzlich steht was anderes da)
> Adresse nach CALL 1E
Das liegt wohl an dem 'On-chip Debug system'- break; aber damit habe
ich selbst noch nie gearbeitet.
Wenn das wirklich 'ne umfangreiche Hausaufgabe ist ... aber selbst wenn ich von Assembler keine Ahnung habe, habe ich das innerhalb einer Stunde durch einen passenden Simulator gejagt. Sieht irgendwie aus wie AVR-Assembler.
Hi S. Landolt schrieb: > Quatsch - natürlich 1e, dorthin springt ja der call ! Jo, da hast du recht. Aber wie auch immer, sehr verwirrend, da bin auch ich mal wieder drauf reingefallen, eine "Func" mitten im Programm, ächt ätzend.. Gruß oldmax
Immerhin haben wir jetzt eine Diskussion, an der sich dann auch Hammer V. beteiligen kann - eine pauschale Lösung wird er wohl nicht bekommen, dazu wäre das komplette Ausfüllen auch für einen Willigen doch zu viel Arbeit.
Ben B. schrieb: > selbst wenn > ich von Assembler keine Ahnung habe, habe ich das innerhalb einer Stunde > durch einen passenden Simulator gejagt. Arm, wenn man eine Stunde braucht, um eine Zeile Code aus einem Papierlisting zu simulieren, wenn 1 Minute hinschauen reicht. Da steht exakt was passiert, und wenn man auch nur im Ansatz versteht was call macht (im übrigen völlig unabhängig der nicht genannten Architektur), dann kann man doch sehen was da passiert, aund auch warum. Es fehlt OP nur am Leseverständnis. Einfach die Tabellenkopfzeile und die fragliche Zeile zusammen mit der ersten nochmal genau durchlesen, dann sollte es klappen.
Hammer V. schrieb: > Wie kommen die auf diese Call Func Lösung in der Reihe? Der SP wird rückwärts gezählt. Entsprechend verringert sich die Adresse am SP: Mach doch nen Test. Nim statt call (4 Byte Befehl) rcall (2 Byte) und guck mal. ciao gustav
Karl B. schrieb: > Der SP wird rückwärts gezählt. > Entsprechend verringert sich die Adresse am SP: > > Mach doch nen Test. > Nim statt call (4 Byte Befehl) > rcall (2 Byte) > und guck mal. Was hat der Unterschied zwischen call und rcall mit dem Stack bzw. dem Stackpointer zu tun? Es werden immer zwei Bytes abgelegt.
> Arm, wenn man [blah]
Ich meinte erstens eine Stunde für das komplette Problem und nicht nur
eine einzelne Zeile. Zweitens bin ich ziemlich gut in Assembler, könnte
das vermutlich ohne Simulator - ist nur etwas Schreibarbeit damit man
keine Fehler macht.
Aber natürlich wolltest Du das nicht verstehen... verständlich!
Ben B. schrieb: > Aber natürlich wolltest Du das nicht verstehen... verständlich! Ich muss das nicht versuchen, ich hab es verstanden, und das hat nicht mal lange gedauert. Die eine Zeile und die Frage dazu braucht nur ein wenig Nachdenken, und die Lösung ist klar. Wobei es kein Rätsel ist, nur ein Verständnisproblem. Die frage ist allerdings zu allgemein gestellt, Hausaufgaben soll man hier ja nicht beantworten. "Warum zählt der Stack rückwärts?" wäre z.B. eine Frage gewesen, die man hätte beantworten können, da wäre dann etwas Initiative sichtbar gewesen. Aber natürlich wolltest Du das nicht verstehen... verständlich!
Jens M. schrieb: > Warum zählt der Stack rückwärts?" wäre z.B. eine Frage gewesen, die man > hätte beantworten können, da wäre dann etwas Initiative sichtbar > gewesen. Naja das ist nicht in Stein gemeißelt. Auch wenn bei den meisten Architekturen der Stack rückwärts wächst. Das kann auch anders sein.
Thomas Z. schrieb: > Naja das ist nicht in Stein gemeißelt. Auch wenn bei den meisten > Architekturen der Stack rückwärts wächst. Das kann auch anders sein. Tjoa, bei der Arch oben in der Aufgabe isser "Standard".
Es ist ja keine Hausaufgabe, da ich ja die Lösung mit gepostet hab :) Nach call func steht 0x0ffe ? Woher kommen die darauf? Und wie kommen die auf SPEICHERADRESSE geändert drauf ? Speicherinhalt nach dem Befehl? Eine Erklärung wäre schön
Steht doch alles im von mir gezeigten Auszug des 'AVR® Instruction Set Manual' > Nach call func steht 0x0ffe ? 'SP ← SP-2, (2 bytes, 16 bits)' - SP stand zu Beginn auf 0x1000. > Und wie kommen die auf SPEICHERADRESSE geändert drauf ? 'STACK ← PC+2' > Speicherinhalt nach dem Befehl? Auf dem Stack wird die Adresse für den Rücksprung abgelegt, d.h. die Adresse des auf den call folgenden Befehls.
Vielleicht bin ich dumm. Aber ich verstehe immer noch nicht ? 0x1000- 2 = 0x00fe ? Das 0x0fff,0x1c,0x00 ? Wie rechnen die das aus ? ich kapiere es sorry nicht
Hammer V. schrieb: > 0x1000- 2 = 0x00fe ? Nein 0x1000 - 2 = 0x0ffe Oder 0x0100 - 2 = 0x00fe Das ist ganz banale Mathematik im Hexadezimalsystem. Wenn man hoch zählt, kommt nach 00fe die Zahl 00ff und dann 0100. Und nach 0ffe kommt 0fff und dann 1000.
Ah jetzt verstehe ich es . Und bei Speicheradresse geändert ? Da zählen die nur 1 runter ? 0x1000- 1 = 0x0fff ? Aber wie die auf das kommen ?0x1c 0x00 Verstehe ich immer noch nicht :)
Vielleicht führst du das Programm mal step-by-step im Simulator aus. Dabei liest du im "Instruction Set Manual" für jeden einzelnen Befehl die Beschreibung und guckst dir im Simulator die Bestätigung dessen an.
Schreibe mal bald klausur und muss das verstehen Mir fällt das thema sehr schwer
Hammer V. schrieb: > Aber wie die auf das kommen ?0x1c > 0x00 Hi, das ist das (der Wert, das Argument), was in der Speicherzelle steht. Das Ergebnis der Rechenoperationen vorher. Nicht die Adresse selbst. ciao gustav
Der PC (program-counter) steht auf Adresse 0x001a des Programmspeichers (flash, hier wird in Worten, also Doppel-Bytes, gezählt). Dort steht der Befehl call, ein 2-Wort-Befehl. Der SP (stack-pointer) steht auf Adresse 0x1000 des Arbeitsspeichers (RAM bzw. SRAM, hier wird in Bytes gezählt). call schiebt seine Folgeadresse, 0x001c, auf den Stack. Diese Adresse ist ein Wort, also zwei Bytes, folglich steht anschließend im RAM auf Adresse 0x1000 das Low-Byte 0c und auf Adresse 0x0fff das High-Byte 00 der Folgeadresse. Der stack-pointer wurde dabei um 2 heruntergezählt. Anschließend springt der PC zu der im call angegebenen Adresse 0x001e == func.
Um es nochmals, deutlicher, zu erklären: Der Program-counter PC zählt (schaltet) im Programmspeicher in Wort-Schritten aufwärts (außer bei Sprüngen). Der Stack-pointer SP zählt (schaltet) im Arbeitsspeicher in Byte-Schritten abwärts.
Und wenn ich noch, angesichts des sehr schleppenden Verlaufs hier, einen Rat aus meinem Bliss anfügen darf: 'The amount of time spent on a project is not what counts: it's the amount of uninterrupted time. Few problems can resist an all-out attack; few can be solved piecemeal.'
Ich hatte mir das jetzt so erklärt 0x01a wird 2 mal hochgezählt also 0x01c Aber wie kommen die dann auf das 0x00 ? Das ist mir immer noch nicht klar Sorry Aber es hilft ja nicht wenn ich sage, dass ich es verstehe :) Aber danke schon mal für eure Geduld
> Aber wie kommen die dann auf das 0x00 ?
Wie bereits geschrieben, das ist das High-Byte der Adresse.
Eine Programmadresse besteht aus 1 Wort, das sind zwei Bytes. Der
Arbeitsspeicher, der u.a. ja auch als Stack dient, ist in Bytes
gegliedert, folglich muss eine Programmadresse, wenn sie im
Arbeitsspeicher abgelegt werden soll, in die einzelnen Bytes, high und
low, aufgespalten werden.
Kann man sagen das das 0x00 der Startpunkt des Programmes ist also 0x00?
Jein. Offenbar hat die verkürzte Schreibweise der Adressen zu Beginn zu Irritationen geführt (mea culpa, u.a.). Ein Adresse hat (hier) immer 2 Bytes, dargestellt in 4 nibbles : 0x1234. Ein Programm beginnt nach einem Reset (normalerweise) bei 0, also 0x0000. Der hier diskutierte Programmausschnitt beginnt bei 0x001a. Warum das in der einen Tabelle als "00001a" geschrieben wird, sei mal dahingestellt, führende Nullen stören ja nicht weiter.
Falls Grundlagen fehlen: ein Byte hat 256 verschiedene Zustände; wie schreibt man das am besten - man benutzt Hexadezimal-Ziffern, 0..9,a..f, das sind 16 Zustände. 16^2 ergibt 256, also wird ein Byte mit zwei Hexziffern geschrieben, bzw. eine Adresse, bestehend aus zwei Bytes, mit vier Hexziffern. Anders gesagt: ein halbes Byte, ein nibble, wird mit einer Hexziffer notiert.
1 | Das Halbwort und das Doppelwort |
2 | trieben Sport. |
3 | Als Partner wählten sie sich Liste |
4 | und byte auf langer Speicherpiste. |
5 | |
6 | Gemischtes Doppel hält sie fit; |
7 | Ball ist's bit. |
KLEN (in memoriam)
Eine schöne Übung: Statt für dies und das von 1 bis x oder von 0 bis x zu zählen, einfach mal mit Hex-Zahlen von 100 bis x rückwärts zählen. 100 FF FE FD FC ..usw. Z.B. könnte man eine zeitlang Benzinpreise verfolgen, die Preise nach Hex übersetzen und Preissteigerungen oder Preissenkungen mit Hexzahlen anzeigen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.