Software > Software (16-/32-Bit)
NetSurf GEM Alpha
mfro:
--- Zitat von: Mathias am Do 13.08.2015, 19:45:11 ---...
Nur der Vollständigkeit halber; das ist die Vorgangsweise bei gcc. AHCC wiederum erzeugt Programme die auf 68020 bis inkl. ColdFire laufen. Ein Ansatz den ich für verfolgenswerter halte. Ich kann aber auch verstehen warum Vincent die Optimierung für jede CPU bevorzugt.
--- Ende Zitat ---
Jetzt haben wir noch nicht mal die von Freescale versprochenen 401 VAX-MIPS hingekriegt und ich soll auch noch einen Compiler nehmen, der wichtige Coldfire-Befehle einfach nicht nutzt und dadurch deutliche Geschwindigkeitseinbußen hat? Kommt nicht in die Tüte. >:D
Ernsthaft: der AHCC ist ein nettes Werkzeug, aber daß er es schafft, NetSurf fehlerfrei zu compilieren, halte ich für ausgeschlossen. Das ist (mindestens) eine Nummer zu groß für den.
m0n0:
--- Zitat ---und ich soll auch noch einen Compiler nehmen, der wichtige Coldfire-Befehle einfach nicht nutzt und dadurch deutliche Geschwindigkeitseinbußen hat?
--- Ende Zitat ---
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), stellt sich auch die Frage, warum das nicht, 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... leider ist das nicht über Standardmechanismen in GCC für FreeMiNT/Coldfire möglich, soweit ich das verstanden habe..., in GCC Compilern ffür andere Plattformen funktioniert es wohl, weil kein so exotischer Weg wie beim FreeMiNT/Coldfire GCC genommen wurde...).
--- Zitat ---Außerdem verhindert der Coldfire-Startupcode der mintlib, daß das Programm auf einem m68k überhaupt anläuft.
--- Ende Zitat ---
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 ;-)).
mfro:
--- Zitat von: m0n0 am Fr 14.08.2015, 01:29:23 ---
--- Zitat ---und ich soll auch noch einen Compiler nehmen, der wichtige Coldfire-Befehle einfach nicht nutzt und dadurch deutliche Geschwindigkeitseinbußen hat?
--- Ende Zitat ---
IMO wäre es gut wenn gcc per default für 680x0 UND coldfire kompatibel kompiliert.
--- Zitat von: m0n0 am Fr 14.08.2015, 01:29:23 ---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),...
--- Ende Zitat ---
--- Ende Zitat ---
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.
--- Zitat ---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...
--- Ende Zitat ---
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.
--- Zitat ---
--- Zitat ---Außerdem verhindert der Coldfire-Startupcode der mintlib, daß das Programm auf einem m68k überhaupt anläuft.
--- Ende Zitat ---
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 ;-)).
--- Ende Zitat ---
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.
Mathias:
--- Zitat von: mfro am Fr 14.08.2015, 00:38:28 --- Jetzt haben wir noch nicht mal die von Freescale versprochenen 401 VAX-MIPS hingekriegt und ich soll auch noch einen Compiler nehmen, der wichtige Coldfire-Befehle einfach nicht nutzt und dadurch deutliche Geschwindigkeitseinbußen hat? Kommt nicht in die Tüte. >:D
--- Ende Zitat ---
Hihi! ;)
Ja, ich sag ja ich kann VIncent schon verstehen. Ich hab ja beispielsweise auch blöd geschaut um wieviel flotter Highwire für den 040er optimiert, dann am Hades gelaufen ist im Gegensatz zur "normalen" Version.
--- Zitat von: mfro am Fr 14.08.2015, 00:38:28 ---Ernsthaft: der AHCC ist ein nettes Werkzeug, aber daß er es schafft, NetSurf fehlerfrei zu compilieren, halte ich für ausgeschlossen. Das ist (mindestens) eine Nummer zu groß für den.
--- Ende Zitat ---
Davon war ja nie die Rede Netsurf mit AHCC zu kompilieren! Ich wollte nur generell anmerken, daß es grundsätzlich geht, weil 1ST1 so verwundert war. Denn wenn es gar nicht funktionieren würde, hätten wir ja tatsächlich einen PPC nehmen können ;)
mfro:
--- Zitat von: Mathias am Fr 14.08.2015, 09:15:49 ---...Denn wenn es gar nicht funktionieren würde, hätten wir ja tatsächlich einen PPC nehmen können ;)
--- Ende Zitat ---
Da unterschlägst Du die cf68klib. Die gibt's für den PPC nicht (und kann's in der Form auch gar nicht geben).
Nicht alles durcheinanderwerfen. "Code für m68k _und_ Coldfire erzeugen", "illegale m68k-Befehle in der cf68klib abfangen und korrigieren" und "eine m68k-CPU auf einer anderen Prozessorarchitektur emulieren" sind prinzipiell völlig unterschiedliche technische Herangehensweisen.
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln