Assembler: Für was/aktuell? Lernen wo, wie?

Das ist ein sinnloses bespiel (in mehrerlei Hinsicht) - einzig interessant wäre Vergleich von Algorithmen. Zudem ist es ganz klar: einen (guten) Compiler zu schlagen ist oft nicht möglich oder nur extrem aufwändig. Einzig bei den SIMD Erweiterungen kann man mit Assembler wirklich was rausholen.

dot

syscall schrieb:

Einzig bei den SIMD Erweiterungen kann man mit Assembler wirklich was rausholen.

Für solche Dinge verwendet man besser Intrinsics als Assembler

Hostfreak schrieb:

Noch Fragen???

Ja: Hast du auch ein Beispiel das was aussagt? Irgendein Hello World, noch dazu mit so merkwürdigem Code, seh ich jetzt nicht als wirklich repräsentativ für irgendwas. Abgesehen davon schaut mir das eher nach einem Debug Build als nach einem optimierten Release Build aus. Da kann ich ein genauso sinnvolles Gegenbeispiel bringen:

#include "vector.h"

typedef math::vector<float, 3> float3;

int main()
{
  float3 v0 = float3(1, 2, 3);
  float3 v1 = float3(1, 1, 1);

  return dot(v0, v1);
}

Wie du siehst alles voll von Konstruktoren, Destruktoren, templates und Funktionen. Und der MSVC 10 macht draus:

mov eax, 6
ret

Wüsste nicht wie man das in asm besser machen könnte. Im C++ Code sieht man aber sofort was gemeint ist, in asm ist jegliche Semantik verschwunden.

Bei Banken läuft definitiv kein ASM. Ich kenne einige "kritische" Bank - Computerprogramme (Bankomat, Geldtransport, Geldlagerung, ...), da kommt einem von C über C++ bis hin zu Jave oder C# alles unter, nur ASM nicht.
Die Sprache der Wahl ist letztlich auch eher eine Frage, wann das Programm begonnen wurde. Es tut sich doch niemand freiwillig ASM an. Das nimmt man nur, wenns gar nicht mehr anders geht. Und dann auch nur an ein paar kritischen Stellen mit Inline ASM. Und definitiv nicht mehr!
Anders als in der Hobbywelt muss in Firmen schnell ein Ergebnis geliefert werden.
Ich hab schon öfters mitbekommen, nach welchen Gesichtspunkten die Verantwortlichen die Programmiersprache ausgesucht haben. Und da haben Argumente wie schnelle und übersichtliche Programmierbarkeit definitiv mehr gezählt als Geschwindigkeitsvorteile von ein paar µs.

Und auch wenn ich privat lieber C und C++ programmiere, so bin ich auf der Arbeit trotzdem froh, C# verwenden zu können, weil es viele Probleme massivst vereinfacht!

Übrigens wird ASM selbst auf Mikrocontrollern immer mehr verdrängt, und durch C ersetzt.

An und für sich finde ich es schon gut, ein bisschen ASM zu können, zwecks Verständnis für CPU, Speicher, ...
Aber danach sollte man sich wieder sinnvolleren Dingen zuwenden.

Glutamat schrieb:

Es tut sich doch niemand freiwillig ASM an. (...). Und dann auch nur an ein paar kritischen Stellen mit Inline ASM. Und definitiv nicht mehr!

Ohne ASM kein Inline-ASM.

dot schrieb:

Hostfreak schrieb:

Noch Fragen???

Ja: Hast du auch ein Beispiel das was aussagt? Irgendein Hello World, noch dazu mit so merkwürdigem Code, seh ich jetzt nicht als wirklich repräsentativ für irgendwas. Abgesehen davon schaut mir das eher nach einem Debug Build als nach einem optimierten Release Build aus. Da kann ich ein genauso sinnvolles Gegenbeispiel bringen:
#include "vector.h"

typedef math::vector<float, 3> float3;

int main()
{
  float3 v0 = float3(1, 2, 3);
  float3 v1 = float3(1, 1, 1);

  return dot(v0, v1);
}
Wie du siehst alles voll von Konstruktoren, Destruktoren, templates und Funktionen. Und der MSVC 10 macht draus:
mov eax, 6
ret
Wüsste nicht wie man das in asm besser machen könnte. Im C++ Code sieht man aber sofort was gemeint ist, in asm ist jegliche Semantik verschwunden.

Soetwas würde ich jetzt als pure Demagogie oder Populismus hinstellen. Eine seriöse Diskussion ist da nicht möglich... Im realen Leben mache ich um solche Leute einen sehr, sehr grossen Bogen.
Viel Spass mit Deinem C++

Hostfrak schrieb:

Soetwas würde ich jetzt als pure Demagogie oder Populismus hinstellen. Eine seriöse Diskussion ist da nicht möglich...

so ein Aussage von Jemanden, der sich selbst als Hardcore Assembler Programmierer bezeichnet

dot

Hostfrak schrieb:

Soetwas würde ich jetzt als pure Demagogie oder Populismus hinstellen. Eine seriöse Diskussion ist da nicht möglich...

Inwiefern das mit "Demagogie oder Populismus" zu tun hat ist mir zwar schleierhaft aber falls es nicht offensichtlich genug war: Das war eine halbironische Antwort auf dein "Beispiel" (wobei ein Körnchen Wahrheit drin steckt). Wenn du seriös diskutieren willst dann musst du auch mit seriösen Beispielen kommen.

dot schrieb:

Irgendein Hello World, noch dazu mit so merkwürdigem Code, seh ich jetzt nicht als wirklich repräsentativ für irgendwas. Abgesehen davon schaut mir das eher nach einem Debug Build als nach einem optimierten Release Build aus. Da kann ich ein genauso sinnvolles Gegenbeispiel bringen: [...]

...

Bashar

Die Antwort war von "Hostfrak", nicht von "Hostfreak".

Hier merkt man wieder deutlich, wie ignorant und weltfremd die Assemblerfanboys sind. Liegt wohl daran, dass sie unbedingt ihr Mikrowissen verteidigen muessen, fuer das sich im Grunde keiner mehr interessiert.

Und das mit den Banken ist das laecherlichste was ich lange gelesen habe. Bei Bankensoftware zaehlt vor allem eins: Validierung und Sicherheit. Und da ist Assembler so ziemlich das mieseste was es gibt. Banken benuzten fast immer Cobol und in neueren Anwendungen Java.

dot schrieb:

Inwiefern das mit "Demagogie oder Populismus" zu tun hat ist mir zwar schleierhaft aber falls es nicht offensichtlich genug war: Das war eine halbironische Antwort auf dein "Beispiel" (wobei ein Körnchen Wahrheit drin steckt). Wenn du seriös diskutieren willst dann musst du auch mit seriösen Beispielen kommen.

So.... jetzt ist Wochenende und ich bin in "Kampfstimmung" - nein - kämpfen müssen wir nicht.... Dieses Beispiel ist wirklich nur in 5 mn hingesch@#?+- Was es verdeutlichen soll, ist, dass in bestimmten Bereichen C++ absolut keine Berechtigung hat - Und das waren auch die Aussagen meiner vorherigen Posts. Ich denke aber, dass ich jetzt nicht am Zug bin 1000 Lines of C++ Code in Assembler umzusetzen, um zu beweisen, dass C++ im Verhältnis zu ASM von der Effizienz her keine Chance hat... Ich denke, das wird auch so jeder C++ Freak bestätigen. In der heutigen Zeit mit relativ schneller Hardware kann man ja auch recht grosszügig mit den Ressourcen umgehen... So gesehen - ok das mit dem C++.

Amusement schrieb:

Und das mit den Banken ist das laecherlichste was ich lange gelesen habe. Bei Bankensoftware zaehlt vor allem eins: Validierung und Sicherheit. Und da ist Assembler so ziemlich das mieseste was es gibt. Banken benuzten fast immer Cobol und in neueren Anwendungen Java.

