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

[dot]

Hostfreak schrieb:

Naja... hier zwei Links, einer zum Verständinis - der andere für einen Kurs

Sry aber ich kapier echt nicht was genau mir diese Links jetzt sagen sollen
Falls es dich beruhigt: Ich bin jetzt sicherlich kein Guru aber auch ganz sicher kein totaler Analphabet was Assembler angeht...

Hostfrak schrieb:

Nun C++ - alleine schon, dass da ein Constructor und ein Destructor bei jeder Instanzierung erforderlich ist, ist ein "Overhead" - Viel zu viele Instruktionen, die gar nicht nötig wären..

Man sieht du hast dich ja sehr eingehend mit C++ und der Funktionsweise moderner Compiler auseinandergesetzt

Hostfrak schrieb:

Wenn globale Variable (Daten) gleich automatisch allen Beteiligten einer "Unit of Compile" unkonntrolliert zur verfügung steht, ist an diesem Konzept etwas falsch... - oder?? Ansonsten würde man doch OO gar nicht benötigen.

Man kann übrigens auch in ASM wunderbar OO programmieren, OOP hat nämlich nichts mit irgendwelchen Schlüsselwörtern konkreter sogenannter OO Sprachen zu tun (ich kann dir z.B. Tonnen von C++ Code zeigen der voll von class und frei von OOP ist ). Abgesehen davon ist OO natürlich kein Wundermittel aber deinen Satz da oben kapier ich nicht.

Hostfrak schrieb:

Das hat nichts mit zig Millionen Transaktionen zu tun. Jeder Bankautomat - jede Kassentransaktion - jede interne Buchng - das gesamte HR usw.

Klar, das ist natürlich alles in Assembler gecodet, was sonst? Gerade wenn es ums Finanzsystem geht ist es doch essentiell absolute Kontrolle über die Hardware zu haben und Assembler hierfür geradezu prädestiniert, schließlich hat es sich ja gezeigt dass die stabilsten und sichersten Programme genau dann geschrieben werden wenn jede Zeile Code jede beliebige Speicherstelle verändern kann. Auch sind Assemblerprogramme so übersichtlich dass selbst komplexeste Zusammenhänge in derart riesigen Systemen sofort begreifbar sind. Die daraus resultierende extrem leichte Wartbarkeit kombiniert mit der hohen Portabilität des Code macht Assembler zum idealen Kandidaten für die Entwicklung solcher Software...

Assembler hat seinen Platz aber dort seh ich ihn definitiv nicht...

[Hostfreak]

dot schrieb:

Sry aber ich kapier echt nicht was genau mir diese Links jetzt sagen sollen
Falls es dich beruhigt: Ich bin jetzt sicherlich kein Guru aber auch ganz sicher kein totaler Analphabet was Assembler angeht...

Wir reden von zwei verschiedenen Welten: Ich rede von der z/OS Welt, Du meinst wohl die Unix, Linux, Windows Welt.
Als ich mich vor ein paar Jahren an euere Welt eher hobbymässig angenähert habe, habe ich genauso mit dem Kopf geschüttelt und mich gefragt: "Was machen die denn da?"

dot schrieb:

Man sieht du hast dich ja sehr eingehend mit C++ und der Funktionsweise moderner Compiler auseinandergesetzt

Nein, das habe ich nicht, und das ist auch nicht mein Anliegen. Der TE hatte gefragt:

Da ich leider nicht viel finde frag ich jetzt einfach mal hier drauf los. Und zwar überlege ich mir mich an asm heranzuwagen, doch da kommt ne Frage von mir. Nämlich ist das noch aktuell. Findest es nur noch vorwiegend in Hardware-programmierung Anwendung oder gibt es noch andere Anwendungsbereiche.

Meine ursprüngliche Antwort bezog sich also darauf und ich wollte erläutern, dass optimaler Code im Systembereich von Grossrechnern, auf denen zig Millionen Transaktionen täglich laufen sehr wichtig sind. In der IBM Grossrechnerwelt (und nicht nur da) geht man sogar soweit, dass man etwa einen Compress nicht softwaremässig löst, sondern in der Hardware implementiert.
http://www-01.ibm.com/software/data/db2imstools/imstools/ims-hardware-data-compression/
Info was das ist:
http://www.differencebetween.net/technology/difference-between-hardware-compression-and-software-compression/

dot schrieb:

Klar, das ist natürlich alles in Assembler gecodet, was sonst? Gerade wenn es ums Finanzsystem geht ist es doch essentiell absolute Kontrolle über die Hardware zu haben und Assembler hierfür geradezu prädestiniert,

Assembler hat seinen Platz aber dort seh ich ihn definitiv nicht...

In der Anwendungsentwicklng hat Assembler sicher nichts zu suchen. Aber wie gesagt ganz unten im System... Dort ist Assembler unentbehrlich. Und als alter Hardcore Assembler Programmierer kann ich dem TE nur empfehlen:
Arbeite Dich in einen Prozessor ein - wenn man den mal richtig beherrscht, arbeitet man sich auch recht schnell in andere Prozessortypen ein.

Das war eigentlich alles, was ich zu diesem Thema sagen wollte...

[dot]

Hostfreak schrieb:

dot schrieb:

Man sieht du hast dich ja sehr eingehend mit C++ und der Funktionsweise moderner Compiler auseinandergesetzt

Nein, das habe ich nicht, und das ist auch nicht mein Anliegen.

Der Punkt ist: Wenn du das hättest dann wüsstest du dass moderne C++ Compiler extrem gut Optimieren und dass der Compiler z.B. Konstruktor/Destruktor-Aufrufe wegoptimieren wird wenn diese nicht, z.B. aufgrund irgendwelcher Seiteneffekte, unbedingt nötig sind. Und wenn du die Seiteneffekte brauchst dann hast du den äquivalenten Code auch in Assembler. Compiler sind natürlich nicht perfekt, aber ein moderner C++ Compiler verschwendet in der Regel garantiert nicht unnötig CPU Cycles. Und er ist dabei in der Regel besser als ein normaler Mensch, vorausgestzt der C++ Code ist entsprechend gut. Natürlich kann man in jeder Sprache beliebig schlechten und langsamen Code schreiben, das geht aber auch in Assembler

Aber ja, wenn es um maximale Performance geht dann ist es sicher von Vorteil wenn man Assembler (zumindest lesen) kann, Ahnung von der Hardware hat auf der man läuft und sich in den kritischen Bereichen auch mal anschaut was der Compiler so macht. Falls er da wirklich wo Performance liegen lässt dann wird das in den meisten Fällen an suboptimalem C++ Code liegen (der dem Compiler die Möglichkeit zur Optimierung verwehrt) und sich daher auch auf C++ Ebene beheben lassen. Assembler lesen und verstehen würde ich also als nach wie vor wichtigen Skill in einigen Bereichen ansehen. Wirklich Assembler programmieren dagegen eher kaum.

Abgesehen davon muss aber natürlich irgendwer die Compiler und Optimizer ja auch bauen. Das sind die Orte wo Assembler seinen Platz hat und immer haben wird, keine Frage. Das betrifft aber auch nur ganz wenige Menschen.

Hostfreak schrieb:

Meine ursprüngliche Antwort bezog sich also darauf und ich wollte erläutern, dass optimaler Code im Systembereich von Grossrechnern, auf denen zig Millionen Transaktionen täglich laufen sehr wichtig sind.

Da widerspreche ich nicht. Allerdings sollte auch in diesen Bereichen eine Sprache wie z.B. C++ mit einem vernünftigen Compiler in 99.9999% der Fälle mindestens ausreichende Performance bieten. Wenn dem nicht so wäre dann wären die Server von google oder WoW oder Facebook, oder ... wohl jedenfalls in Assembler geschrieben, was sie aber nicht sind

Hostfreak schrieb:

Aber wie gesagt ganz unten im System... Dort ist Assembler unentbehrlich.

Ja, aber selbst in einem OS Kernel braucht man nur sehr wenige Zeilen Assembler.

[Hostfreak]

dot schrieb:

Hostfreak schrieb:

dot schrieb:

Man sieht du hast dich ja sehr eingehend mit C++ und der Funktionsweise moderner Compiler auseinandergesetzt

Nein, das habe ich nicht, und das ist auch nicht mein Anliegen.

Der Punkt ist: Wenn du das hättest dann wüsstest du dass moderne C++ Compiler extrem gut Optimieren und dass der Compiler z.B. Konstruktor/Destruktor-Aufrufe wegoptimieren wird wenn diese nicht, z.B. aufgrund irgendwelcher Seiteneffekte, unbedingt nötig sind.

Ich wollte jetzt sowas nicht anfangen, aber naja warum nicht.....
Hier ein OO Hallo Welt Programm:

#include <iostream>	
using namespace std;  

class hello_world				// Die wunderbare Klasse
{
	char *hello_world_sample;
public:
	hello_world(void);			// mit zwei Methoden
	char * get_hello_world(void);
};

hello_world::hello_world(void)
{
	hello_world_sample = "Hello world";
	return;
}
char * hello_world::get_hello_world(void)
{
	return (hello_world_sample);
}
int main()
{
hello_world hello_world;
   cout <<  hello_world.get_hello_world() << "\n";
return (0);
}

Da stellen sich mir schon die Nackenhaare
Aber es kommt noch besser - hier der erzeugte Assemblercode mit g++ in Ubuntu 10.4:

.file	"samp.cpp"
	.local	_ZStL8__ioinit
	.comm	_ZStL8__ioinit,1,1
	.section	.rodata
.LC0:
	.string	"Hello world"
	.text
	.align 2
.globl _ZN11hello_worldC2Ev
	.type	_ZN11hello_worldC2Ev, @function
_ZN11hello_worldC2Ev:
.LFB958:
	.cfi_startproc
	.cfi_personality 0x0,__gxx_personality_v0
	pushl	%ebp
	.cfi_def_cfa_offset 8
	movl	%esp, %ebp
	.cfi_offset 5, -8
	.cfi_def_cfa_register 5
	movl	8(%ebp), %eax
	movl	$.LC0, (%eax)
	popl	%ebp
	ret
	.cfi_endproc
.LFE958:
	.size	_ZN11hello_worldC2Ev, .-_ZN11hello_worldC2Ev
	.align 2
.globl _ZN11hello_worldC1Ev
	.type	_ZN11hello_worldC1Ev, @function
_ZN11hello_worldC1Ev:
.LFB959:
	.cfi_startproc
	.cfi_personality 0x0,__gxx_personality_v0
	pushl	%ebp
	.cfi_def_cfa_offset 8
	movl	%esp, %ebp
	.cfi_offset 5, -8
	.cfi_def_cfa_register 5
	movl	8(%ebp), %eax
	movl	$.LC0, (%eax)
	popl	%ebp
	ret
	.cfi_endproc
.LFE959:
	.size	_ZN11hello_worldC1Ev, .-_ZN11hello_worldC1Ev
	.align 2
.globl _ZN11hello_world15get_hello_worldEv
	.type	_ZN11hello_world15get_hello_worldEv, @function
_ZN11hello_world15get_hello_worldEv:
.LFB960:
	.cfi_startproc
	.cfi_personality 0x0,__gxx_personality_v0
	pushl	%ebp
	.cfi_def_cfa_offset 8
	movl	%esp, %ebp
	.cfi_offset 5, -8
	.cfi_def_cfa_register 5
	movl	8(%ebp), %eax
	movl	(%eax), %eax
	popl	%ebp
	ret
	.cfi_endproc
.LFE960:
	.size	_ZN11hello_world15get_hello_worldEv, .-_ZN11hello_world15get_hello_worldEv
	.section	.rodata
.LC1:
	.string	"\n"
	.text
.globl main
	.type	main, @function
main:
.LFB961:
	.cfi_startproc
	.cfi_personality 0x0,__gxx_personality_v0
	pushl	%ebp
	.cfi_def_cfa_offset 8
	movl	%esp, %ebp
	.cfi_offset 5, -8
	.cfi_def_cfa_register 5
	andl	$-16, %esp
	subl	$32, %esp
	leal	28(%esp), %eax
	movl	%eax, (%esp)
	call	_ZN11hello_worldC1Ev
	leal	28(%esp), %eax
	movl	%eax, (%esp)
	call	_ZN11hello_world15get_hello_worldEv
	movl	%eax, 4(%esp)
	movl	$_ZSt4cout, (%esp)
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
	movl	$.LC1, 4(%esp)
	movl	%eax, (%esp)
	call	_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
	movl	$0, %eax
	leave
	ret
	.cfi_endproc
.LFE961:
	.size	main, .-main
	.type	_Z41__static_initialization_and_destruction_0ii, @function
_Z41__static_initialization_and_destruction_0ii:
.LFB965:
	.cfi_startproc
	.cfi_personality 0x0,__gxx_personality_v0
	pushl	%ebp
	.cfi_def_cfa_offset 8
	movl	%esp, %ebp
	.cfi_offset 5, -8
	.cfi_def_cfa_register 5
	subl	$24, %esp
	cmpl	$1, 8(%ebp)
	jne	.L11
	cmpl	$65535, 12(%ebp)
	jne	.L11
	movl	$_ZStL8__ioinit, (%esp)
	call	_ZNSt8ios_base4InitC1Ev
	movl	$_ZNSt8ios_base4InitD1Ev, %eax
	movl	$__dso_handle, 8(%esp)
	movl	$_ZStL8__ioinit, 4(%esp)
	movl	%eax, (%esp)
	call	__cxa_atexit
.L11:
	leave
	ret
	.cfi_endproc
.LFE965:
	.size	_Z41__static_initialization_and_destruction_0ii, .-_Z41__static_initialization_and_destruction_0ii
	.type	_GLOBAL__I__ZN11hello_worldC2Ev, @function
_GLOBAL__I__ZN11hello_worldC2Ev:
.LFB966:
	.cfi_startproc

So und jetzt schauen wir ns das mal an wie man das in Assembler programmiert:

.section .data
hello: .ascii "Hello World!\n"
.section .text
.globl _start
_start:
mov $4, %eax
mov $1, %ebx
mov $hello, %ecx
mov $13, %edx
int $0x80
mov $1, %eax
mov $0, %ebx
int $0x80

Noch Fragen???

[syscall]

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.

[Gast]

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.

[pushlpopl]

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.

[Hostfrak]

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++

[Glashaus]

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".

[Amusement]

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.

[Hostfreak]

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??

[Summertime]

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.

[supernicky]

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.

[masm]

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.