Post by Manuel RodriguezPost by Dirk Wolfgang GlompPost by Manuel RodriguezPost by Hans-Bernhard BrökerPost by Manuel RodriguezProblem: ein simples Assemblerprogramm braucht unter DOS 10x länger
als unter Linux. Das Programm besteht aus einer Schleife die per loop-
Befehl durchlaufen wird. Innerhalb der Schleife gibt es ein printf auf
die Konsole.
Das ist nicht dein Programm, was da länger braucht, sondern die
Konsolenausgabe selbst ist in DOS+BIOS schnarchlangsam im Vergleich zur
Linux-Konsole. Das war schon zu seligen DOS-Zeiten so, und ist
heutzutage, wo niemand mehr sich drum schert, wie gut die
RealMode-Servies eines BIOS implementiert sind, sicher nicht besser
geworden.
Schon ein simples "type" bzw. "cat" einer ordentlich langen Textdatei
zeigt den Unterschied.
Man kann das bei Bedarf mit Treibern wie NNANSI.SYS radikal verbessern,
die den Job des BIOS bezüglich Bildschirmausgabe an sich reißen, und ihn
erheblich schneller erledigen.
Oder man vergisst das ganze, und kümmert sich stattdessen um wichtige Dinge.
Post by Manuel RodriguezFrage: gibt es unter DOS einen speziellen Modus um das Assembler-
Programm zu tunen, vielleicht Protected Mode oder so?
Nein. Denn das hat mit dem Assemblerprogramm an sich gar nichts zu tun.
Und Protected Mode würde es, wenn überhaupt, höchstens noch langsamer
machen.
Danke für den Hinweis; ich hab jetzt den printf-Interrupt weggelassen
und habe innerhalb der Schleife nur noch den NOP Befehl. Ergebnis: DOS
und Linux haben sich angeglichen.
DOS 70 sekunden Ausführungszeit
Linux 43 sekunden Ausführungszeit
Die verbleibende Differenzzeit könnte daran liegen dass mein DOS Code
mit Push/Pop Befehlen arbeitet um eine verschachtelte Schleife zu
erzeugen und der Linux Code nicht.
Ich dachte es wäre mit Ausnahme vom printf-Interrupt "der gleiche
Algorithmus", jetzt auf einmal nicht mehr. Was denn nun?
Post by Manuel RodriguezAnsonsten hast du natürlich Recht, dass Sterne beobachten sinnvoller
ist als handoptimierter Assembler-Code.
Diese beiden unterschiedlichen Dinge sind wohl nur schwer vergleichbar.
Post by Manuel RodriguezIch wollte nur sichergehen,
dass Linux genauso schnell arbeitet wie MS-DOS.
DOS-Anwendungen können ggf. sogar schneller sein.
Dirk
Zu "gleicher Algorithmus?"
Linux hat 32 bit Register, brauchte daher nur eine Schleife.
Linux selber hat ja eigentlich keine 32 bit Register, sondern unsere
modernen CPUs(ab 80386+) haben solche 32 bit Register...
Post by Manuel RodriguezBei DOS musste ich tricksen.
...die man ebenso unter DOS verwenden kann.
Post by Manuel RodriguezCX auf FFFF
DX auf FFFF
go1: DEC DX
JNZ go1
DEC CX
JNZ go2
Dieser Algorithmus läuft unter DOS und Linux gleichermaßn. Es wird nix
auf den Monitor ausgegen sondern nur stumm die Schleife durchlaufen.
Dos = 22 sek
Linux = 22 sek
Genauso könntest du unter DOS(RM) auch lediglich nur ecx verwenden.
Alle 32 Bit Register und auch 64 Bit MMX/128 Bit XMM -Register sind auch
dort verfügbar. Mit dem 16 Bit Adressmode, oder dem auf 64KB begrenzten
Segmenten des RM hat das rein gar nichts zu tun.
Der Unterschied zwischen dem 16 Bit-Adressmode(RM+PM) und dem 32 Bit-
Adressmode(RM+PM) ist einzig die Verwendung und Bedeutung der Registersize-
+Adresssize-Prefixe(mit oder ohne) jeweils andersherum von der CPU
interpretiert werden.
Im 16 Bit-Adressmode(RM+PM) braucht man daher jeweils ein Registersize-
+Adresssize-Prefix um der CPU mitzuteilen das hier 32 bitige
Werte/Register/Adressen verwendet werden sollen und im 32-
Bit-Adressmode(RM+PM) muss man dafür solche Registersize-
+Adresssize-Prefixe weglassen und umgekehrt.
...
Im "16 Bit-Adressmode(DOS)" gestaltet sich dieser Beispiel-Opcode um zwei
Byte länger als im 32 Bit-Adressmode(RM+PM) da hier Registersize-Prefixe
vor dem jeweiligen Opcode plaziert werden müssen:
mov ecx, 0FFFFFFFFh ; + vorangestelltes Registersize-Prefix
go:
dec ecx ; + vorangestelltes Registersize-Prefix
jnz go
Im "32 Bit-Adressmode(Linux)" lässt man diese Registersize-Prefixe weg
damit ecx verwendet wird und nicht nur cx.
Dirk