Wie bester "Amusement" willst Du beispielsweise ein DB2 Exit bedienen - ausser mit Assembler? Das hat zwar nix mit der Anwendungsentwicklung zu tun - aber sehr wohl mit der Systemprogrammierung... - oder??

So viel Krebs in einem Thread. *Summertime*

HansKlaus schrieb:

das mmn schönste an assembler ist einfach, daß du quasi nebenbei lernst, wie die cpu bzw. der computer intern funktioniert.

Das ist ein altes und dummes Gerücht, das mit jeder neuen Prozessorgeneration an Wahrheitsgehalt verliert.
Das was man in Assembler von der CPU "sieht" abstrahiert das reale Schaltwerk schon bis zur Unkenntlichkeit weg. Nur weil man mit Registern rumfrickelt heißt das nicht, man hätte irgendeine Ahnung davon wie eine CPU aufgebaut ist.

asmQuestion schrieb:

Außerdem was denkt ihr darüber asm von null auf zu lernen? Macht es Sinn? Und vorallem wo lernt man es gut? Gibt es verschiedene Arten?(Hatte mal kurz versucht nen asm code auszuprobieren ist jedoch nicht gegangen und mit einer anderen ide ist es gegangen)
Also was muss ich beachten? Wo anfangen? Was muss ich wissen. Und vorallem das fast wichtigste kennt ihr onlinequellen was am Anfang gut wäre, damit ich mal reinschnuppern kann bevor ich nen Buch kauf. Aber wie bereits gesagt auch Buchempfehlungen sind gern gesehen. Schreibt einfach ma alles Grundlegende was ihr wisst damit ich mir ein bisschen ein Bild machen kann :). Danke.

Hallo,

ich bin von VB.NET zu Assembler gekommen. Man muss Assembler von Null auf lernen, da du auch einiges über deinen PC wissen musst.

Vor 9 Monaten habe ich mir die Bücher von Rainer Backer und Rhode/Roming gekauft nur auf Neugier. Anschließend die ersten Zeilen geschrieben und siehe da, es geht.

Sinn macht es auf jeden Fall. Lernen ist niemals verkehrt.
Seit ich damit arbeit weiß ich was Zeiger sind, wie man sie nutzt und man kann kinderleicht mit der WindowsAPI programmieren.
Eine Fensteranwendung zu erstellen ist im Nu gemacht und die Programme sind winzig klein. An einigen Stellen kannst du sogar Windows umgehen und direkt mit deinem PC "sprechen".

Das wichtigste für mich war noch die Einfachheit.
Jede Zeile besteht aus einem einzigen Befehl (mit Operanden natürlich).

Sowas wie hier:

rc=bind(acceptSocket,(SOCKADDR*)&addr,sizeof(SOCKADDR_IN));

gibts da nicht...
Man muss zwar ein paar Zeilen mehr schreiben aber es lohnt sich allemal.
Zudem gibts dort genauso If, else, While, Loop und einiges mehr.
Da ich nur Hobbyprogrammierer bin, bleibe ich auf jeden Fall bei Assembler.

Worauf du achten musst ist, das du deinen Code nach jeder 5. Zeile mal auf Fehler testest. Sonst suchst du dir einen Wolf *g*

Man lernt wirklich viel und es ist nicht so schwer wie überall behauptet wird.
Es ist halt anders.

Nicky

xpilz

Hallo.
Ich lerne schon seit einer Woche Assembler lesen und schreiben. Habe dabei natürlich auch eigene Eindrücke von der Sprache gesammelt. Nachdem ich mir diesen Beitrag durchgelesen hatte, musste ich mir ernsthaft Gedanken darum machen ob es die eine Woche überhaupt wert war und dass ich stattdessen nur das Grundprinzip in einer Stunde verstehen sollte.

-Realist- schrieb:

... da man das Grundprinzip in einer Stunde verstanden hat...

Natürlich brauchte ich anfangs einiges an Motivation. Leider hatte ich auch ein für mich nur halbwegs nachvollziehbares Tutorial, aber der Reiz für mich persönlich Assembler zu lernen war die Sache, dass man die komplette Kontrolle hat und im Groben weiß, beziehungsweise bestimmen kann, was passiert.

