Performance Vorteil gcc -m68000 oder -m68030

[tuxie]

Hallo,

es sind ja auch einige hier an board die sich auch mit 68k-gcc auskennen. Würde das Programm welches ich Kompiliere (ist eine große Anwendung) mit dem compilersetting -m68030 schneller laufen als mit m68000 oder macht das keinen Unterschied ? Weil ich kann mir vorstellen das es da von den befehlen her einen Unterschied gibt. Rechner der es dann ausführen soll ist ein Atari TT.

 

[Arthur]

Probier es einfach aus...

[tuxie]

Halt sehr aufwendig da ich es jedesmal in Roms packen muß

[Arthur]

hängt aber stark vom Programmcode ab. Auf der anderen Seite weißt Du nicht ob der Aufwand sich dafür aber lohnt. Um was geht es denn dabei?

[tuxie]

Ok,

also ich habe mir EmuTOS ins Rom gebrannt und bin am Testen was machbar ist und was nicht. Also habe ich mir dazu die Quellen geladen und beim durchschauen der Quellen ist mir aufgefallen das EmuTOS mit -m68000 compiliert wird. Also hab ich das jetzt mal auf -68030 gesetzt und neu Compiliert und ins Rom gebrannt. Resultat sind rund 4% mehr Leistung auf der VDI Seite ohne jetzt noch irgendwelche Optimierungen machen zu müssen. Der Tos selbst ist auch ein Stück kleiner geworden dadurch. Davon abgesehen das es immernoch rund 5% langsamer ist als ein Tos3.06 (ohne NVDI) macht es schon spaß einfach so zu Arbeiten ohne HDDriver installieren oder laden zu müssen. Die Partitionierten geräte sind einfach da
 

[1ST1]

Unterstützt denn EMU-Tos alle Hardware-Komponenten des TT? Sprich die erweiterten Grafikmodis, DMA-Sound, SCSI, zusätzliche serielle Schnittstellen, etc?

[tuxie]

Bis auf SCSI alles ja..

[mfro]

... Würde das Programm welches ich Kompiliere (ist eine große Anwendung) mit dem compilersetting -m68030 schneller laufen als mit m68000 ...

Das *würde* wahrscheinlich einen Unterschied machen, wenn Du nicht mit -mshort (also 16-bit ints) compilieren würdest.
Dann könnte der 68030 beim Array-Zugriff mit seinen "langen" Adressierungsarten "punkten", die's beim 68000 nicht gibt. So kann er das nur, wenn Arrays explizit mit LONG-Indizes angesprochen werden (kommt in EmuTOS meiner Kenntnis nach so gut wie nicht vor). Seine Bitfield-Instruktionen darf er auch nicht benutzen (muß man beim gcc extra einschalten und auch dafür gibt's im EmuTOS so gut wie keine Verwendung).
Ich bin fast ein wenig verwundert, daß überhaupt 4% Gewinn rauskommen. Ich denke, daß kommt im Wesentlichen daher, daß die gcc-Hilfsroutinen für 32-bit Multiplikationen nicht mehr aufgerufen werden müssen.

Ich könnte mir sogar vorstellen, daß -Os mehr bringt. Wenn der Compiler auf Codegröße optimiert, steigt die Wahrscheinlichkeit, daß Schleifen noch in die (mickrigen) 68030-Caches passen.

[tuxie]

Also ohne das -mshort läuft emutos nicht, da kommt gleich eine Error Exception, aber mit Os läuft es, ja an sowas hatte ich auch schon gedacht. Wie gesagt mit -m68030 ist es etwas schneller, 4% ist natürlich nicht viel. Der VDI Teil müsste wirklich optimiert werden im Emutos, ich schätze wenn das sich ein Programmierer ran setzt der davon mehr versteht wie ich dann würde daraus wirklich eine Alternative auch für Reale Hardware.
Will mal sehen das ich die nächsten Tage die hässlichen Desktop Icons tauschen kann. bzw. sollte gar nicht so das große Problem sein.

[mfro]

... Der VDI Teil müsste wirklich optimiert werden im Emutos, ich schätze wenn das sich ein Programmierer ran setzt der davon mehr versteht wie ich dann würde daraus wirklich eine Alternative auch für Reale Hardware...

das EmuTOS-VDI ist schon recht gut optimierter C-Code. Wenn man da ungeschickt dranfaßt, wird das gern mal eben halb so schnell...

Das Atari-VDI ist schneller, weil es für jede Auflösung und Farbtiefe separate, optimierte Assembler-Routinen (zumindest für die wichtigsten Grafikprimitive wie horizontal_line und Rasterkopien) bereitstellt. In EmuTOS ist das eine Funktion, die alle ST- und TT-Auflösungen mittels Fallunterscheidung auf einmal erschlägt.

Das Bitgefummel mit den interleaved Bitplanes ist für einen C-Compiler nicht unbedingt ein vielversprechendes Betätigungsfeld.

Optimierte Assemblerroutinen sind nicht das Ziel von EmuTOS. Der Code soll so weit wie möglich portabel und verständlich bleiben. Für den, dem das EmuTOS-VDI zu langsam ist, läßt sich seit einiger Zeit NVDI installieren.

[tuxie]

Das verstehe ich schon das EmuTOS ein Variables OS sein soll für verschiedene Systeme und damit auch recht Universal.. Auf der anderen Seite wäre es eine gute Alternative zu TOS selbst besonders im Bezug bestimmter Features wie z.b. kein Festplattentreiber Notwendig oder Automatischer Erkennung und Einbindung verschiedener Erweiterungen wie z.b. der Monster von Alanh. Aber damit es eine sinnvolle Alternative zum Standard Tos ist fehlen halt einiges an Optimierungen, klar kann ich NVDI nachladen und damit ist es auch fast so schnell wie Normal Tos. Ich habe bei Roger und auch Vincent ein paar Anregungen eingebracht und so wie ich es verstanden habe sind sie auch gern bereit sobald die neue Version raus ist einige Optimierungen umzusetzen.