ASM-Code und C in einem Programm

A. S. schrieb:
> Felix M. schrieb:
>> aber kann man immer annehmen, dass R0 der erste Parameter, R1 der
>> zweite, usw. ist?
>
> Und wenn 10 oder 100 Parameter übergeben werden? Oder der erste 70 Byte
> hat?

Wenns zu viele Parameter werden gibts dann noch den Stack.

Vielen Dank für eure Antworten.

Ich sehe, dass ich mich wohl noch durch so einiges an Dokus durchwälzen 
darf :D

Dennis H. schrieb:
> Wenns zu viele Parameter werden gibts dann noch den Stack.

Stimmt, das hab ich fast schon wieder vergessen. Aber ganz so 
umfangreiche Argumente haben wir dann auch wieder nicht - da sah es bei 
den C++-Projekten schon ganz anders aus.

Bezogen war das eigentlich mehr auf das Ausweichen auf den Stack. Aber 
du hast natürlich Recht - die Register könnten genauso durch {something} 
aus dem restlichem C-Programm belegt sein und deswegen der Stack 
verwendet werden.

Felix M. schrieb:
> Bezogen war das eigentlich mehr auf das Ausweichen auf den Stack.
> Aber du hast natürlich Recht - die Register könnten genauso
> durch {something} aus dem restlichem C-Programm belegt sein und
> deswegen der Stack verwendet werden.

Die ABI, mit der ich mal zu tun hatte (Cortex-M3), definierte das 
ungefähr wie folgt (mal aus meinen alten Folien gekratzt und übersetzt):

Die ersten vier 32-Bit-Argumente liegen in R0, R1, R2 und R3 oder
die ersten beiden 64-Bit-Argumente liegen in R0:R1 und R2:R3 oder
das erste 128-Bit-Argument liegt in R0-R3.
Was bei Mischbestückung passiert, weiß ich aus dem Kopf nicht.

Weitere Argumente liegen auf dem Stack, von links nach rechts.

Der Rückgabewert liegt in R0 (32-Bit), R0:R1 (64-Bit) oder R0-R3 
(128-Bit).

Die Register R0-R3, R9, R12, LR und PC dürfen von einer Funktion 
zerstört werden, alle anderen Register müssen vor und nach dem 
Funktionsaufruf gleich sein.

Weitere Regeln existieren, hatte ich aber nicht in der Vorlesung. Der 
Kurs damals war ausschließlich Assembler, die ABI wurde also für jede 
Funktion und Aufgabe irgendwie definiert und musste von den Studenten 
entsprechend dokumentiert werden.

Zien schrieb:
> Lass das doch vom Compiler erledigen:

Wenn der Dozent vorgibt, dass externe Assemblerquellen zu verwenden 
sind, dann ist das nicht zulässig.

Dafür hätte es von mir einen Punkt für Originalität gegeben.
Mehr nicht, weil Aufgabenstellung nicht erfüllt.

MaWin schrieb:
> Was funktioniert denn damit nicht?

Dein Vorschlag würde mit ziemlicher Sicherheit funktionieren (man könnte 
genauso gut auch alles rein in C schreiben), aber die Vorgabe der Profs 
ist, dass bestimmte Teile des Programms in Assembler zu schreiben sind.

Im aktuellem Projekt ist z.B. die main() und das komplette Interrupt 
Handling samt SysTick in Assembler zu schreiben.

MaWin schrieb:
>> weil Aufgabenstellung nicht erfüllt
> Was funktioniert denn damit nicht?

Solcherlei Aufgabenstellungen lauten nicht "schreibe funktionierenden 
Code", sondern sie lauten eher "löse folgendes Problem auf die in der 
Vorlesung / hier beschriebene Weise".

MaWin schrieb:
> Welcher Compiler macht das denn bitte?

Keiner. Das macht der Programmierer.

Oliver

Das ist mir völlig klar, der Vorschlag kam aber nicht von mir. Das Thema 
hat da jemand anderes verfehlt.

Oliver

Georg schrieb:
>> Weitere Argumente liegen auf dem Stack, von links nach rechts
> Das muss nicht so sein, [...]

Für die von mir zitierte ABI ist das aber so. Immer.

S. R. schrieb:
> Solcherlei Aufgabenstellungen lauten nicht "schreibe funktionierenden
> Code", sondern sie lauten eher "löse folgendes Problem auf die in der
> Vorlesung / hier beschriebene Weise".

wenn das mal so wäre!
Leider sind auch Dozenten nicht fehlerfrei und lassen den Frust bei 
korrekter Umsetzung gemäß der Aufgabenstellung auch mal gerne an dem 
Prüfling aus!

Wie verstehst du denn folgende Aufgabenstellung:
"ermitteln sie den Wert des Integrals" programmierbare Rechner sind 
zugelassen!

Mit der keplerschen Fassregel und Programm habe ich die Aufgabe erfüllt 
und trotzdem 0 Punkte und eine Note 6 kassiert!
https://de.wikipedia.org/wiki/Simpsonregel

An keiner Stelle war Handarbeit gefordert und Käsekästchen unter der 
Funktion zu addieren kann der Rechner viel besser als ich.

Joachim B. schrieb:
> Leider sind auch Dozenten nicht fehlerfrei [...]

Das ist mir klar. Aber wenn du mir unterstellen möchtest, ich sei ein 
furchtbarer Dozent gewesen, dann kann ich dir nur sagen, dass ich aus 
dem System raus bin. :-)

Arschlöcher gibt's überall im Leben und Arschlöcher mit Machtgefälle 
sind überall besonders unangenehm, egal ob das nun Dozenten, Lehrer, 
Chefs oder höherqualitative Kollegen sind.

S. R. schrieb:
> Aber wenn du mir unterstellen möchtest

nie im Leben, ich kenne dich nicht!

Mit meinem Dozenten konnte ich mich später einigen und musste in der 
mündlichen Prüfung die 6 zu einer 2 umbauen.....
puh noch mal gut gegangen!
Aber ärgerlich fand ich das schon, leider waren nicht alle Dozenten 
fair, da konnte man nur demütig abnicken und hinnehmen.

Joachim B. schrieb:
>> Aber wenn du mir unterstellen möchtest
> nie im Leben, ich kenne dich nicht!

Das freut mich. Es gibt hier nur so einige Spezialisten, die das 
vermutlich aus Prinzip anders sehen.

Was mich halt stört ist, wenn (absichtlich) Vorschläge gemacht werden, 
die die Aufgabenstellung untergraben. Und dann muss man sich als 
Korrektor - oft genug nichtmal für die Aufgaben verantwortlich! - mit 
Lösungen rumschlagen, die weder ins Lösungsschema passen noch 
ausgearbeitet sind. Das kostet Zeit und Nerven, wenn man den Studenten 
gegenüber einigermaßen fair sein möchte.

Es geht ja nicht nur um "die Lösung funktioniert theoretisch", sondern 
auch "die Standardlösung gibt 20 Punkte, die hier vorgestellte Lösung 
funktioniert komplett anders und funktioniert auf Anhieb nicht, könnte 
aber mit ein bisschen Debugging funktionieren, wieviele Punkte vergibt 
man dafür?".

Wer das nie gemacht hat, kann das vermutlich nichtmal einschätzen. Und 
ich kann Dozenten verstehen, die das komplett ausblenden und mit "hau 
ab" quittieren, obwohl ich das absolut nicht respektiere.

rbx schrieb:
> Mit der AT&T Asm-Sytax (beim gcc) müsste man sich erstmal anfreunden.
> Ich meine, das geht leichter, wenn man schon die wichtigsten
> Assembler-Grundlagen intus hat.

In erster Linie erwarte(te) ich, dass der Student in der Klausur den 
gleichen Assembler-Dialekt und Architektur verwendet, den er in den 
Vorlesungen vermittelt, in den Übungen verinnerlicht und im Praktikum 
angewendet hat.

> Als ich (zur Jahrtausendwende) ging, standen
> 30-50 - und mehr Leute vor der Türe vom Professor.

Dafür haben kluge Leute mal E-Mails erfunden.
Dummerweise ist nicht jeder Professor willens, das auch zu benutzen.
Dummerweise ist nicht jeder Student zur sinnvollen Nutzung fähig.

Klausurbesprechung kenne ich grundsätzlich aus der letzten Vorlesung. 
Bei manchen Dozenten sehr sinnvoll, bei manchen eher nutzlos.

> Letztlich muss jeder für sich selbst einen Weg finden, wie mit den
> Unmengen an Wissen klarkommen.

Bulimie-Lernen ist verbreitet und in den meisten Fächern (leider) die 
optimale Herangehensweise. Das Bildungssystem ist da nicht ganz 
unschuldig.

Andererseits muss man auch sagen, dass Frontalunterricht bei allen 
Nachteilen die mit Abstand die beste Methode ist, wenn man viel Wissen 
in kurzer Zeit vermitteln will. Und Studenten wollen Youtube-Videos, was 
ja effektiv auch nichts anderes ist, nur mit besseren Mitteln.

S. R. schrieb:
> Bulimie-Lernen ist verbreitet

der Begriff gefällt mir, wie hiess es früher?
Nicht für die Schule sondern fürs Leben lernen wir, zugegeben manches 
darf aus dem Langzeitspeicher ruhig verschwinden, dummerweise tut es 
nicht immer das Sinnloseste, "333 Isos Keilerei"
https://de.wikipedia.org/wiki/Schlacht_bei_Issos

Felix M. schrieb:
> Konkret geht es um die Verwendung von ASM-Files (*.s) in C-Programmen.
> Bei einem Projekt haben wir eine main.c als Rahmenprogramm
> (Funktionsköpfe und main{...}) vorgegeben bekommen und mussten die
> einzelnen Funktionen in Assembler in einem separatem Assembler-File
> implementieren.
>
> Bei der Implementation habe ich immer angenommen, dass der erste
> Parameter einer Funktion in R0 und der zweite in R1 ankommt.
> Ich weiß, dass die Register R0 bis R3 für Übergabeparameter vorgesehen
> sind (Procedure Call Standard for the Arm® Architecture, Seite 18/19),
> aber kann man immer annehmen, dass R0 der erste Parameter, R1 der
> zweite, usw. ist?
wegen .s vermute ich mal, daß es sich um nasm Assembler handelt?
Welchen C Compiler verwendet Ihr denn? gcc oder was anderes?
Bißchen konkreter wäre nicht schlecht ... hier wirst Du allerdings 
sowieso keine Antwort finden; trotzdem viel Erfolg.

rbx schrieb:
> Der spannende Teil ist: der Begriff (Bulimie)
> hört sich irgendwie schon so krank an..

Ist es ja auch...

rbx schrieb:
> Um so wichtiger ist auf jeden Fall, und das wird hier deutlich, dass
> vorsortiertes und voroptimiertes "Material" genutzt wird - sonst würde
> diese Geschichte gar nicht gut funktionieren, und die Gefahr von
> Motivationsverlust und Verzettelung wäre um so größer.

Breit gefächertes, wenig sortiertes und optimiertes Material wird von 
all jenen bevorzugt, die ein "holistisches" Bildungssystem wünschen. Was 
hier mit "seinen Namen tanzen lernen" verspottet wird, hat durchaus Hand 
und Fuß; vernetztes Wissen bleibt hängen, eine Faktensammlung nicht.

Davon abgesehen führt optimiertes Material immer zu einem Verlust von 
Wissen und dem wiederum trauern die Älteren nach, die dafür einstmals 
ihre Lebenszeit opfern mussten. Es gibt durchaus interessante 
Technologien, die mal verbreitet waren, es nicht mehr sind, aber unter 
den aktuellen Bedingungen durchaus wieder werden könnten. Haben die 
Entscheider aber nie von gehört, wird also auch nicht berücksichtigt.

S. R. schrieb:
> Davon abgesehen führt optimiertes Material immer zu einem Verlust von
> Wissen und dem wiederum trauern die Älteren nach

mit was? Mit Recht
Wir können 1000 Jahre alte Steinplatten entziffern aber kaum noch 
digitale Medien seit 1980.

Zur Optimierung gefällt mir immer wieder:
https://www.youtube.com/watch?v=7FeqF1-Z1g0

Geschichte wiederholt sich, auch in der IT.

A. S. schrieb:
> In Mechanik (bei uns ein Nebenfach) weiss ich noch, wie der Prof
> seinerzeit resümierte, dass ein Großteil der Studenten die
> Schrauben-Berechnung zum ersten Mal in ihrem Leben überhaupt in der
> Klausur selbstständig machen.

Daran ist der Prof aber nicht ganz unschuldig.

Und mal Hand aufs Herz: Die wenigsten Studenten brauchen im ersten 
Studienjahr höhere Mathematik. Der Bedarf kommt erst lange nach den 
Klausuren.

Rückblickend waren die späteren und interessanteren Kurse auch immer 
mehr qualitativ als quantitativ. Da hat man dann auch keine DFTs mehr 
berechnet, sondern sich berechnen lassen und analysiert. Hauptsache man 
wusste, (a) dass man das berechnen kann, (b) grob was man tun müsste, 
wenn man wöllte und (c) was man daraus ablesen kann.

Unser Prof in E-Technik war immer traurig, dass die Studenten die 
Winkelfunktionen nicht mehr im Kopf zwischen bekannten Punkten 
interpolieren konnten. Mussten wir auch nicht können, wir hatten 
Taschenrechner...

A. S. schrieb:
> Klavierspielen schafft man doch auch, wenn man Abends vorher übt.

Ja, aber nicht, wenn man nur am Abend vor der Klausur intensiv übt und 
sich dann auf sein Kurzzeitgedächtnis verlässt. ;-)

Felix M. schrieb:
> aber kann man immer annehmen, dass R0 der erste Parameter, R1 der
> zweite, usw. ist?

Der erfahrene Programmierer nimmt gar nichts an.
Er schreibt eine Dummyfunktion, die genau die benötigte Anzahl und Typen 
der Argumente, Returnwerte und Variablen verwendet. Diese läßt er dann 
nach Assembler compilieren und hat somit den Rumpf für sein 
Assemblerprogramm.
Wichtig ist dabei, auch die gewünschten Compilerschalter und 
Optimierungslevel zu setzen. Je nach Compiler und Target kann das 
nämlich auch die Argumentenübergabe beeinflussen.
Z.B. beim Keil C51 unterscheidet sich der erzeugte Rumpf für Small und 
Large erheblich.

Peter D. schrieb:
> Der erfahrene Programmierer nimmt gar nichts an.

Würde ich so nicht unterschreiben. Der erfahrene Programmierer schaut 
sich an, was garantiert wird (d.h. schaut in die Dokumentation vom ABI), 
prüft das und hält sich dann an die Regeln.

Peter D. schrieb:
> Z.B. beim Keil C51 unterscheidet sich der
> erzeugte Rumpf für Small und Large erheblich.

Ja, das sind unterschiedliche ABIs, die von Keil ganz sicher auch 
passend dokumentiert sind.

S. R. schrieb:
> Der erfahrene Programmierer schaut
> sich an, was garantiert wird (d.h. schaut in die Dokumentation vom ABI),
> prüft das und hält sich dann an die Regeln.

Nun, das ist prima, wenn man mehrere Baustellen gleichzeitig aufreißen 
will.
Funktioniert etwas nicht, dann kann es sein, daß die ABI-Doku fehlerhaft 
ist oder man hat sie nicht richtig verstanden/verwendet oder das 
Programm ist fehlerhaft.
Läßt man aber den Compiler das machen, was er am besten kann, also einen 
Rahmen erstellen, fallen schonmal 2 Baustellen weg. Außerdem geht das 
deutlich schneller.

Peter D. schrieb:
> Funktioniert etwas nicht, dann kann es sein, daß die
> ABI-Doku fehlerhaft ist oder man hat sie nicht richtig
> verstanden/verwendet oder das Programm ist fehlerhaft.

Darum das "prüfen".

Peter D. schrieb:
> Außerdem geht das deutlich schneller.

Ja, das macht man dann in der Realität und irgendwann fliegt es einem um 
die Ohren. Been there, done that.