Um meine Meinung mal etwas zu befestigen hier mal ein Beispiel: ~Ich hoffe es ist für euch nachvollziehbar~
Ein ganz normaler Funktionsaufruf sieht sich in vielen Sprachen ziemlich ähnlich. Ich beschränke mich aufgrund der Übersichtlichkeit nur auf C++ und Assembler.

int func(int ret=0) {
    return ret;
}

int main() {
    func(0);
    return 0;
}

So sieht im besten Fall ein Funktionsaufruf in C++ aus. Wenn man sich diesen Code anguckt. Wird einem klar das C++ einige seiner Pflichten als Hochsprache erfüllt hat. Man kann es schon mit minimalen Englisch Kentnissen und ein wenig Logik nachvollziehen. Dazu kann man den Code auf den ersten Blick auch recht leicht Warten. Was C++ aber für diese Vorteile aufgibt, ist die Klarheit einiger Instruktionen die zwischen einem Funktionsaufruf passieren. Und hier ist Assembler einzigartig (meines Wissens nach).
Hier ein größtenteils äquivalentes Beispiel, im Vergleich zu dem oberen.
(Gas Syntax)

.section .text
.globl _start
_start
  pushl $0
  call func

  movl $1, %eax
  movl $0, %ebx
  int $0x80

.type func, @function
func:
  movl 4(%esp), %eax
  ret

Wie man unschwer erkennen kann, ist es schlecht lesbar. Vielleicht bräuchte dieser Code auch mehr Wartungsarbeit als der erste. Aber, wenn man etwas Ahnung von Assembler hat, und dazu noch eine Quelle, die ein Beispiel in dieser Art für eine Erklärung der Segmentierung verwendet, dann ist es an diesem Beispiel wesentlich besser zu verstehen als in einer anderen Sprache wie C++ (Im Bezug auf Funktionen).

Wollte man sich für längere Zeit mit der Assembler Sprache beschäftigen, sei es im Beruf, der Schule oder im Hobby, dann kann man sagen, je mehr man über Assembler liest, desto besser ist es. Egal welche Qualität die Lektüre bietet. Ich denke neben dem Lesen probiert man die Beispiele nebenbei auch aus. Läuft ein Versuch jetzt darauf hinaus das man es nicht versteht oder das Programm eine falsche Ausgabe macht, dann guckt man nach warum, probiert aus oder zieht das Internet zu Rate. Ich denke wie nachtfeuer schon gesagt hat, ist ein Selbstständiges Lernen für Assembler notwendig und wichtig. Gerade wenn man bei null Anfängt.

nachtfeuer schrieb:

... Das heißt, man ist (erstmal) gezwungen, sich diesen roten Aufbauplan selbst zu erstellen, ...

Auf Assembler bin ich nicht gekommen, weil ich unbedingt nebenbei wissen wollte wie eine CPU beziehungsweise der Computer intern funktioniert...

HansKlaus schrieb:

das mmn schönste an assembler ist einfach, daß du quasi nebenbei lernst, wie die cpu bzw. der computer intern funktioniert.

..., sondern wissen wollte was es im genaueren mit der Segmentierung (siehe: Segmentierung) auf sich hat. Ich persönlich finde, dass es sich allein dafür schon lohnt mit Assembler anzufangen. Das wie spielt dabei nach meiner Meinung erst einmal eine Nebenrolle.
Wichtiger ist: Motivation, Durchhaltevermögen und ein wenig Selbstständiges Lernen.

Ich hoffe alle zukünftigen Leser hilft mein Beitrag zu diesem Thema weiter.
Grüße, xpilz

Ethon

So.... jetzt ist Wochenende und ich bin in "Kampfstimmung" - nein - kämpfen müssen wir nicht.... Dieses Beispiel ist wirklich nur in 5 mn hingesch@#?+- Was es verdeutlichen soll, ist, dass in bestimmten Bereichen C++ absolut keine Berechtigung hat

