www.mikrocontroller.net

Forum: Compiler & IDEs push pop asusschalten


Autor: Peter Lustig (registerpeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 =)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Lustig (registerpeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Peter Lustig (registerpeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 =)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Lustig (registerpeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Peter Lustig (registerpeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Peter Lustig (registerpeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Lustig (registerpeter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.