Hardware > Firebee

Wie geht das mit der Firebee 68K Emulation?

<< < (5/6) > >>

Arthur:

--- Zitat von: Mathias am Mo 22.12.2014, 15:43:51 ---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.

--- Ende Zitat ---

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


--- Zitat von: Mathias am Mo 22.12.2014, 15:43:51 ---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.

--- Ende Zitat ---

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:

--- Zitat von: Mathias am Mo 22.12.2014, 15:34:26 ---...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.

--- Ende Zitat ---
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.


--- Zitat von: Mathias am Mo 22.12.2014, 15:34:26 ---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, ...

--- Ende Zitat ---
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.


--- Zitat ---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.

--- Ende Zitat ---
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: ---    move.b    d0,-(sp)
    move.w    (sp)+,d0

--- Ende Code ---
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:

--- Zitat von: Lukas Frank am Mo 22.12.2014, 18:09:31 ---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 ?

--- Ende Zitat ---

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

"ist schon drin" ;)

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete