Schnelligkeit von C-Code

ein zustand in dem man vollen zugriff auf die hardware hat und sehr wenig speicher ansprechen kann. 64kiB oder 1MiB, weiß ich jetzt grad nicht.
wird vom betriebssystem soweit ich weiß komplett gesperrt.

dachschaden weiss garantiert zu 100% was Real Mode bedeutet
mir auch zu 100% klar was Real Mode bedeutet - und ich habe diesen auch mit dem Watcom schon vor 24 Jahren programmiert, und mit Turbo/Borland C, Microsoft C, Paradigm C - weit vor der 32 Bit Zeit - jetzt eben nur noch ein paar (Sicherheits)Ringe drüber - und mit anderen Kompilern und Betriebssystemen

das betriebssystem ist aber nicht dos und die cpu ist auch kein pentium pro.

das ist völlig irelevant - out und mov haben sich seit dem 8088 nicht geändert - wie du auch am 32/64bit Opcodes des GCCs sehen kannst

aber stell doch einfach die richtigen Parameter ein und sieh das es das bessere Ergebnis null verändert

und ob DOS oder Windows ist für die Code-Generierung auch völlig irelevant - nur das Exe-Image sieht leicht anders aus - was nicht bedeutet das du es ausführen kannst - aber der generierte Code ist mehr oder minder der selbst - auf jeden Fall aus Geschwindigkeitssicht

ausserdem müsste es DOS sein - oder wie nutzt du denn sonst out ohne Ring 0 Execptions zu bekommen?

386ex embedded übertragen...

Achso - also eben kein DOS sonder was eigenes was eben im Real-Mode betrieben wird
also wäre die CPU schon mal ein 386ex - was ist dann dein Target-OS - oder erzeugt ihr nur obj und kombiniert die irgendwie fuer das embedded 386ex OS?

Ist ja nicht so das ich mich damit nicht Auskennen würde

wie dem auch sei: wenn ich daran denke, compiliere ich es gerne noch einmal mit optimierung und messe die frequenzen erneut. ich bezweifle aber, dass diese kleinen kniffe, die der compiler da anwendet bei einer cpu mit 30MHz so stark ins gewicht fallen, dass aus 120kHz ausgangssignal plötzlich 300kHz oder noch mehr werden.

wieso nur "ins Gewicht fallen"?

der C-Code ist was die Zyklenanzahl angeht definitiv schneller als der Inline-Assembler-Code - ob 1% oder 500% ist völlig egal - es geht darum das deine Aussage bezüglich der Optimierbarkeit durch Inline-Assembler (bei diesem Beispiel) falsch ist weil der original C-Code mit Optimierung einfach nicht weiter optimiert werden kann - er ist schon optimal und schneller

Sorry ist gerade so interessant

Zustand:

1. du hast ein 386ex embedded System das mit einem eigenem Betriebssystem(oder nur Loader?) im Real Mode läuft d.h.
du kannst 16 Bit Speicher Addressierung (Seg:Ofs) und 16/32 Bit Code wegen dem 386ex ausführen (ihr habt nur eben keinen 32Bit Code - technisch geht es aber)

2. dein C- und Inline-Assembler-Beispiel enthält nur Befehle die schon auf dem 8088 vorkommen sind und für die es auch keine 32 oder 64 Bit Varianten gibt
d.h. der Opcode kann keine Pentium oder sonstige Optimierungen enthalten weil die Befehle dort einfach gleich sind

3. Es ist egal ob ich für den 386, Pentium Pro, DOS, Windows, Linux oder sonstwas mit einem x86 konformen Kompiler kompiliere - es wird in allen Fällen 16-Bit oder 32bit Opcode erzeug
der so direkt auf deinem 386ex Target ausgeführt werden kann - der Opcode ist zu 100% konform zu den Anforderungen deines 386ex
z.B. erzeugt der gcc 6.2 (aktuell von dieser Woche) den absolut gleichen (bis auf 32Bit Registernutzung - der keinen Geschwindigkeitunterschied zum 16Bit Code aufweist) Code wie
dein alter Watcom wenn man ihn ohne/mit Optmierung kompilieren lässt

4. Es ist klar das du den gcc oder clang so direkt nicht nutzen kannst (wolltest)
damit will ich nur aufzeigen das aktuelle Optimizer für dieses trivial-Beispiel den gleiche Code erzeugen
wie es dein optmierender Watcom macht

5. Weil du einen besonderen Loader in deinem 386ex hast kann man eben keine DOS, Windows oder Linux "EXE" ausführen - aber ich könnte den Opcode einfach von
Hand in dein Target patchen (oder in die Ausgangsdatei) und es würde definitiv laufen

6. Ihr habt scheinbar aus Unwissenheit einfach vergessen die Optmierung zu aktivieren (was in der Industrie/Branche höchst schändlich wäre)
und vergleiche Angestellt die so einfach keinen Sinn ergeben - und euer Professor hat scheinbar kein Problem damit euch Falschwissen zu vermitteln
Hier wurde aus den falsche Gründen ein sog. AGM - Assembler-Geschwindigkeits-Mythos erzeugt

7. Es könnte sein das auch andere Projekte von euch, die viel größer sind, genau nach diesem Schema gebaut werden und einfach um ein vielfaches langsamer sind als sie sein könnten
- bei deinem trivialen IO-Beispiel kann der Optimizer nicht so viel erreichen (immerhin besser als der Inline-Assember ist er schon mal)
bei größeren Codemengen hat der Optimizer viel mehr Auswirkung auf die Geschwindigkeit - ganz zu schweigen von Floating-Point Operation (die ihr aber wegen höchst wahrscheinlich fehlendem x87 nicht nutzt) usw.

8. Es gibt natürlich Fällen in denen Assembler heutzutage Einsatz findet - schau dir z.B. nur mal den Bignum/GMP Code an da ist viel Assembler drinn

Fragen:

1. welche Watcom Version ist es denn jetzt? (wcl -v auf der Kommandozeile)
2. welche Platform Version vom Watcom nuttz du (DOS, Windows, 16,32,64 Bit) - also von welcher Art ist deine wcl.exe
3. wie sieht genau deine wcl-Parametrisierung aus damit das richtige Ergebnis für dein embedded 386ex Target rauskommt
4. wie bekommst du dein Kompilat auf den 386ex - gibt da noch einen Load- oder Umwandlungsprozess für die obj-Datei oder EXE?

so könnte ich es bei mir nachbauen
oder du stellst die Daten die auf deinen 386ex kommen hier rein - dann kann ich mir die mal anschauen und verstehen wie dein Loader funktioniert

osdt

dachschaden schrieb:

L$1:
mov dx,0x0001
mov ax,0x0338
call outp_
xor dx,dx
mov ax,0x0338
call outp_
jmp L$1
Die einzigen Unterschied sind, dass statt out als Instruktion outp_ als Funktion aufgerufen wird, und dass statt ein mov ein xor generiert wird. Die Frage ist, warum der Compiler denn sowas tut - oder anders, wenn outp_ langsamer ist als die Instruktion, warum er dann nicht out direkt verwendet.

Sehr wahrscheinlich handelt es sich um eine 'normale' C Funktion. Dem Compiler ist nur die Deklaration bekannt, nicht die Implementierung. Inline Funktionen gibt es erst seit C99 und ich glaube nicht, dass der Compiler das unterstützt.

Sehr wahrscheinlich handelt es sich um eine 'normale' C Funktion. Dem Compiler ist nur die Deklaration bekannt, nicht die Implementierung. Inline Funktionen gibt es erst seit C99 und ich glaube nicht, dass der Compiler das unterstützt.

Falsch - der Open Watcom unterstützt inline schon sehr sehr lange
und wenn man die Optimierung aktiviert wird die Funktion auch ge-inlined - so wie man es erwartet

da es scheinbar Probleme gibt die einzelenen Kompilerergebnisse zu unterscheiden führe ich sie hier einfach mal alle auf
ich erzeuge nur obj-Dateien und machen keine Verweise auf PentiumPro, DOS oder gcc - das scheint ja nur zu verwirren (bis auf die 32Bit-Register Nutzung beim gcc besteht die relevante Funktion immer aus 8086 Opcodes)

mit dieser compile.bat (http://hastebin.com/efuzogucor.tex) Batch-Datei wird aus der Aufgabe21.c (http://hastebin.com/ilinixeqov.vala) 3 verschiedene Objektdateien (fuer 8086) mit unterschiedlichen Optimiereinstellungen erzeugt
dazu gehören (OhneParameter, HansKlaus und MitOptimierung) - genau Einstellungen für diese sind aus der compile.bat zu ersehen
und der inline-Assembler aus Aufgabe22.c (http://hastebin.com/fowekavuto.cs)

verwendeter Kompiler: wcl -v
Open Watcom C/C++ x86 16-bit Compile and Link Utility
Version 2.0 beta Aug 26 2016 05:40:13 (32-bit)

mit dem IDA 6.5x analysiert ergibt sich für die obj-Dateien folgendes Bild

Aufgabe21.OhneParameter.obj (http://hastebin.com/ininepezan.tex)
Aufgabe21.HansKlaus.obj (http://hastebin.com/ozireqezor.tex)
Aufgabe21.MitOptimerung.obj (http://hastebin.com/areyosanul.tex)
Aufgabe22.obj (http://hastebin.com/ibuwoyeyiz.tex)

man sieht deutlich:

Aufgabe21.OhneParameter.obj und Aufgabe21.HansKlaus.obj sind identisch, es ist keine Optimierung enthalten - keine inlining von Funktionen usw.
d.h. der Parameter -ot hat in diesem Beispiel keine Auswirkung (daher auch die gleichen Ergebnisse)
und Aufgabe22.obj ist locker um ein vielfaches schneller

Aufgabe21.MitOptimerung.obj ist besser optimiert als Aufgabe22.obj - wenn man nur die richtigen (und in allen aktuellen Kompiler Standard sind wenn Optimierung aktiviert wird)
Optimierparameter verwendet - klar sind das jetzt keine riesigen Sprünge mehr gegenüber dem inline-Assembler aber zeigt eben auf das der inline-Assembler hierfür keinen Vorteil bringt

jetzt wäres es interessant was dein Watcom mit den MitOptimierung-Parametern erzeugt und falls die Ergebnisse identisch sind würde
ich immer noch gerne Wissen warum ihr solche Unfug-Vergleiche machen müsst (deine Erklärungen bezogen sich auf alles danach nur nicht auf dieses Beispiel) - gerne auch direkt von der Person von der die Aufgabe kommt

Ganz Wichtig:
falls Aufgabe21.MitOptimerung.obj gleich schnell oder schneller als Aufgabe22.obj ist muss du dich leider in aller Form für die Verbreitung eines Assembler-Geschwindigkeits-Mythos im Internet entschuldigen

So in der Form denke ich wäre genug der Buße:
"Meine Nickname ist HansKlaus und ich habe einen Assembler-Geschwindigkeits-Mythos im Internet verbreitet, ich war unerfahren, kannte den Kompiler nicht und mein Lehrer hatten keine richtige Aufgabe um Inline-Assembler zu rechtfertigen"

btw: ist das ein selbst gebautes embedded 386ex Board oder ein fertigs Kit - eines von denen?
http://www.mme-berlin.de/386ex-modul/
http://elmicro.com/de/386excard.html
http://www.jkmicro.com/Flashlite386Ex.html
möchte mir eines zum spielen kaufen - ein 386ex Board würde gut in meine ARM-Board Sammlung passen Ich dachte nicht das die 386ex noch gebaut werden - lustig

also:

2. dein C- und Inline-Assembler-Beispiel enthält nur Befehle die schon auf dem 8088 vorkommen sind und für die es auch keine 32 oder 64 Bit Varianten gibt
d.h. der Opcode kann keine Pentium oder sonstige Optimierungen enthalten weil die Befehle dort einfach gleich sind

gilt das denn auch für andere befehle? also wenn da jetzt noch andere berechnungen durchgeführt werden, wäre es doch möglich, dass der compiler dann spezielle (schnellere) pentium-befehle verwendet, wodurch das programm dann entsprechend inkompatibel wäre, oder nicht?

Fragen:

1. welche Watcom Version ist es denn jetzt? (wcl -v auf der Kommandozeile)
2. welche Platform Version vom Watcom nuttz du (DOS, Windows, 16,32,64 Bit) - also von welcher Art ist deine wcl.exe
3. wie sieht genau deine wcl-Parametrisierung aus damit das richtige Ergebnis für dein embedded 386ex Target rauskommt
4. wie bekommst du dein Kompilat auf den 386ex - gibt da noch einen Load- oder Umwandlungsprozess für die obj-Datei oder EXE?

1. wie gesagt: die kiste befindet sich in der hochschule im labor, ich komm da nicht ran.
2. wahrscheinlich windows 32bit
3. der aufruf lautete ursprünglich z.b. "wcl A21 && A21"
4. auf dem daneben stehenden windows-rechner befindet sich eine spezielle software, die dann eine dos-oberfläche bietet, mit welcher ich dann programme von der festplatte auf den laborcomputer laden kann.

btw: ist das ein selbst gebautes embedded 386ex Board oder ein fertigs Kit - eines von denen?
http://www.mme-berlin.de/386ex-modul/
http://elmicro.com/de/386excard.html
http://www.jkmicro.com/Flashlite386Ex.html
möchte mir eines zum spielen kaufen - ein 386ex Board würde gut in meine ARM-Board Sammlung passen Ich dachte nicht das die 386ex noch gebaut werden - lustig

angeblich ist "der computer" komplett selbst gebaut, damit man den vollen überblick darüber hat. was das genau heißt, weiß ich auch nicht.
allerdings ist das ja eine hochschule und zumindest theoretisch sollte man dort die entsprechende ahnung haben, um solche platinen zur not auch selbst entwickeln zu können, aber ich weiß es einfach nicht.

2. dein C- und Inline-Assembler-Beispiel enthält nur Befehle die schon auf dem 8088 vorkommen sind und für die es auch keine 32 oder 64 Bit Varianten gibt
d.h. der Opcode kann keine Pentium oder sonstige Optimierungen enthalten weil die Befehle dort einfach gleich sind

gilt das denn auch für andere befehle? also wenn da jetzt noch andere berechnungen durchgeführt werden, wäre es doch möglich, dass der compiler dann spezielle (schnellere) pentium-befehle verwendet, wodurch das programm dann entsprechend inkompatibel wäre, oder nicht?

Ja klar gibt es die und wären natürlich inkompatibel - aber in Aufgabe21.c kommen keine Konstrukte vor für die es neuere/bessere Opcodes gibt, mich würde es aber trotzdem wundern wenn ihr ohne Optimierung UND 386 Code-Generierung (Achtung zwei paar Stiefel) arbeiten würdet - was aber scheinbar so ist

1. wie gesagt: die kiste befindet sich in der hochschule im labor, ich komm da nicht ran.
2. wahrscheinlich windows 32bit
3. der aufruf lautete ursprünglich z.b. "wcl A21 && A21"
4. auf dem daneben stehenden windows-rechner befindet sich eine spezielle software, die dann eine dos-oberfläche bietet, mit welcher ich dann programme von der festplatte auf den laborcomputer laden kann.

also keine Fakten - ich dachte du wolltest/könntest mit dem Ozi nachmessen - folglich also auch dort sein - oder hast du das Equipment teilweise noch zuhause?

allerdings ist das ja eine hochschule und zumindest theoretisch sollte man dort die entsprechende ahnung haben

seltener als man denkt

gibts da eine Kontaktperson bei euch?

Und was ist damit...?

So in der Form denke ich wäre genug der Buße:
"Meine Nickname ist HansKlaus und ich habe einen Assembler-Geschwindigkeits-Mythos im Internet verbreitet, ich war unerfahren, kannte den Kompiler nicht und mein Lehrer hatten keine richtige Aufgabe um Inline-Assembler zu rechtfertigen"

Jetzt kannst du dich noch reinwaschen - ansonsten landet es irgendwann in archive.org und wird deinen Nickname für immer beschmutzen