Wie geht das mit der Firebee 68K Emulation?

[Arthur]

Hallo zusammen. Ich hab zwar noch keine Firebee bin aber trotzdem daran interessiert, besonders wie oder was man tun muss damit die 68K-Emulation optimal genutzt werden kann. Ich habe schon gelesen das zum Beispiel bei User A das eine Programm läuft während es bei User B nicht läuft. Welche Komponenten und TOS-Versionen sind davon abhängig und wie gut funktioniert das... bzw. wird das in Zukunft noch besser funktionieren und wo sind der Emulation Grenzen gesetzt? Ich finde das ist ein interessantes Thema das einen Thread verdient.

[Lukas Frank]

Meinst du das ->   http://vincent.riviere.free.fr/soft/68kemu/

Schau dir mal das Firebee CF Karten Image an ...

[Arthur]

Das ist schon mal ein Anfang... erklärt aber trotzdem nicht wieso bei User A das eine 68K-Program läuft und bei B nicht. Was ich auch nicht verstehe (hab ich mal hier im Forum irgendwo gelesen) ist wenn ich in irgend einen Ordner das 68KEMU.PRG kopiere und es für *.68K im Desktop anmelde... wieso es dann auch mit der Endung *.PRG funktionieren soll bzw. tut? Oder ich hab da was falsch verstanden...

[Lukas Frank]

Was meinst du denn genau?

Bei Mathias läuft nach seiner Aussage z.B. PhotoLine, bei mir läuft es nicht, weder direkt noch mit Hilfe des 68k Emus als photoline.68k ...

Meine Firebee hat glaube ich die letzten Versionen vom FireTOS etc. vielleicht hat Mathias eine neuere nicht öffentliche Version, keine Ahnung ...

Bei mir gab es keinen Fall in dem mir dieser 68k Emu irgendetwas gebracht hätte !?!

[towabe]

Ist bei mir auch so. Photoline läuft nicht. 68k-Emu bringt meist nichts

[AngelikaZ]

Dito bei mir!
Auch Chagall bekomme ich nicht zum laufen.

Irgendwie hat Matthias da eine Sonderbiene! Grmmblll!

[Mathias]

Grundsätzlich ist im FireTOS die cf68klib von MicroAPL eingebaut. Damit werden die ca 30% der 68k-Befehle die es im Coldfire nicht mehr gibt emuliert. 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.
Leider hat sich der eine Programmierer der das übernommen hat als Blender rausgestellt, und der Andere der das Wissen und die Skills hätte ist seit bald 3 Jahren unmotiviert (ich bleibe aber dran).

Vincents 68kemu ist eine ganz andere Abteilung. das ist eine "Soft-CPU" wo schlicht und einfach der ganze Prozessor emuliert wird (während die Systemaufrufe usw. native bleiben). Das ist ein Programm, und wenn man im Desktop ".68k" Programme auf 68kemu.PRG angemeldet hat, dann wird eben das Programm 68kemu aufgerufen um das jeweilige Programm laufen zu lassen. Dazu muß man aber vorher das Programm von ".PRG" oder ".APP" auf ".68k" umbenennen.

Photoline läuft mittlerweile nicht nur bei mir, sondern auch bei ein paar anderen Leuten mit 68kemu. Es bleibt aber ein kleines Mysterium warum das so ist. 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. ;-)

[Mathias]

Irgendwie hat Matthias da eine Sonderbiene! Grmmblll!

Ja, die geheime Spezialbiene mit Extraschalter "Wahnsinnige Komatibilität", die haben wir nach den ersten 3000 Verkäufen finanzieren können (Fredi mußte 17 Monate dran entwickeln), aber wir behalten das jetzt Alles strenggeheim für uns. Es gibt nur 2 dieser Spezialbienen, und eine habe ich um euch mit den Kompatibilitätsmeldungen in die Verzweiflung zu treiben!!! :-p

[Lukas Frank]

Grundsätzlich ist im FireTOS die cf68klib von MicroAPL eingebaut. Damit werden die ca 30% der 68k-Befehle die es im Coldfire nicht mehr gibt emuliert. 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 ...

Ich persönlich würde mir sowas im nächsten Jahr wünschen, ich hätte lieber eine langsame Firebee und dafür umso kompatibler ...

[Mathias]

