C++ vs. Assembler

[freakC++]

Wird denn beim Compilieren etwa erst in Assembler übersetzt und dann erst in Maschinensprache? Warum übersetzt der Compiler nicht gleich in Einsen und Nullen?

Vielen Dank
lg, freakC++

[dot]

freakC++ schrieb:

Warum übersetzt der Compiler nicht gleich in Einsen und Nullen?

Tut er ja. Aber Einsen und Nullen sind nicht so wirklich hilfreich für den menschlichen Leser. Darum schaut man sich die Einsen und Nullen eben in Form von Assembler an...

[linux_c89]

Zeig' mir einen komplett in C oder C++ geschriebenen Bootsektor und ich glaub's.

Das kommt drauf an was du machen willst.
Auslesen geht mit einer struct auf jeden Fall, schreiben nur für Masochisten^^ (man müsste eigentlich die Opcodes manuell reinschreiben).
Das heißt es geht schon, es macht nur kein Mensch.

[Nobuo T]

linux_c89 schrieb:

Zeig' mir einen komplett in C oder C++ geschriebenen Bootsektor und ich glaub's.

Das kommt drauf an was du machen willst.
Auslesen geht mit einer struct auf jeden Fall, schreiben nur für Masochisten^^ (man müsste eigentlich die Opcodes manuell reinschreiben).
Das heißt es geht schon, es macht nur kein Mensch.

Jo, man kann einen Bootsektor auch in einem Hexeditor schreiben oder manuell in Lochkarten stanzen. Macht aber auch kein Mensch.

[linux_c89]

Jo, man kann einen Bootsektor auch in einem Hexeditor schreiben oder manuell in Lochkarten stanzen. Macht aber auch kein Mensch

Echte Programmierer(TM) benutzen sowieso Schmetterlinge^^
http://xkcd.com/378/

[Hehe]

Damit programmiert man : http://media.techeblog.com/images/_funnykeyboards_1.jpg . Wir sind nur alle schon zusehr verwöhnt

[_umpf[\*&//$%([^]

freakC++ schrieb:

Hallo zusammen,

ich möchte mir Assembler beibringen und habe nun mein erstes Buch dazu erhalten. Gibt es eine Problemstellung, die mit reinem C++ nicht gelöst werden kann, aber mit Assembler? Ich benötige nämlich ein Beispiel, warum man eigentlich Assembler lernen sollte. Ich suche also ein Problem, dass durch Hochsprachen eher nicht gelöst werden kann, mit Assembler aber schon. Ich dachte an das Auslesen der Festplattengröße. Ich bin mir aber nicht sicher, ob ich das mit C++ nicht auch irgendwie hinkriegen könnte.

Vielen Dank
lg, freakC++

1. Eine Cp-Sprache(ich meine Asm) schnell lernen
2. Ein möglichst kleines Programm schreiben
3. Ein leicht debuggbares Programm schreiben
4. schnellere Algorithmen/Befehle für Berechnungen finden
5. seltsame Hochsprachenkonstrukte besser verstehen
6. Leistungsfähige Exoten wie Cell überhaupt ausreizen
7. C bzw. C++ Fetischisten, die nicht beides können, seitenlange Rechtfertigungsromane schreiben lassen
8. Maschinenspezifische Optimierungen/Anpassungen bei allen, meistens aber bei neuen oder unbekannten Maschinen (.
9. Ein möglichst eigenständiges Programm schreiben
A. Disassembles schneller lesen können
B. Debug für kleine feine Proggies benutzen können.
C. Sich über den neuen (64bit) Rip-Mode freuen (Rip? Rip asm <->Multicore/->>Javahardwaredesignerboys?
D. Sich über Vorurteile über Assembler wundern
E. Über die Leistungsfähigkeit und das Handling von Fasm staunen.
F. Sein Programm mit dem gas selber schreiben, falls einem der Code vom gcc fishy erscheint.
10. Die grundlegenden Funktionen der Programmierung/der Hardware ganz nebenbei erlernen
11. Überhaupt wissen, was mit X nicht geht, aber mit asm, bzw. was mit asm auch nicht geht oder nicht unbedingt besser. Überhaupt auch die letzte Option zur Verfügung zu haben, wenn es um Optimierung geht, überhaupt _asm {} sinnvoll nutzen können, als natürlichen Bestandteil von C und auch C++.

Mir fällt noch mehr ein, etwa GUI-Programming, ohne sich den Kopf darüber zu zerbrechen, welches Guipacket, oder demoscenercode reversen, oder Betriebssystemboot- und bastelspielereien, aber ich wills nicht übertreiben, und ich hab ja auch oben schon geschrieben, wohin solche Argumente führen

@Nobuo
Maschinenbootcode ist nicht so sonderlich groß, den kann man zur Not auch mal in den Hexeditor tippen. Das hat ganz nebenbei den Vorteil, das die Größe auch gleich passt.

[_OMG]

Großmut kommt vor dem Fall

[ZOMG!!1]

Nicht eher Hochmut?

[raps]

es gibt viele dinge die nicht mit c(++) an sich gehen, deswegen bauen compiler hersteller "instrinsics" ein, diese binden assembler "schnipsel" ein. manchmal sind das nur einzelne instruktionen, manchmal eine sequenz von instruktionen, dabei ist es oft wichtig welches register in welcher reihenfolge gelesen/geschrieben wird.
sowas merkt man oft durch die dumheit die damit daherkommt, denn weil der compiler nichts ueber diese "schipsel" weiss, kann es sein, dass sowas wie z.b.
x=__mul(y,x); langsammer ist als x=__mul(x,y); weil eine temporaere kopie von y angelegt wird, ,da der compiler nicht weiss, dass in diesem fall x und y vertauscht werden koennen, ohne dass das ergebnis anders wird. (sieht man im disassembler natuerlich).

wenn ein compiler mal nicht die instructions unterstuetzt die du brauchst, musst du sie "per hand" als inline assembler einbinden, z.b. um bei cpus die mehrere threads auf einem core laufen lassen, die rechenzeit von einem hardware thread fuer ein paar cycles komplett abzugeben (quasi ein yield).

[Marthog]

Der Hauptvorteil von Assembler ist die Geschwindigkeit.
Berechnungen, die von Programmen sehr oft in kurzer Zeit aufgerufen werden, kann man in Inline-Assembler schreiben. Den Programmrest schreibt man in C/C++. Ganze Proramme würde man schon wegen Aufwand und Übersichtlichkeit nicht in Assembler schreiben, aber wichtige Algorithmen kann man als Zeitersparnis gut in Assembler schreiben (vorausgesetzt, man ist besser als der Compiler).

[dbu]

Marthog schrieb:

(vorausgesetzt, man ist besser als der Compiler).

was bei dem aktuellen Stand der Compilertechnik und den modernen CPU's eher selten der Fall sein duerfte.

Wenn du heute Spass mit Assembler haben moechtest, dann such dir nen kleinen einplatinen Rechner mit ein paar IO-Ports...

Gruss
Dirk

[Erhard Henkes]

Wie oben bereits erwähnt, benötigt man für Bootloader immer noch Assembler.
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm

Bei µC-Programmierungen kann man sowohl Assembler als auch bequemer C/C++ verwenden.
http://www.henkessoft.de/Roboter/stk500.htm
http://www.henkessoft.de/Roboter/ASURO.htm
http://www.henkessoft.de/Roboter/Nibo.htm

Der Nachteil von Assembler ist die enge Bindung der Syntax an den Prozessor. Bei C ist man da unabhängiger, eben Hochsprache. Daher vermeidet man heutzutage Assembler und verwendet z.B. C.

Ist man allerdings Assembler-Fan, warum auch immer, so kann man z.B. ein Hobby-OS komplett in Assembler schreiben. Die Lesbarkeit ist sogar ziemlich gut. Ein vorbildhaftes Beispiel ist z.B. TatOS (den Autor "TomT" findet man bei osdev.org).
http://code.google.com/p/tatos/
http://code.google.com/p/tatos/downloads/list

[rapso]

dbu schrieb:

Marthog schrieb:

(vorausgesetzt, man ist besser als der Compiler).

was bei dem aktuellen Stand der Compilertechnik und den modernen CPU's eher selten der Fall sein duerfte.

an sich ist das noch recht oft der fall, jedenfalls sehe ich so einiges was suboptimal ist.

dazu hatte ich hier sogar mal einen thread der das schoen aufzeigt (also wozu assembler wissen gut waere)

http://www.c-plusplus.net/forum/130853

ich habe so das gefuehl, dass mit jeder visual studio version alles ein bissl langsammer wird. Man kann gut was rauskitzeln indem man auf 64bit stellt, aber dann funktioniert inline assembler nicht und man verliert wieder irgendwo an anderer stelle.

bei gcc gab es auch einen ziemlichen absacker, 2.95 is IMO noch am besten was performance vom generierten code angeht. die neueren, besonders was vectorizing angeht sind wieder gut am anziehen, aber meistens wegen wirklich aufwendiger "highlevel" feature, rein von der code generierung auf assembler ebene ist da nicht soviel was sich verbessert.

die bisher besten resultate sah ich vom SPU binary generiert mit gcc. wenn man da alles an optimierungen aufdreht, generiert das ding von dem ganzen code den man drauf wirft eine einzige funktion.
wenn sowas schreibt wie z.b.

if(x==y)
  blbla=5;

//100zeilen code

if(x==y)
  bfdsdf=545;
//weiterer code

dann hat er mir daraus zwei funktionen gesplitet, eine fuer x==y und eine fuer x!=y, sodass der untere check eingespart werden konnte, das kostet rein vom branching her 6cycles nud zudem ist das instruction sheduling suboptimal wenn ein branch vorhanden ist.
das hatte zur folge, dass der code von 9 auf 17kb wuchs, wenn die undere if-abfrage vorhanden war (und darauf achtet man, wenn man jedes kb von den 256KB verplant

wenn man assembler lesen will, empfehle ich zudem sich einen der static code analyser fuer assembler zu besorgen, die zeigen schoen dependancies zwischen instructions, registern und penalties. (ich kenne leider keine publich tools, deswegen kann ich nichts empfehlen).

[nachtfeuer]

rapso schrieb:

wenn man assembler lesen will, empfehle ich zudem sich einen der static code analyser fuer assembler zu besorgen, die zeigen schoen dependancies zwischen instructions, registern und penalties. (ich kenne leider keine publich tools, deswegen kann ich nichts empfehlen).

Na, zur Not tuts wohl auch das geniale Hackertool Brain

Mir ist übrigens aufgefallen, das es sich in Gemeinsschaft oft um ein vielfaches spannender/lustiger optimieren läßt. Hast du die 2 langsamsten Stellen in deinem Raytraycer schon mal einer guten Optimiergemeinschaft (z.B. hier: http://www.c-plusplus.net/forum/f15 ) vorgeführt?
(Optimiergemeischaften empfehlen sich gerade auch für Parallelprogramming, weil Erfahrungsaustausch und Abgleich hier das A und O ist.

Letztlich kann man noch die Frage in den Raum werfen, warum eigentlich C++-Compiler überhaupt unterschiedlich schnelle Programme rauswerfen, oder unterschiedlich groß/klein und unterschiedlich fehlerfrei/-unfrei auf SystemXY laufen oder HardwareXY laufen.