Nö, du verstehst das falsch. Höchstens gewisse Bibliotheken und Techniken von C++ haben in gewissen Bereichen keine Berechtigung. I/O-Streams sind da ein Paradebeispiel, die sind saulahm, und du bringst es.
Aber weißt du was witzig ist: Bei I/O intensiven Applikationen zocken sogar die lahmen iostreams deine ASM-Lösung per Syscall ab da du kein Buffering verwendest.
Ergebnis: Deine ASM-Lösung ist sogar lahmer als Java oä. da das Konzept stinkt.

- Und das waren auch die Aussagen meiner vorherigen Posts. Ich denke aber, dass ich jetzt nicht am Zug bin 1000 Lines of C++ Code in Assembler umzusetzen, um zu beweisen, dass C++ im Verhältnis zu ASM von der Effizienz her keine Chance hat... Ich denke, das wird auch so jeder C++ Freak bestätigen.

Und nächster Denkfehler: Du gehst davon aus, dass ein Assembler-Programmierer genau den Prozessor versteht. Das tun aber nur die allerwenigsten, und die sind zu großen Teilen damit beschäftigt C/C++ Compiler zu schreiben.
Simples Beispiel: Machst du ein "mov eax, 0" und der Compiler (da er weiß dass es schneller ist) ein "xor eax, eax", dann ist der C++ Code bereits schneller.
Und das geht in ganz andere Größenordnungen, da es sich ein C++ Compiler leisten kann, absolut unverständlichen und hochperformanten ASM-Code zu erzeugen, den kein Mensch warten wollen würde.

Dann noch weitere Feinheiten, dass der Compiler Instruktionen perfekt anordnen kann usw

Kleine Teile mögen in ASM performanter möglich sein als es ein Compiler hinbekommt (Vor allem wenn man spezifische CPU-Features nutzt, die der Compiler per Default nicht unterstützt, zb AMD 3DNow! oä), in der Regel ist C++ aber schneller, je nach Technik eben.

Ethon schrieb:

Aber weißt du was witzig ist: Bei I/O intensiven Applikationen zocken sogar die lahmen iostreams deine ASM-Lösung per Syscall ab da du kein Buffering verwendest.
Ergebnis: Deine ASM-Lösung ist sogar lahmer als Java oä. da das Konzept stinkt.

Man muss halt die richtigen Funktionen verwenden - genau wie es c++, java & co machen - das hat nicht mit der Art zu tun, wie man die Funktionen Aufruft.

Ethon schrieb:

Simples Beispiel: Machst du ein "mov eax, 0" und der Compiler (da er weiß dass es schneller ist) ein "xor eax, eax", dann ist der C++ Code bereits schneller.

Nö, XOR ist bestenfalls gleichschnell. XOR bringt nur etwas, wenn es darum geht Flag-Abhängigkeiten zu brechen.

Ethon schrieb:

in der Regel ist C++ aber schneller, je nach Technik eben.

Hängt vom Compiler und deren Einstellungen ab. Aber grundsätzlich kann ich dem zustimmen: Meiner Erfahrung nach sind Compiler hier und da Schlagbar, im Ganzen sind sie aber dem Assembler-Programmiere deutlich überlegen.

nachtfeuer

Ethon schrieb:

...

@Ethon: Es braucht nicht allzulange, um die Assembler Grundlagen zu verstehen, und sich bestimmte Programmiertechniken in Assembler anzueignen. Natürlich nicht in 10 Minuten oder 21 Tagen. Aber vielleicht nicht viel länger als 8 Wochen oder wenn man viel arbeitet, ein viertel oder halbes Jahr für weit fortgeschrittenere Techniken. Auf jeden Fall wird man schneller zum Asm-Profi als man in C++ guter Fortgeschrittener wird.
Umgekehrt helfen einem die Assemblergrundlagen, bessere, stabilere Programme zu schreiben oder Disassemblings viel besser zu verstehen. Und man kann auch aus Asm heraus C-Funktionen aufrufen, wie auch umgekehrt.

Setzt euch lieber hin, nehmt euch die Zeit, um Assembler zu lernen und zu vertiefen. Es ist keine verschwendete Zeit. Wenn dann ein tiefers, geübtes Verständnis über die Assemblerprogrammierung da ist, dann kann man nochmal kommen, und seine eigenen Urteile über Assembler hier im Asm-Forum lesen.
Nur Mut.

Ethon

Man muss halt die richtigen Funktionen verwenden - genau wie es c++, java & co machen - das hat nicht mit der Art zu tun, wie man die Funktionen Aufruft.

Naja, alle kochen nur mit Wasser.
In seinem Beispiel hat er write() direkt aufgerufen. Hätte man aus C++ auch können, aber er hat als Gegenbeispiel cout verwendet.
Um fair zu bleiben, hätte er in seinen Code Buffering, Locales etc einbauen müssen. Von daher fand ich den Vergleich schlicht unfair.

Nö, XOR ist bestenfalls gleichschnell. XOR bringt nur etwas, wenn es darum geht Flag-Abhängigkeiten zu brechen.

Du wirst NIEMALS ein "mov REGISTER, 0" sehen, das von einem x86 Compiler erzeugt wurde.
Selbst wenn mov gleichschnell wäre als ein xor(was es wirklich nicht ist), ist ein xor von der Instruktionsgröße her kleiner (1 Byte vs mehrere Bytes).
So Feinheiten, die als Mensch eher unintuitiv sind (obwohl sich das bei dem xor in Grenzen hält), aber für den Compiler ganz normal.

Meiner Erfahrung nach sind Compiler hier und da Schlagbar

Genau, und für das "hier und da" lohnt sich ja auch Assembler, hat schon einen Grund wieso memcpy und Konsorten in ASM geschrieben werden.
Nur nervt es mich tierisch, wenn Leute überall verbreiten wollen, dass Assembler ja soooo viel schneller sei als C etc.

Ethon schrieb:

Du wirst NIEMALS ein "mov REGISTER, 0" sehen, das von einem x86 Compiler erzeugt wurde.
Selbst wenn mov gleichschnell wäre als ein xor(was es wirklich nicht ist), ist ein xor von der Instruktionsgröße her kleiner

Die Größe ist heut zu tage nur noch in wenigen Fällen von Bedeutung. Und ganz neben bei, XOR ist grundsätzlich nicht schneller - nur in bestimmten Situation kann es Vorteile bringen es zu verwenden.
Wenn du es nicht glaubst, kannst du es ja mal auf aktuellen Systemen testen.

dot

masm schrieb:

Die Größe ist heut zu tage nur noch in wenigen Fällen von Bedeutung.

Ist das so? Ich würde mal behaupten, die Größe ist vor allem heutzutage immer mehr von Bedeutung. Denn die CPUs werden immer schneller, die Speicher aber nicht. Google mal nach Instruction Cache...

abc.w

Ich habe mal auf einer CPU Takte für xor gemessen: http://www.c-plusplus.net/forum/237896-full
Es gibt einen Geschwindigkeitsvorteil, wenn man drei mal hintereinander das eine und gleiche Register mit xor nullt, ob es Sinn macht oder nicht - sei dahingestellt. Irgendwas tut sich in der CPU...

Irgendwo im Optimization Manual von Intel steht, dass ihre CPUs eine Art spezielle Unterstützung für xor haben. Vielleicht ein Beispiel, welchen Einfluss ein "Glaube" entwickeln kann. Der Glaube an das gute alte xor bewegt die Chiphersteller, ihre Chips zu modifizieren, damit sie in den Benchmark-Tests ja nicht langsamer abschneiden. Die Benchmark-Tests enthalten ja im guten Glauben lauter xor reg, reg... Die Modifikationen auf dem Chip brauchen mehr Chipfläche, mehr Chipfläche bedeutet mehr Geld - aber dieses Geld werden wir, die Gläubigen an xor, beim Kauf des nächsten PCs ausgeben müssen