Es gibt einige Stellen mit #if 0, wobei das vermutlich alte Code-Stücke sind, wo sich jemand nicht sicher war, ob sie vielleicht doch einen Sinn haben.
Makros, auch längere, sind nicht von sich aus schlimm. Was wäre denn die Alternative? Auch die Länge von Funktionen ist kein Kriterium. Wenn in einem Switch viele Fälle vorkommen, wird die Funktion nun mal lang. Klar kann man auch jeden Switch Fall in eine eigene Funktion verfrachten, aber wird davon das Ganze übersichtlicher?
Ich weiß, man kann sich über so was streiten, es handelt sich immer um meine Meinung/Erfahrung. Achtung, manchmal bin ich etwas extrem in meinen Aussagen
.
Meiner Meinung nach verwirren solche Abschnitte und gehören gelöscht. Zu was gibt es Revisionssystem. Wie es aussieht hat jemand mal die ARM-Datei kopiert und dann angepasst. Meine Vermutung.
Nein, Makros sind nicht schlimm, ich finde sie erschweren nur eine späteres Review. Ich würde für die verschiedenen Fälle Funktionen schreiben und passend benennen (mono_mips_addint32_n32, mono_mips_addint32_o32, ...). Das verkürzt das #if, und der Compiler löscht die tote Funktion.
Lange Switch-Anweisungen lassen sich manchmal nicht vermeiden, doch sollte man in solchen Anweisung Codeblöcke/Fälle die viele Zeilen haben vermeiden, damit man es nicht noch mehr in die Länge zieht. Gibt es im vi codefolding? Das nutze ich dann meist, um es kürzer zu halten (bsp.:
NextToken).
Die Optimierung -Os bedeutet zumindest beim GCC, dass auf Größe optimiert werden soll. Da ist das Einbetten von Funktionen eher kontraproduktiv, da kann man dem GCC nicht vorwerfen, dass er es nicht tut. Wenn man statt dessen auf Geschwindigkeit optimiert, wird einiges verschoben, eingebettet, ausgerollt usw. Das Programm wird dann eben auch größer. Und ich kann mich nicht erinnern, dass GCC bei eingeschalteter Optimierung, ob für Größe oder Geschwindigkeit, Werte von einem temporären Platz zu einem anderen kopiert hat.
Kann ich schon
. Die Funktion wird genau einmal gerufen, ein einbetten würde den Code verkleinern, da der Stackframe gespart werden kann. Ach, Optimierung ist ein schönes Thema ... wird aber ein bisschen zu OffTopic. Für die Diskussion brauch ich ein Bier
.
Ich würde emacs statt vi nehmen, und make hat nur mit der Übersetzung und nicht mit der Entwicklung zu tun. Sinnvollerweise sollte man vorher einen Überblick haben, wie das Programm arbeiten soll.
Ich bin enttäuscht, vi hab ich wenigstens vor 10 Jahren viel mit gemacht. emacs hab ich irgendwie keinen Zugang zu. Wie schafft man sich den Überblick, ohne Code zu markieren, Definitionslisten, Calltree's ... . Gibt es nichts komfortableres? Bin leider über die Jahre durch Borland Pascal/Cpp, Delphi, VS etwas verweichlicht
*. Gerade wenn man fremden Code bearbeitet finde ich solche Werkzeuge extrem praktisch und zeitsparend. Denn man muss sich ja erstmal den Überblick verschaffen, und da ist schön wenn man ein wenig mit den Code spielen kann?
Btw. keine Sorge ich hab schon einiges zusammengebaut, auch auf exotischer Hardware, make hab ich früher auch oft eingesetzt. Verwende ich aber auch seit langem nicht mehr.
vielleicht kann man mit jemanden aus dem MONO Team Kontakt aufnehmen? Vom Gefühl her sind wir ja schon einige Schritte weiter gekommen. Selbst ein Hello World klappt schon.
Wie ich bei meinen vorherigen Recherchen gesehen habe, gibt es keinen Maintainer bzw. keinen den es Interessiert und die Aufnahme ist meiner Meinung nach erst möglich wenn man Seiteneffekte ausschließen kann. Das werde ich nicht leisten können. Fehlt mir einfach die Hardware und Zeit.
So, wie ich das Überblicke ist die Mips-Architektur ein ziemliches Sammelwerk an verschiedensten Konfiguration und es wird schwer sein jemals alle zu unterstützen.
Es wäre schon schön, wenn man mit dem Urheber reden könnte, aber ich denke das bleibt ein Wunsch. Da sind wir wohl auf uns gestellt.
Zum Thema:
Ich werde so wie es die Zeit zulässt daran weiter arbeiten, dass es hoffentlich irgendwann sauber funktioniert. Das wird aber wohl in den nächsten Monat nicht werden. Erstens ist Sommer, zweitens muss ich noch beruflich ein Projekt durchbringen.
Es ist furchtbar spannend für mich, da ich etwas von der low-level Entwicklung abgekommen bin und zur Zeit immer komplexe Systeme verwalten muss, und eigentlich hab ich vor vielen Monden so mal angefangen.
* Ich bin kein Maus-Schuppser, es gibt ja Kurztasten. Aber gerade für Codereviews finde ich es angenehmer, via Maus und vielen Fenster sich durch zu wühlen. Auf dem Wischschirmen müssen Sie aber noch ein bisschen fein tunen.
