02.02.2016, 21:01
(02.02.2016, 17:26)gaor schrieb: Linuxlastig ist prinzipiell schonmal gut, etwas Anderes habe ich nämlich nicht. Aber warum wird Qemu benötigt bzw. warum reicht nicht dosbox für BCC? Gibt es da Probleme mit irgendwelchen Systembibliotheken (AIL in seg002.cpp?) auf die BCC zurückgreift?
Ich wollte nicht so ganz ins Detail gehen, aber jetzt da Du fragst:
Wenn ich an einer einzelnen Datei arbeite, benutze ich zur händischen Kontrolle DOSBox,
weil es für eine einzelne Datei so am schnellsten geht.
Für den automatischen Test mit Git dauert es mir zu lange, da mittlerweile bei jedem Commit 85 cpp-Dateien
kompiliert werden. Mit Qemu und KVM, also mit HW-Unterstützung, geht es wesentlich schneller.
Vergleich: DOSBox ~ 172s Qemu ~ 36s => Qemu ist um Faktor 4.77 schneller
Es geht sicher noch _besser_ , aber das Hauptziel ist schließlich SCHICK und nicht die optimale Toolchain.
Die Benutzung von DOSBox oder Qemu kann in einer Zeile geändert werden.
Achso, das AIL-Verzeichnis mit den Headern habe ich im Moment auch nicht eingecheckt.
Du kannst dir die AIL2.ZIP
herunterladen. Darin ist A213_D2.ZIP, daraus brauchst Du
AIL.ASM AIL.H AIL.INC AIL.MAC AIL.MAK
um seg002.cpp kompilieren zu können.
(02.02.2016, 19:37)Rabenaas schrieb: Könntest Du Dir den Vergleich nicht sparen, wenn Du die Ausgabe von objdump durch md5sum jagst, oder ist das eh nicht ganz identisch?
Ich habe gerade mal probiert mit objdump zu disassemblieren, aber mit dem Resultat bin ich nicht zufrieden,
da objdump m.W. keinen 16-Bit Code unterstützt und somit fragwürdige Listings erstellt.
An den Output von ndisasm (kann 16-bit) habe ich mich jetzt schon gewöhnt und meine Toolchain darauf aufgebaut.
Never run a changing system.
Außerdem gibt es auch Dateien, bei denen der Unterschied nur ein paar Zeilen ist.
Für diese (von mir persönlich geprüften Fälle) habe ich Ausnahmen zugelassen, on-top-of-ndisasm.