[CALU] Re: Register Policy?
- From: Martin Elshuber <e9825286@xxxxxxxxxxxxxxxxxxxx>
- To: calu-ss2010-tuwien@xxxxxxxxxxxxx
- Date: Tue, 18 May 2010 02:27:00 +0200
Benedikt Huber wrote:
Hi,
ein wenig vorgegriffen, aber wir sollten uns noch auf eine Policy fuer
register allokation einigen.
Da wir keinen Compiler haben, muessen wir fuer reusable library
functions wohl ein relativ simples Schema verwenden.
Eine Moeglichkeit:
- Return Value in r0
- Argumente in r0..rk (Caller Save, damit die Funktion direkt mit den
Parametern arbeiten kann ohne sie vorher sichern zu muessen)
- 2,3 Register (r13-r15) sind temporaer, sprich Caller-Save
- Bei den restlichen bin ich mir nicht sicher - halbe/halbe
vielleicht? (wie war noch mal die experimentell beste Aufteilung lt.
Krall?)
Gibt es fuer assembly code library functions eine bessere Moeglichkeit
als die Aufteilung in caller und callee safe?
gute nacht,
benedikt
das ich ich jetzt gebaut habe hat alles returnwert void
als uart-base register nehme ich r15 (wobei es bei den kurzen funktionen
eine variante gibt, die das register voher sichert, und die addresse
selbst lädt)
Eine "langsame" funktion gibt es UARTSendHex. Sie konvertiert ein
Register in ASCII Hex Ziffern und schickt das ganze zum UART.
Verwendet werden ein Predikat(für den makrobefehl) und r0 (Daten). Die
Funktion verwendet derzeit nur die oberen Register (konkret r9 bis r14)
Setzt sie aber vor dem iret wieder zurück.
ich denke aber auch das es sinvoll ist sich zu einigen. zb daß r0,r1,...
die input parameter sind. sowie daß es welche gibt die eine funktionen
nach belieben verändern darf,
und natürlich einige die invariant bleiben müssen:
Ein Konkreter Vorschlag:
IN: r0,r1,.... (je nachdem vieviele es sind)
OUT: r0,r1,.... (je nachdem vieviele es sind)
Die Funktion darf alle register >=r10, sowie die OUT register verändern
Der Rest muss erhalten bleiben.
Weiters würde ich auch noch vorschlagen, daß die Predikate auch
invariant bleiben sollten (sprich iret* verwenden) wenn nicht explizit
anders erwünscht.
Wenn wir uns mal auf was geeinigt haben. Dann sollte jede Abweichung
vermieden werden bzw. wenn nicht anders möglich/sinnvoll dick und fett
im funktionskopf dokumentiert werden.
fasst das ganze mal als eine konkretisiereung von benedikts idee auf
meinen code schreibe ich gerne wieder um, da er primär zum debuggen
entwickelt wurde
g martin
ps.: habe heute 2 stunden lang an keinem fehler debugged heul :(
* iret hat keinen nachteil, es braucht nur mehr strom. da wir aber mit
unserem prozessor sowies so die WELTHERRSCHAFT an uns reisen werden, ist
das auch egal :)
Other related posts:
