Wie geht das mit der Firebee 68K Emulation?

[Arthur]

Ich versuchs auch nochmal anders. DIe cf68klib ist im FireTOS eingebaut und läuft noch vor dem Betreibssystem und fängt die Befehle die es nicht mehr gibt ab. Davon bekommt kein Programm was mit.

Alles klar...  bedeutet das jetzt auch das Festplattentreiber theoretisch problemlos laufen oder gibt es da völlig andere Probleme?

68kEMU.PRG ist ein TOS Programm. Ein kompletter CPU-Emulator. Um den zu nutzen nennt man ein belibiges ".PRG" in ".68k" um und sagt somit dem Programm 68kemu daß es das Programm xy emuliert ausführen soll. Das macht aber nur bedingt sinn, weil es langsam ist, und eben eine volle Emulation. Zum ernsthaft Arbeiten ist das aber nichts, weil es eben eine Software-Emulation ist. Da wäre Aranym oder so wirklich schlauer. Ist als Zusatz für zickige Programme gedacht, oder derzeit als einzige Möglichkeit 68k-Code mit EmuTOS zu ntuzen.

Das mit der *.68K Anmeldung hatte ich ja weiter oben, vor deinem Post, schon vermutet und erwähnt. Das die Emulation durch den 68KEMU so langsam sein soll kann ich nicht ganz nachvollziehen (der Vergleich passt vielleicht nicht ganz) da unter Magic auf dem alten Mac's mit 680x0 CPU doch auch eine 68K emuliert wurde und das Tempo abgeblich hervorragent war.

Wird eigentlich verhindert das auch CF-Code durch die cf68klib ist im FireTOS ausgeführt wird oder macht das gar nichts aus bzw. werden da irgendwelche Programm-Flags benutzt um das zu verhindern?

[mfro]

...Laut meinen Informationen ist die cf68klib schon so alt, daß sie nicht für den V4e optimiert ist, und soweit ich die anderen Entwickler verstanden habe, gibt es da schon diesbezüglich ein paar Optimierungsmöglichkeiten.

Ich weiß natürlich nicht, wo Du das her hast, aber die cf68klib, wie sie im FireTOS eingebaut ist, verwendet durchaus ISA_B-Instruktionen (und die kann nur der v4e). Meist sogar "händisch" dekodiert (dc.w xxx) - also mit Hirnschmalz -, weil manche Assembler wohl die Befehle nicht beherrschen.

Die andere Idee war ja daß der "Illegal Instruction Handler" eigentlich ins BaS eingebaut wird, und eben exzessiv mit Sprungtabellen gearbeitet wird, was dann wiederum um Häuser flotter gehen sollte als die derzeitige Konstruktion mit FreeRTOS, der cf68klib und dem TOS als task davon, ...

Das kann ich nicht nachvollziehen. Die cf68klib arbeitet bereits mit Sprungtabellen und hängt mit ihren Ausnahmebehandlungsroutinen direkt in der Vektor-Table des Coldfires (da spielt der FreeRTOS Task Switcher und die TOS-Task keine Rolle). Die meisten Fixes laufen in 5, höchstens 10 Taktzyklen und ich wüsste nicht was man da - verglichen damit, daß die Exception selbst (nur Exception + RTE) größenordnungsmäßig bereits etwa 50 Taktzyklen braucht - viel besser machen sollte. Generell ist die cf68klib meiner Ansicht nach ein Musterbeispiel an "schlauem" Coldfire-Assembler, ich jedenfalls könnte das nicht besser.

Auch ist mir noch immer nicht ganz klar wie Didiers "Pure-C patcher" funktioniert, der ja im Speicher scannt und die Programme patcht, was ja in etlichen Fällen sehr gut läuft momentan, zumindestens bei move.b xx,-(sp) wenn ich das richtig verstanden habe. Aber grundsätzlich habe ich schon den Endruck daß da Einiges gehen würde.

Das ist eigentlich ganz simpel. PureC hat eine Eigenart (damals als "Optimierung" gehandelt) um möglichst schnell ein 16-Bit-Wort mit 256 zu multiplizieren (also um 8 Bit nach links zu schieben):

Code: [Auswählen]

    move.b    d0,-(sp)
    move.w    (sp)+,d0
Das nutzt die "Angewohnheit" der m68k-Prozessoren aus, den Stack automatisch auf Wortgrenzen auszurichten, indem sie bei einem Byte-Push immer eine 0 hinterherschieben (sonst gäb's einen Adressfehler). Dem Coldfire-Prozessor ist es egal, wenn der Stack "schief" liegt (die "Korrektur" gibt's da nicht mehr), wenn man ein Byte pusht und anschließend ein Wort wieder vom Stack holt, multipliziert man mit 1 und holt zusätzlich das letzte Byte der Rücksprungadresse (die anschließend kaputt ist). Spätestens beim rts kracht's dann.

Der "Pure-C"-Patcher sucht beim Programmstart nach den von PureC geschriebenen Bytemustern dieser Library-Routine und überschreibt sie mit einem passenden "Coldfire-Ersatz". Das funktioniert aber nur für diesen speziellen Fall und paßt schon dann nicht mehr, wenn man bloß ein anderes Register verwendet (glücklicherweise macht PureC das immer gleich). Theoretisch gibt's auch hier die Möglichkeit, daß dieselben Bytemuster auch mal als Daten gebraucht werden (dann ginge das schief), aber das ist wohl bislang noch nicht passiert.

Es gäbe übrigens noch eine weitere (meines Wissens nach noch nirgends diskutierte), zumindest theoretisch mögliche Art, der Firebee m68k-Code "beizubiegen": das FPGA hängt zwischen Coldfire und "FPGA-Speicher". Würde man den als ST-RAM anmelden, müsste es möglich sein, nach Abschalten des Datencaches (mit weiterhin eingeschaltetem Befehlscache) Instruction-Fetches an den Burst-Reads zu erkennen, mit denen der Coldfire seinen Befehls-Cachelines füllt. Datenzugriffe würden am Cache vorbei stattfinden und keine Burst-Reads verursachen. Das FPGA hätte damit die Möglichkeit, Daten- und Codezugriffe auseinanderzuhalten.
Anstatt nun die Befehlsbytes einfach "durchzureichen", wie es das heute tut, könnte es den Datenstrom dann nach "m68k-only"-Befehlen scannen und entsprechend umkodieren.
Besonders schnell wär's allerdings nicht. Der FlexBus hat nur 33 MHz, die sich der Prozessor mit dem Videospeicher teilen muß, zusätzlich müsste der Data-Cache ausgeschaltet werden - wahrscheinlich kaum schneller als ein Falcon.

Das ist bei weitem nicht fertig überlegt, aber könnte eine Möglichkeit sein. Bloß: ohne FPGA-Entwickler nicht zu machen.

[Lukas Frank]

PhotoLine ist doch ein Pure-C Programm soweit ich weiss, so wie sehr viele Atari Programme ...

Wo bekommt man denn diesen "Pure-C -Patcher" her oder ist der im FireTOS eingebaut ?

[AngelikaZ]

@mfro, danke Markus, das ist sehr interessant, auch wenn ich nur eine Anwendungsentwicklerin bin und so tief noch nie drin war.

[mfro]

PhotoLine ist doch ein Pure-C Programm soweit ich weiss, so wie sehr viele Atari Programme ...

Wo bekommt man denn diesen "Pure-C -Patcher" her oder ist der im FireTOS eingebaut ?

Wie beim Metzger, wenn Du nach einem zweiten Brötchen zu deiner Frikadelle fragst:

"ist schon drin"

[Arthur]

Wie beim Metzger, wenn Du nach einem zweiten Brötchen zu deiner Frikadelle fragst:

"ist schon drin"

 

[m0n0]

Die neue Version von MyAES soll ja nochmal Optimierungen für das ausführen von SDL Applikationen beinhalten... evtl. reichts ja diesmal für Hatari, um einen normalen ST mit 8 Mhz flüssig darzustellen  ?

...und hatari soll ja laufen, und so wie ich das verstanden habe ist der Fullscreen Modus auch schneller (aber der GEM Fenster Modus dafür kompatibler und der funktioniert auch so wie er soll auf der Firebee - nur etwas zu langsam)... Gibt aber noch Probleme mit der FPGA beim Fullscreen Modus (oder anderer treibender Komponenten?), wenn das behoben wäre (und ich glaube, wenn es einen FPGA Programmierer geben würde der das kann, dann wäre das der kleinste Aufwand), dann ist die Firebee doch wohl schnell genug um einen 8 Mhz Atari mit hatari flüssig zu emulieren? Ich gehe start davon aus... Immerhin ist die Firebee rund 30x schneller... also eigentlich genug zeit pro 8mhz CPU Befehl diversen Kram abzuarbeiten, oder?

[m0n0]

Alles klar...  bedeutet das jetzt auch das Festplattentreiber teoretisch problemlos laufen oder gibt es da völlig andere Probleme?

Theoretisch Ja - praktisch gibt es da völlig andere Probleme Ich glaube im thread wurde erwähnt das 98% der möglichkeiten durch cf68klib und solche Techniken "korrigiert" werden... aber das bedeutet bei einem 100k großen Programm immer noch 2k an Querschläger Befehlen... Kann man sich bei einem Festplattentreiber dann ja ausrechnen was passiert.Aber davon abgesehen, weiss ich nicht ob der Festplattentreiber nicht auch schon seine Arbeit machen muss, bevor die m68k Emulation gestartet ist?

[mfro]

...Und das wird leider auch solange so bleiben, bis sich ein guter Programmierer hinsetzt und das rausfinden will. Und bei mir laufen schon einige Programme, die ohne 68kemu gar nicht gehen (Porthos, Texel, ...) selbst wenn VIncent es definitiv nur als Proove Of Concept betitelt, und natürlich auch da noch viel machbar wäre bei dementsprechender Motivation und Tagesverlängerungen für Vincent. ;-)

Da ist übrigens nicht besonders viel zu machen, an Vincent's Emulator. Einer der wesentlichen Gründe, warum manche Programme laufen und andere nicht, liegt darin begründet, daß der Emulator Betriebssystemaufrufe nicht emuliert, sondern 1:1 ans (Coldfire-) Betriebssystem durchreicht.

Das macht die Geschichte zwar nett flott, scheitert aber da, wo das Betriebssystem irgendwann per Callback m68k-Routinen in der Anwendung  aufruft (die dann ja wieder potentiell einen Absturz verursachen). Für den "Supexec()" Betriebssystemaufruf ist das schon gemacht, fehlt aber (noch) für VDI-Callbacks. Also beispielsweise für VDI-Erweiterungen über G_USERDEF-Objekte oder Programme, die per vex_...() eigene Maus- oder Timer-Routinen ins VDI basteln.

Das dürfte der wesentliche Grund sein, warum insbesondere "moderne" GEM-Programme abschmieren (die ihr GUI eben meist über solche USERDEF's "aufhübschen").

Was fehlt ist ein eigener VDI-Trap-Handler im Emulator, der objc_draw()-Aufrufe abfängt, dann prüft, ob gerade ein G_USEDEF-Objekt gezeichnet werden soll und wenn ja, den entsprechenden Code im Emulator abhandelt, ansonsten (Coldfire-native) im OS. Wenn der Trap-Handler dann noch gleich die vex_...()-Routinen (die werden wahrscheinlich nicht so oft benutzt) miterledigt, gibt's ein Fleißsternchen.

Das einzubauen ist nicht besonders schwierig, es muß sich nur einer (oder eine) finden, der's macht. Ich wette, dann laufen die meisten m68k-Programme, die ansonsten nicht ins OS eingreifen.