Grundsätzlich ist im FireTOS die cf68klib von MicroAPL eingebaut. Damit werden die ca 30% der 68k-Befehle die es im Coldfire nicht mehr gibt emuliert. 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 ...

Ich persönlich würde mir sowas im nächsten Jahr wünschen, ich hätte lieber eine langsame Firebee und dafür umso kompatibler ...

Die FireBee wäre dann natürlich flotter als jetzt!
Die Problematik ist, daß wir bei so einem Task schon sehr viel Wissen brauchen. Da schrumpft der Kreis von fähigen aktiven Programmierern auf ein bis zwei Handvoll zusammen. Und wie immer sind die die wirklich was können schon so mit Arbeit oder anderen Projekten eingedeckt, daß eigentlich nichts mehr geht. Aber wer weiß, vielleicht gibt es auch noch "Externe" die sich da reinhängen würden, zu denen ich bis jetzt keinen Zugang hatte?

[mfro]

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

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.

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

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]

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

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)

Nicht um Prozessor-Inkompatibilitäten umzuschreiben, sondern um Code zur Laufzeit zu optimieren.

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?

[Lukas Frank]

Es soll doch mal Falcon kompatibel werden, wenn das so sein sollte fehlt ja noch der DSP und eventuell die ganzen Hardware Schnittstellen die so alle auf dem Board vorhanden sind ...

[Arthur]

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

Es soll doch mal Falcon kompatibel werden, wenn das so sein sollte fehlt ja noch der DSP und eventuell die ganzen Hardware Schnittstellen die so alle auf dem Board vorhanden sind ...

Also bitte, wir sind hier doch nicht bei Wünsch Dir was... nur weil es gerade so weihnachtlich ist.

[Arthur]

Grundsätzlich ist im FireTOS die cf68klib von MicroAPL eingebaut. Damit werden die ca 30% der 68k-Befehle die es im Coldfire nicht mehr gibt emuliert.

Was hilft bzw. kommen sich die Lib von MicroAPL oder der 68KEMU.PRG ins Gehege oder hat beides seine Berechtigung? Wer benutzt eigentlich noch zusätzlich das 68KEMU.PRG von Vincent?

[Mathias]

Hallo Markus!

ob die Zahlen ("Kompatibilitätsgrad"), die Du genannt hast, so stimmen, weiß ich nicht.

Ich kann das auch nicht mit Bestimmtheit sagen, aber die Zahlen stammen von Fredi und VIncent. Ich kann halt nur wiedergeben, was mit Entwickler an Infos geben. Jedenfalls war die Idee ja soweit fortgeschritten, daß ein ungepatchtes Falcon TOS laufen sollte.

Was ich aber zu glauben weiß: viel besser, als die cf68klib das heute macht, wird's wohl nicht werden.

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

Jedenfalls wäre es schön, wenn wir uns der Sache auch im Entwicklerforum wieder mal widmen (z.B. Thread Software -> Kompatiblität gelöst!) und womöglich was in die Richtung anstoßen. ;-) Auch Henks Idee des "virtual memory manager" in dem das OS dann läuft könnte man weiterdenken.

Über den JIT, oder die Idee eines "Teilweisen JIT" kann ich noch weniger sagen, weil ich nichtmal verstanden habe wie ein JIT "teilweise" klappen könnte. Aber das sollten Leute wie Mikro schon wissen, wenn sie meinen daß es "gar nicht soo kompliziert wäre".
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.


Und abschließend zu Börr noch; die Idee eines kompletten CPU-Cores im FPGA gabs natürlich auch immer schon, als zusätzliche Kompatibilitäts-Schicht. Bis uns halt die FPGA-Entwickler abhanden gekommen sind, ...

[Mathias]

Grundsätzlich ist im FireTOS die cf68klib von MicroAPL eingebaut. Damit werden die ca 30% der 68k-Befehle die es im Coldfire nicht mehr gibt emuliert.

Was hilft bzw. kommen sich die Lib von MicroAPL oder der 68KEMU.PRG ins Gehege oder hat beides seine Berechtigung? Wer benutzt eigentlich noch zusätzlich das 68KEMU.PRG von Vincent?

Du hast das grundsätzlich noch nicht verstanden. Ließ mein obiges Posting nochmal.

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.

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.

Die beiden Methoden haben natürlich NICHTS miteinander zu tun und kommen sich auch nicht ins Gehege.