Hi, gibt es eine Möglichkeit push/pop für eine funktion abzuschalten? Habe das bisher nur in verbindung mit bascom gefunden als INterrupt. Problem ist folgendes: Im main lade ich werte in bestimmte register. Dann ruf ich eine void unterfunktion auf, die auf diese Regs zugreift und die Ergebnisse in anderen bestimmten Regs abspeichert. Diese will ich dann im main auslesen. DUrch die pops am Ende werden die Regs ja wieder zerstört, oder? Möchte die Werte auf keinen fall in den SPeicher legen und darin übergeben. Im main wird ja erst am Schluss gepopt, oder? Das heisst die Werte müssten noch in den Regs stehen wenn ich in der Unterfunktion lande? Danke schonmal edit: Könnte natürlich auch von Hand die pushs und pops im assmblerfile entfernen, aber es wäre schöner und wichtig, wenn es einfach ausm AVRStudio schon richtig rauskommt =)
Peter Lustig schrieb: > gibt es eine Möglichkeit push/pop für eine funktion abzuschalten? Warum willst Du, daß Dein Programm abstürzt? Der Compiler ist ja nicht blöde, er sichert nur Register, die er benötigt. > Im main lade ich werte in bestimmte register. Dann hast Du schon verloren. Als C-Programmierer benutzt man Variablen und keine Register. Wenn dann der Compiler beim Optimieren Variablen in Register packt, dann ist das sein Bier. Die Register gehören zu 100% dem Compiler. Wenn Du über Register frei verfügen willst, darfst Du kein C programmieren. > Dann ruf ich eine void unterfunktion auf, die auf diese Regs zugreift > und die Ergebnisse in anderen bestimmten Regs abspeichert. Nö, dazu nimmt man Argumente und Rückgabewerte! > Im main wird ja erst am Schluss gepopt, oder? Nö, das Main läuft endlos. Wie gesagt, der Compiler ist ja nicht blöde, toten Code läßt er weg. Peter
Ein gewisses Problem dabei ist, daß es nur einen Rückgabewert gibt. Wenn man mehrere Werte zurückgeben will, muß man das über Zeiger-Parameter machen, und die Variablen müssen dann im Speicher stehen, damit man darauf zeigen kann. Wenn das schon ein Problem darstellt, ist aber fraglich, ob C die richtige Sprache ist.
Rolf Magnus schrieb: > Ein gewisses Problem dabei ist, daß es nur einen Rückgabewert gibt. Wenn > man mehrere Werte zurückgeben will, dafür kann man auch globale variable benutzen, im besten fall werden sie auch gleich zu Registern.
Also habe das jetzt über das naked attribut gemacht. Assemblermässig sieht das ganze gut aus. Obs dann eben läuft oder abschmiert wird sich noch zeigen. @Peter: Ich weiß, dass man das eigentlich auf keinen Fall so machen sollte, ABER falls Du Dich noch dran erinnerst, ich bin der mit dem modifizierten Atmel mit breiteren Registern und normalem Speicher. Deswegen MÜSSEN die Werte in den Regs gehandelt werden. Danke trotzdem. Mal sehen ob das läuft...
Peter schrieb: > dafür kann man auch globale variable benutzen, im besten fall werden > sie auch gleich zu Registern. Ich kann mir kaum vorstellen, daß gcc jemals eine globale Variable von sich aus in ein Register steckt. Das muß man ihm dann explizit sagen. Wäre zwar nicht sonderlich elegant, aber eine Alternative wäre es. Peter Lustig schrieb: > ich bin der mit dem modifizierten Atmel mit breiteren Registern und > normalem Speicher. Deswegen MÜSSEN die Werte in den Regs gehandelt > werden. Ehrlich gesagt halte ich es immer noch für eine selten dämliche Idee, einen in einem einzelnen Detail modifizierten Prozessor-Core zu bauen, den Rest seiner Architektur nicht daran anzupassen und dann auch noch in C mit einem nicht an diese Änderung angepaßten Compiler zu programmieren. Damit wird man regelmäßig auf die Schnauze fallen. Wenn ich mich recht erinnere, war es nicht deine Idee, aber ist es nicht möglich, demjenigen begreiflich zu machen, wie unsinnig das ist?
Hehe, ja Du sagst es =) Aber hab die Problematik ganz gut im griff mittlerweile. Hab für Standard befehle den Zugriff auf die unteren 8 Bit beschränkt in den Regs, damit hab ich dann das printf Prob gelöst. War nur ein Hardware Bug meines Vorgängers...der mich 3 monate gekoster hat :-/ Ja ich muss halt darauf achten, dass sich der gcc an meine Vorgaben hält. Nee muss da jeztt leider durch bis ich dann in 1,5 Monaten fertig bin mit der DA. Gruß und danke =)
Peter Lustig schrieb: > Hab für > Standard befehle den Zugriff auf die unteren 8 Bit beschränkt in den > Regs, damit hab ich dann das printf Prob gelöst. War nur ein Hardware > Bug meines Vorgängers...der mich 3 monate gekoster hat :-/ Das wurde damals schon vermutet, da ein Fehler im printf längst aufgefallen sein müßte. Ich würde trotzdem die erweiterten Register im SRAM mit einblenden. Dann kannst Du sie in C zugreifen ohne jedwede Verrenkungen des Compilers oder des Code. > Nee muss da jeztt leider durch bis ich dann in 1,5 Monaten fertig > bin mit der DA. Klingt recht sportlich. Peter
Peter Dannegger schrieb: > Das wurde damals schon vermutet, da ein Fehler im printf längst > aufgefallen sein müßte. > > Ich würde trotzdem die erweiterten Register im SRAM mit einblenden. > Dann kannst Du sie in C zugreifen ohne jedwede Verrenkungen des > Compilers oder des Code. Ja, das halte ich auch für das einzig vernünftige! Aber es geht nunmal leider auch um den Platz, der auf dem FPGA verbraucht wird. Und wenn das SRAM auch noch verbreitert würde ist das wohl zu viel Verbrauch... Naja, da muss ich jetzt halt durch, und hey, ich schon ganz schön viel zum laufen gebracht auf dem Ding ;-)
Peter Lustig schrieb: > Naja, da muss ich jetzt halt durch, und hey, ich schon ganz schön viel > zum laufen gebracht auf dem Ding ;-) Vielleicht erinnere ich mich auch nicht mehr: Ich hab da zwei Frage Welche Befehle wurden da eigentlich verbreitert? Ich nehme mal an, dass es sich um Arithmetik u dgl. handelt und das Ziel ist es den Prozessor schneller zu machen. Für welche Anwendung ist das relevant oder ist das mehr eine allgemeine 'Zielsetzung'? Frage 2: Gibt es schon Messergebnisse, was die Modifikation bringt?
aha, naked entfernt ja auch den ret...
Dann würde es wohl nie zurückkehre aus der Funktion, was?
Krieg ich das mit einem asm("ret") am Ende der Funktion in den Griff?
Karl heinz Buchegger schrieb: > Vielleicht erinnere ich mich auch nicht mehr: > Ich hab da zwei Frage > > Welche Befehle wurden da eigentlich verbreitert? Ich nehme mal an, dass > es sich um Arithmetik u dgl. handelt und das Ziel ist es den Prozessor > schneller zu machen. Für welche Anwendung ist das relevant oder ist das > mehr eine allgemeine 'Zielsetzung'? > > Frage 2: Gibt es schon Messergebnisse, was die Modifikation bringt? Das ist leider ein Punkt, zu dem ich mich nicht äußern kann.. Ist ja "geheim" und will da keinen ärger riskieren :-( Es sind spezielle Berechnungen die eben über die ganze Regbreite durchgeführt werden. Dazu eben auch neue Befehle und Opcodes, die dem Assembler beigebracht wurden. Ja die Ergebnisse haben so ca einen Faktor von 100. Also der modifizierte ist ein paar hundert mal schneller als der normale. Damit wird dann eben der mehraufwand in der Software gerechtfertigt.
Peter Lustig schrieb: > Das ist leider ein Punkt, zu dem ich mich nicht äußern kann.. Ist ja > "geheim" und will da keinen ärger riskieren :-( Schade. Nicht mal eine Andeutung in welchem Bereich ihr euch bewegt Finanzmathematik, Graphikworkstation, Regelungstechnik, Videoauswertung, OCR, teuflisch schwierige quadratische Gleichungen, .... ? > Ja die Ergebnisse haben so ca einen Faktor von 100. Also der > modifizierte ist ein paar hundert mal schneller als der normale. Damit > wird dann eben der mehraufwand in der Software gerechtfertigt. Faktor >100 ist schon nicht schlecht.
Karl heinz Buchegger schrieb:
> teuflisch schwierige quadratische Gleichungen,
das trifft es ganz gut =) Tut mir leid, ich trau mich echt nich mehr zu
sagen, da das eben auch für spezielle Firmen ist und ich da wirklich die
Klappe halten muss.
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.