Hardware > Firebee

Wie geht das mit der Firebee 68K Emulation?

<< < (3/6) > >>

mfro:

--- Zitat von: Mathias am So 21.12.2014, 15:17:14 ---... An dieser Stelle könnte man generell noch viel an der Kompatibilität schrauben, und einen eigenen 68k-Handler schreiben, der dann als Lib für TOS oder auch MiNT direkt zur Verfügung steht. Wenn man dann noch einen JIT für die ganz wenigen (2?) Fälle wo sich der CF anders als der 68k verhält dazuprogrammiert, dann wären wir bei den geplanten 95% Kompatibilität, die den Hades und Milan übertreffen würde...
--- Ende Zitat ---

Hallo Mathias,

ob die Zahlen ("Kompatibilitätsgrad"), die Du genannt hast, so stimmen, weiß ich nicht. Was ich aber zu glauben weiß: viel besser, als die cf68klib das heute macht, wird's wohl nicht werden.

Die cf68klib fängt alle m68k-Befehle, die unmittelbar eine Prozessor-Exception bewirken, ab und schreibt sie "im Flug" in Coldfire-Befehle um. Die inkompatiblen Instruktionen, die sie heute nicht abfängt, bewirken eben keinen unmittelbaren Fehler, sondern einen, der sich erst im späteren Programmablauf durch falsche Ergebnisse und mehr oder weniger mysteriöse Abstürze auswirkt.

Das Ganze wird mit einem Preis erkauft: es gibt keinen "echten" Supervisor-Mode mehr (weil die cf68klib den emuliert, um inkompatible Befehle auch im OS "zu erwischen"). In der Konsequenz bedeutet das dann eben auch: kein echter Speicherschutz in MiNT (wenn MiNT im Usermode abläuft, kann es seine Prozesse nicht so kontrollieren, wie das dazu nötig wäre).

Der angesprochene "JIT" wäre ein ganz anderes Kaliber.

Sehr viel eher zu vergleichen mit einem "aufgebohrten" Aranym. Zwar wäre es möglich, große Teile des "übersetzten" Programms als "echte" Coldfire-Anwendung laufen zu lassen, einen großer Unterschied zu Aranym gäb's aber nicht - der JIT müsste sich trotzdem jeden einzelnen Befehl "anschauen", kompatible Codestrecken eben kennzeichnen, den Rest emulieren.

Technisch nicht unmöglich, aber nicht ganz einfach. Nichtsdestotrotz ein Emulator.

Einen wesentlichen Vorteil zu einem PC mit Aranym kann ich da nicht entdecken, zumal der trotz allem sicherlich günstiger und schneller wäre, obwohl er keinen "halbwegs kompatiblen" Prozessor hat.

Gruß,
Markus

Arthur:
Da sind einige interessante Infos wobei ich jetzt nicht genau weis ob die 68K-Emulation jetzt im TOS bzw. FireTOS eingebaut ist oder durch Benutzung des von Frank verlinkten 68KEMU.PRG bewerkstelligt wird.


--- Zitat von: mfro am So 21.12.2014, 17:23:01 ---Die cf68klib fängt alle m68k-Befehle, die unmittelbar eine Prozessor-Exception bewirken, ab und schreibt sie "im Flug" in Coldfire-Befehle um. Die inkompatiblen Instruktionen, die sie heute nicht abfängt, bewirken eben keinen unmittelbaren Fehler, sondern einen, der sich erst im späteren Programmablauf durch falsche Ergebnisse und mehr oder weniger mysteriöse Abstürze auswirkt.

Das Ganze wird mit einem Preis erkauft: es gibt keinen "echten" Supervisor-Mode mehr (weil die cf68klib den emuliert, um inkompatible Befehle auch im OS "zu erwischen"). In der Konsequenz bedeutet das dann eben auch: kein echter Speicherschutz in MiNT (wenn MiNT im Usermode abläuft, kann es seine Prozesse nicht so kontrollieren, wie das dazu nötig wäre).

--- Ende Zitat ---

Zu der Problematik die Markus/mfro erwähnt hat... mit dem Supervisor-Mode Problem... würde ich sagen das die Programme die mit der 68K-Emulation bzw. Lib laufen dann einfach mit einem "68KEMU-Übersetzer" als Coldfire-gepatchtes-Programm auf der Platte gespeichert werden müssten (dann wäre das neue Binary schon Compatible) um das Problem zu beheben damit dann der 68KEMU für den Supervisor-Modus z.B. MiNT wieder normal verfügbar wäre da der EMU dann nicht immer aktiv sein müsste... ist aber nur so ein Gedanke... 

mfro:

--- Zitat von: Arthur am So 21.12.2014, 18:23:48 ---würde ich sagen das die Programme die mit der 68K-Emulation bzw. Lib laufen dann einfach mit einem "68KEMU-Übersetzer" als Coldfire-gepatchtes-Programm auf der Platte gespeichert werden müssten (dann wäre das neue Binary schon Compatible) um das Problem zu beheben damit dann der 68KEMU für den Supervisor-Modus z.B. MiNT wieder normal verfügbar wäre da der EMU dann nicht immer aktiv sein müsste... ist aber nur so ein Gedanke...

--- Ende Zitat ---

Das könnte funktionieren - nur leider kann man 68k-Programme nicht "statisch" umsetzen, weil nicht erkennbar ist, was Daten und was Programm ist. Der Emulator müsste also so lange aktiv bleiben, bis wirklich alle Codepfade mindestens einmal durchlaufen sind und das wiederum ist nicht wirklich final festzustellen (schließlich könnte immer noch irgendwo bislang als Daten betrachteter Binärcode sich plötzlich in irgendeiner speziellen Situation doch noch als Code entpuppen).

HP hat übrigens an solch einem System mit "dynamischer Laufzeit-Codepath-Analyse" jahrelang geforscht und auch einige Patente auf dabei verwendete Techniken: http://www.hpl.hp.com/techreports/1999/HPL-1999-78.pdf . Nicht um Prozessor-Inkompatibilitäten umzuschreiben, sondern um Code zur Laufzeit zu optimieren. Das Prinzip wäre aber durchaus geeignet, um 68k-Programme auf Coldfire-Prozessoren umzusetzen. Falls also jemand nicht weiß, was er die nächsten paar Jährchen so mit sich und seiner Zeit anfangen soll : nur zu! ;)

Nicht unmöglich, aber nichts was man an ein paar Samstagnachmittagen in seiner Freizeit macht.

Arthur:
Das hast Du gut erklärt... sogar ich verstehe das dies nicht mal ebend umzusetzen ist. ;o)


--- Zitat von: mfro am So 21.12.2014, 19:15:05 --- Nicht um Prozessor-Inkompatibilitäten umzuschreiben, sondern um Code zur Laufzeit zu optimieren.

--- Ende Zitat ---

Für die Alpha-CPU gabe es auch eine Compaq's FX!32 x86 Emulation wo die 32Bit Befehle zur Laufzeit von x86-Code in Alpha-Code übersetzt wurden (für Compaq Server mit NT4.0 und Alpha CPU's statt einer X86 CPU). Damals gab es ja NT 4.0 native als Alpha-Version und nur wenig native Software dafür... also fast wie auf der Biene.

Börr:
Oder einen 68k Softcore in den FPGA reinnehmen, oder ist das aufwändiger?

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete