Schnelligkeit von C-Code

[Ein ehemaliger Benutzer]

naja die aufgabe sollte wohl zeigen, dass inline-assembler schneller ist bzw. sein kann, weil sich dieser im gegensatz zu hochsprachen unmittelbar in opcodes umwandeln lässt.
es gab auch noch eine weitere aufgabe, bei der wir das ganze mit hilfe eines ominösen treibers, der sich aber genauso verhält wie in und out, auf einem windows-pc durchführen und dann erklären sollten, wieso das signal in bezug auf die viel höhere taktfrequenz der cpu so unglaublich langsam ist.
die aufgabe sollte uns dann zeigen, dass in und out heutzutage ziemlich selten zu anwendung kommen, weil das betriebssystem alles sperrt und außerdem die hardware gar nicht mehr direkt an die cpu angeschlossen ist.

jedenfalls hast du beim openwatcom keinen debugmodus bzw. du musst da explizit angeben, dass du debuginformationen im programm haben willst, ansonsten ist das immer "release".

[dachschaden]

HansKlaus schrieb:

die aufgabe sollte uns dann zeigen, dass in und out heutzutage ziemlich selten zu anwendung kommen, weil das betriebssystem alles sperrt und außerdem die hardware gar nicht mehr direkt an die cpu angeschlossen ist.

Was ist Real Mode?

HansKlaus schrieb:

jedenfalls hast du beim openwatcom keinen debugmodus bzw. du musst da explizit angeben, dass du debuginformationen im programm haben willst, ansonsten ist das immer "release".

Das gleiche beim GCC, und dennoch musst du da auch die Optimierungsstufe mit -O<X> angeben. Ohne Optimierungsstufe wird auch fast C-2-Assembler kompiliert, erst mit Optimizern geht der Compiler den Code mal mit Verstand durch.

EDIT: Debugging-Informationen bekommst du mit -g -ggdb3 , für's Profiling gibt's noch -pg .

[Ein ehemaliger Benutzer]

da ich das andere eben nicht gesehen habe: ich habe doch den optimierten code (-ot = optimize for time) hochgeladen und da ist doch eindeutig zu sehen, dass da ständig irgendwelche unterprogramme aufgerufen werden.

[dachschaden]

HansKlaus schrieb:

da ist doch eindeutig zu sehen, dass da ständig irgendwelche unterprogramme aufgerufen werden.

Du meinst, das hier?

L$1:
mov al,0x01
mov dx,0x0338
out dx,al
mov al,0x00
mov dx,0x0338
out dx,al
jmp L$1

Ich sehe vier mov s, zwei out s, und einen jmp . Unterprogramme (/Funktionsaufrufe) sehe ich da nicht.

EDIT: Nein, ich bin blöd, du hast beide mit -ot kompilert. Aber schauen wir uns mal den Code dennoch an:

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.

[Gast3]

naja die aufgabe sollte wohl zeigen, dass inline-assembler schneller ist bzw. sein kann, weil sich dieser im gegensatz zu hochsprachen unmittelbar in opcodes umwandeln lässt.

Das zeigt euer Beispiel aber eben nicht - nur das ein falsch konfigurierter Kompiler schlechten Code erzeugt - mehr nicht

jedenfalls hast du beim openwatcom keinen debugmodus bzw. du musst da explizit angeben, dass du debuginformationen im programm haben willst, ansonsten ist das immer "release".

Codeoptmierung und Mit-Debug-Information sind unterschiedliche Dinge - wenn du beim Watcom keine Optimierangabe machst optimiert er nichts - so wie jeder andere (ältere oder neuere) C/C++ Kompiler den ich kenne auch - und du kannst immer zusätzlich Debug-Information anfordern (unabhängig von der Optimierung)

Kompilier doch einfach mal mit "Standard" Optimiersettings:

z.B. wcl -q -bt=DOS /oneatx /oh /ei /zp8 /6 /fp6 d:\temp\outp_test.c

findest du dann deine calls noch?

und dein Inline-Assembler schlägt z.B. auch den neuesten GCC 6.2 (vom 22.8.2016), VS2015 oder Clang 3.8 - wenn du ihn ohne Optimierung aufrufst

#include <stdint.h> 

#define PORT 123 

static inline void outp(uint16_t port, uint8_t val) 
{ 
  asm ( "outb %0, %1" : : "a"(val), "Nd"(port) ); 
} 

int main() 
{ 
  //Hier noch bisschen Initialisierung 
  for(;;) 
  { 
    outp(PORT,0x01); 
    outp(PORT,0x00); 
  } 

  return 0; 
}

Ohne Optimierung
gcc -O0 (oder keine Angabe) - sieht (ungefähr - bis auf 32bit) so aus wie dein Ergebnis mit den 2 Calls

outp(unsigned short, unsigned char):
        push    rbp
        mov     rbp, rsp
        mov     edx, edi
        mov     eax, esi
        mov     WORD PTR [rbp-4], dx
        mov     BYTE PTR [rbp-8], al
        movzx   eax, BYTE PTR [rbp-8]
        movzx   edx, WORD PTR [rbp-4]
        outb al, dx
        nop
        pop     rbp
        ret
main:
        push    rbp
        mov     rbp, rsp
.L3:
        mov     esi, 1
        mov     edi, 123
        call    outp(unsigned short, unsigned char)
        mov     esi, 0
        mov     edi, 123
        call    outp(unsigned short, unsigned char)
        jmp     .L3

mit Standard-Optimierung
gcc -02 -> sieht so aus wie das Watcom Ergebnis mit den Optimierflags kompiliert

main:
        mov     ecx, 1
        xor     edx, edx
.L2:
        mov     eax, ecx
        outb al, 123
        mov     eax, edx
        outb al, 123
        jmp     .L2

[Ein ehemaliger Benutzer]

dachschaden schrieb:

Was ist Real Mode?

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.

Das gleiche beim GCC, und dennoch musst du da auch die Optimierungsstufe mit -O<X> angeben. Ohne Optimierungsstufe wird auch fast C-2-Assembler kompiliert, erst mit Optimizern geht der Compiler den Code mal mit Verstand durch.

hmmm also wir sollen später auch noch lernen, wie man so etwas von hand optimiert bzw. wie man ressourcenschonend programmiert. der compiler hat sich das ja auch nicht ausgedacht, sondern irgendjemand hat das so programmiert, dass diese ptimierungen durchgeführt werden.

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.

[Ein ehemaliger Benutzer]

dachschaden schrieb:

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.

xor ist eben schneller als mov und out_ wird zumindest laut aussage des laboringenieurs deshalb aufgerufen, weil der compiler eben nicht weiß, was er genau machen soll, während ich ihm bei inline-assembler gewissermaßen erkläre, dass ich so schlau bin und er bitte den assembler-code direkt übernehmen soll - was er dann ja auch so macht.

[dachschaden]

HansKlaus schrieb:

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.

Ein Mebibyte - 16 64-KiB-Segmente. Und das ist der Adressraum, nicht der insgesamt ansprechbare Arbeitsspeicher (der ist 10 64-KiB-Segmente, 640 KiB.)

Jeder Kernel auf einem x86/x64-System bootet im Real Mode. Die Hardware MUSS an die CPU angeschlossen sein. Nur, weil das Betriebssystem den Zugriff auf die Hardware für Userspace-Programme sperrt, heißt das nicht, dass der Zugriff nicht mehr möglich ist.

Auch moderne x64-Prozessoren haben auch noch das A20-Gate. Es gibt eine Meeeenge Abwärtskompatibilität in Prozessoren, auch die Taktfrequenzen, in denen kommuniziert wird.

EDIT:

HansKlaus schrieb:

xor ist eben schneller als mov

Klick!

Ein xor spart Platz, ist aber nicht unbedingt schneller. Das hängt davon ab, wie die CPU funktioniert. Die kann bei der Dekodierung von Instuktionen, die eine fixe Länge haben, schneller sein. Deswegen macht man auch die Unterscheidung zwischen "Optimierung nach Größe" und "Optimierung nach Geschwindigkeit".

[Ein ehemaliger Benutzer]

Gast3 schrieb:

Kompilier doch einfach mal mit "Standard" Optimiersettings:

z.B. wcl -q -bt=DOS /oneatx /oh /ei /zp8 /6 /fp6 d:\temp\outp_test.c

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

[Gast3]

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

[Gast3]

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

[Gast3]

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?

[Gast3]

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

[Gast3]

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

[Gast3]

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.

[Gast3]

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

[Gast3]

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

[Ein ehemaliger Benutzer]

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.

[Gast3]

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