Leon3 c Code Optimierung und Messung

[hellmaster (Gast)]

Hallo Zusammen,

Ich bin gerade an meiner Diplomarbeit dabei für einen FPGA ein 
Laufzeitsystem zu implementieren, welches die Rekonfiguration des FPGA 
steuert. Meine Software läuft unter Linux und ist in C programmiert. 
Leider läuft diese nicht schnell genug. Richtig messen konnte ich bisher 
nicht, da die clock_res() = 10 Millisekunden sind und Teile meines 
Programms nur 0.5 - 1.5 Millisekunden brauchen dürfen. Hat der Leon3 
irgendwelche Timer Register, welche ich unter Linux auslesen kann, da 
weder gettimeofday, noch clock() etwas bringt? Die Auflösung ist immer 
zu hoch. Gibt es Optimierungen beim GCC die speziell für Sparc bzw. 
Leon3 sind. Was sollte ich beim Programmieren beachten, dass meine 
Software schneller ausgeführt wird. Kleine Funktionen "inline" 
kennzeichnen bzw. Variablen mit "register variable". Wie sieht es mit 
signed vs unsigned aus?

Danke schonmal

[Uwe (Gast)]

> Hat der Leon3 irgendwelche Timer Register
Du hast den doch zusammengebastelt.
Woher sollen wir denn wissen ob du da Timer reingemacht hast ???

[coca (Gast)]

Glaube gptimer unit oder so heisst der IP Core der GRLIB, die sollte man 
mit in den SOC packen und initialisieren; im 1ms Bereich sollte man dann 
genau messen können. Ist natürlich von deiner taktPower, quartz, ISRs, 
usw.  abhängig. Spontan würd mir noch die alternative Port Pin Messung 
einfallen.

Ist ein Betriebssystem nicht eine Laufzeitumgebung, sprich linux ? , 
whatever ...

Gaisler bietet ein gcc cross compiler + Toolchain(bcc), von der Sache 
mit allem was das Herz begehrt :D

Für Geschwindigkeit würd ich den LEON3 Instruktion- Data Cache auf max, 
fahren + geeignetem caching Algorithmus parametriern, alles im LEON3 
core vorhanden.

Zu unsigned würd mir spontan einfallen, das bei hex Operation zu 
benutzten 1 byte [0 - 255] uint8 = unsigned char. wein ein char 1 Byte 
ist.
zu signed ... brauch man quasi nicht schreiben, char = signed char.
Beispiel: mit einem Byte zählen: signed char Int8 [+128/ -128 ]  oder 
ASCI Byte gespiele.

Speicherkonzept ist auch eine gute Idee für eine Laufzeitumgebung. Stack 
und Heap sollten man je nachdem beachten. Als Hinweis der SPARC hat eine 
Art stack-Revolver mit 8 Registerspeicher, bei Kontext-wechsel, vor oder 
zurück, kann er bisschen was auf dem Prozessor nahen Stack parken und 
somit schneller sein, weil es nicht aus dem RAM nachgeladen werden muss.

MMU, wenn mehr als ein Prozess involviert ist gilt es zu beleuchten.

Inline würd ich im Zeikritischen Fall empfehlen, so schafft man mehr 
Übersicht im Code  und weniger Sprünge/Kontextwechsel, vielleicht :P Bei 
einem Low Level Timer Treiber würd ich damit zB arbeiten.