Findfirst/Findnext in Assembler

[negaH]

Tja, falsch gedacht. Das Problem bei Kylix ist das Register EBX. Auf Windows Maschinen ist dieses Register "unbenutzt" d.h. man kann es frei verwenden. Delphis Compiler hat per Definition EAX,EDX,ECX als vollständig freie Register defeiniert und EBX,ESI,EDI als teilfreie Register deren Inhalt in ASM gesichert werden muß. Register EBP ist bei ASM Sourcen der Basepointer auf eventuelle Paramter oder lokale Daten. Man kann dieses Register aber ebenfalls benutzen wenn man die Regeln beachtet.

Nun, in Kylix enthält das Register EBX die GOT = Global Object Table. Diese Tabelle ist sowas ähnliches wie das Datensegement. ALLE globalen Daten werden immer über Register EBX referenziert ! D.h. das Betriebssystem kann die Daten einer Anwendung dynamsich und zu jeder Zeit durch Änderung der GOT in EBX im Speicher veschieben. Dadurch soll das Speichermanagement des OS verbessert werden. Nun, dies stimmt auch bringt aber nicht so viel. Da nun beim Überschreiben von EBX der Zeiger auf die GOT zerstört wird wird das Program abstürtzen. Denn, auf meine Anfragen bei Borland, wie sich das Exceptionhandling von Kylix verhält wenn EBX überschriben wurde, warte ich noch heute. Da aber der Exceptionhandler selber auf die GOT in EBX angewiesen ist, würde eine Überschreiben von EBX eine Exception auslösen (im spärteren Programteilen) und der Excpetionhandler ebenfalls eine Exception auslösen usw. usw.
Somit darf EBX NIEMALS überschriben werden in Kylix. Um dies zu verhindern entschlossen sich die Borland-Programmierer das der Compiler darauf zu achten hat das EBX unverändert bleibt. Somit musste jeder Assemblersource erstmal als PASCAL vorliegen. Denn nur dann hat auch der Compiler die Gewalt darüber. Es ist also aus Zeitgründen einfacher alle Assemblerparts in PASCAL Source zu ändern. Dann kann durch Änderungen am Compiler selber das korrekte Verhalten mit der GOT besser kontroliert werden.

All diese Änderungen bewirken das in großen Teilen bestehender und guter Assembler ersetzt wurde. Da der Compiler selber auch noch schlchter wurde, ist es klar das die Gesamtperformance der Compilate darunter zu leiden hatte. Ich will hier NICHT auf die Kylix Gemeinde schimpfen o.ä. die können am wenigsten dafür. Aber es dürfte nun klarer werden was Kylix für die Windows-Gemeinde für Auswirkungen hatte.


Gruß Hagen