FVDI Saga Treiber für Saga Optimieren

[mfro]

wenn das eine "memory barrier" sein soll, würde ich das so schreiben:

Code: [Auswählen]

__asm__ __volatile__("" ::: "memory");
Aber nur, wenn es tatsächlich gebraucht wird - schließlich hindert das gcc ja am Optimieren.

[Thorsten Otto]

Das würde wohl nichts nutzen, weil gcc nichts von nötigen memory barriers für m68k weiss, und das genauso ignoriert würde. Wenn überhaupt, müsste man wohl einfach

Code: [Auswählen]

#define KEEP_ORDER() (void)keep_order

verwenden.

Abgesehen davon, die bisherigen Änderungen könnten den Fehler beim Bild-Spiegeln erklären, aber noch nicht die merkwürdigen Effekte in der Menüzeile. Müsste man aber wohl erstmal ausprobieren.

[mfro]

Das würde wohl nichts nutzen, weil gcc nichts von nötigen memory barriers für m68k weiss, und das genauso ignoriert würde.

Das muss es doch auch nicht. Das Statement oben bedeutet m.E. für den gcc, daß da asm-Code eingestreut wurde, der Hauptspeicher geändert hat.

Alles, was danach kommt, muß demzufolge seine Register neu laden, alles was davor kommt, sie zurückschreiben -> memory barrier.

[1ST1]

Ist das schon auf "unserer" Hardware, oder noch drüben?

[Arthur]

@tuxie, kannst du die Screenshots noch mal direkt auf forum.atari-home.de hoch laden?

Ingo, ich schieb hier mal ein wenig.

[tuxie]

Habe nur den einen und den habe ich angehaengt!

[Thorsten Otto]

@mfro: memory-barrier sind was anderes als out-of-order execution. Ersteres wird z.B. benötigt um sicherzustellen, daß Variablen die zur thread-synchronisation benutzt werden, tatsächlich im Speicher stehen. Letzteres ist was, was lediglich die CPU betrifft. Da sowohl mit dem bisherigen Konstrukt und mit deinem Vorschlag (oder auch wenn man es ganz weglässt) der gleiche Code erzeugt wird, kann es hier allerdings keinen Effekt haben. Es gibt lediglich einen Unterschied: wenn man es ganz weglässt, wird tatsächlich die Funktion für EXPR_NOP komplett wegoptimiert. Wenn man eines der Konstrukte benutzt, besteht die aus Schleifen die absolut keinen Effekt haben, weil sie weder Speicher lesen noch schreiben.

@tuxie: welchen Compiler verwendet ihr denn bzw. die Amiga-Leute? ich weiss daß Beppo da schon was Richtung Apollo-Code-Erzeugung gemacht hat, aber ist das auch schon im Einsatz?

[Nervengift]

Mal nebenbei: Vielleicht kann @Chocco euch noch helfen? Der schreibt zur Zeit ein VDI für Linux/ARM.

[mfro]

@mfro: memory-barrier sind was anderes als out-of-order execution.

Natürlich.

Mit letzerem werden m68k-Compiler (und erst recht "Legacy"-Code) schlicht nicht umgehen können. M.E. darf der Apollo-Core so etwas nur dann machen, wenn es keine Auswirkungen auf das Ergebnis hat.

M.W. macht auch ein 68060 - obwohl er "die Kraft der zwei Pipelines" hat - immer in-order. ColdFire genauso.

[tuxie]

Ich nutze aktuell den Compiler von Vincent auf meinem MacBook, hatte jetzt versucht den GCC 8 von Thorsten einzurichten, es fehlt allerdings noch ein Paket ein -as fehlt. Habe aber gestern Abend dann nicht weiter geschaut.

Die nonarkitten aus dem Apollo Team die auch die Blit Routinen geschrieben hat, hat mir auch schon gesagt das Beppos Compiler den 68080 bereits Unterstützt. Nur die Frage wie man ihn am besten einbinden könnte.

[tuxie]

Hab ihn eben gefunden, er hat ihn auf Github

https://github.com/bebbo/amiga-gcc

[Thorsten Otto]

es fehlt allerdings noch ein Paket ein -as fehlt.

Der Assembler? Sollte eigentlich bei den binutils dabei sein (ist es auch wenn ich nachschaue). Zur Not müssten aber auch die binutils-2.30 von Vincent funktionieren.

[quoteNur die Frage wie man ihn am besten einbinden könnte.[/quote]

Hauptproblem ist vermutlich, daß er momentan noch vasm verwendet, und gas noch nicht die opcodes versteht.

[tuxie]

Schaue ich heute Abend, bin Arbeiten und habe heute meinen Rechner nicht mit.

[Chocco]

Mal nebenbei: Vielleicht kann @Chocco euch noch helfen? Der schreibt zur Zeit ein VDI für Linux/ARM.

Nein, das passt leider nicht ganz. Für den ARM-Port habe ich mich inzwischen vom Framebuffer getrennt und nutze openvg mit HW-Beschleunigung.

Augenscheinlich würde ich auf vro_cpyfm() tippen, wenn sowohl SCR- als auch DST-Raster im aktuellen Bildspeicher liegen. In diesem Fall wird NULL als Zeiger auf das Raster gesetzt und vielleicht werden die MFDB-Strukturen mit inkorrekten Default-Werten belegt.

[tuxie]

Wie ist den da eigentlich der Status bei deinem Port ?

[Chocco]

Wie ist den da eigentlich der Status bei deinem Port ?

Das ist noch eine große Baustelle. Dazu mache ich mal einen extra Thread zu auf.