und ich soll auch noch einen Compiler nehmen, der wichtige Coldfire-Befehle einfach nicht nutzt und dadurch deutliche Geschwindigkeitseinbußen hat?
IMO wäre es gut wenn gcc per default für 680x0 UND coldfire kompatibel kompiliert.
Speziell optimierte Versionen sind eine gute Sache, aber da NetSurf auf so vielen Komponenten beruht und der Coldfire Prozessor sehr ungnädig mit manchen alten Befehlen ist, und es bei den meisten anderen Plattformen zugunsten der Kompatibilität gelöst ist (IMO),...
Nur scheinbar. Das ist m.E. auf anderen Plattformen, die gcc per multiarch unterstützt, genauso.
Ein Compiler z.B., der für einen x68_64 64-Bit Host gebaut wurde, erzeugt Code, der auf einem 32 Bit-Betriebssystem nichts Vernünftiges macht, solange man ihn nicht mit "-m32" dazu überredet. Das funktioniert nur andersherum: von für einen ia32-Host gebautem Compiler generierter Code läuft auch auf einem 64-Bit System. Das liegt aber nicht daran, daß der gcc da "schlauer" wäre, sondern daß Intel dafür gesorgt hat, daß der Prozessor das mit einem Kompatibilitätsmodus in Hardware unterstützt.
Bei den gefühlt Tausenden unterschiedlicher ARM Varianten ist das ähnlich, funktioniert aber nur für ganz wenige, untereinander aufwärtskompatiblen Kombinationen.
Beim gcc für m68k geht's mit Ausnahme der Coldfire-Prozessoren ja auch - ein für m68000-Host gebauter Compiler erzeugt Code, der auch auf einem 68060 noch (zwar ineffizient, aber immerhin) läuft. Beim Coldfire geht das aber nicht - der hat einerseits einen erweiterten (zusätzliche Befehle), andererseits eingeschränkten Befehlssatz gegenüber seinen "Vorgängern" (gleiche Befehle haben nur sehr eingeschränkte Adressierungsarten).
Jetzt könnte man spekulieren, ob es überhaupt eine gute Idee war, Coldfire als zusätzliche Architektur für m68k aufzunehmen und nicht möglicherweise schlauer gewesen wäre, einen ganz speziellen Compiler dafür zu bauen. Innerhalb der Coldfire-Reihe funktioniert die Auf- und Abwärtskompatibilität ja wieder.
Wahrscheinlich schon, denke ich, aber genausogut könnte man spekulieren, daß es dann vielleicht beide Plattformen beim gcc gar nicht mehr gäbe, weil die geteilte - sowieso schon kleine - Entwicklertruppe dann einfach zu klein wäre, um so was zu supporten.
bei GCC für FreeMiNT bzw. GCC für Coldfire, so ist (wobei, da müsste man noch weiter ausholen..., im NetSurf build system ist der coldfire-gcc-compiler nur durch übergabe des -mcpu=5475 Parameters dazu zu bringen das coldfire kompatibler binärcode ausgespuckt wird. Das ist natürlich beim Bauen der einzelnen Komponenten höchst kritisch. Würde der im Build System verwendete compiler default-mäßig programmecode für coldfire ausgeben, wäre das alles kein Thema, aber...
Möglicherweise könnte man dem gcc (ähnlich wie bei "m68020-60") beibringen, mit diesem sehr eingeschränkten Befehlssatz auszukommen, das müsste aber erstens jemand machen und zweitens ist das Ergebnis sehr ineffektiv und _deutlich_ langsamer.
Dein Vorschlag geht durchaus - ein Compiler der defaultmäßig Coldfire-Code erzeugt. Hat Mikro ja gezeigt, als er den GCC für den nativen Coldfire-Host gebaut hat.
Außerdem verhindert der Coldfire-Startupcode der mintlib, daß das Programm auf einem m68k überhaupt anläuft.
Stimmt so leider nicht ganz, wenn der Code in einer Library ist, wird dafür kein Check durchgeführt.
Das gilt auch für die Funktionen innerhalb der MiNTLib (ausser dem Startup Code ;-)).
Auch das ist bei anderen Plattformen nicht anders. Wär' ja auch ziemlich meschugge, wenn der gcc bei jeder neu aufgerufenen Funktion prüfen würde, ob wohl zwischenzeitlich einer den Prozessor gewechselt hat. Da muß - überall - der Programmierer darauf achten, daß er nur Dinge zusammenlinkt, die auch zueinander passen.
