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.
Ich habe von inlineasm gehört. Wird das oft benötigt? Wenn ja wie funktioniert das. Ich habe das Schlüsselwort __asm für vc++ gefunden. Funktioniert aber nicht. Geht das nur auf bestimmten Projekttypen?
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.
Wir benötigen Assembler in unserem OS-Projekt "PrettyOS", z.B. für die Bootloader und auch an anderen Stellen, zum Teil als eigenes Modul in Intel Syntax, aber auch inline als AT&T Syntax. Wir setzen allerdings C bevorzugt ein, sehen Assembler also eher als lästiges Überbleibsel.
_________________ OS-Development-, C++, Win32-API-, MFC-, Chemie-, Robotik- und Flugsimulator-Tutorials
http://www.henkessoft.de/index.htm
Zuletzt bearbeitet von Erhard Henkes am 07:07:17 02.06.2011, insgesamt 1-mal bearbeitet
es kommt immer darauf an, was du programmieren möchtest. in der regel ist es so nicht notwendig, da du alles mit c oder meinetwegen auch c++ machen kannst. der hauptvorteil an assembler ist einfach, daß es schneller läuft, weshalb selbiger (-s?) z.b. in der spieleprogrammierung eingesetzt wird.
das mmn schönste an assembler ist einfach, daß du quasi nebenbei lernst, wie die cpu bzw. der computer intern funktioniert.
falls du ne bücherei in deiner nähe hast, guck doch einfach mal in die diversen bücher zu assembler rein, ansonsten würde ich dir einfach assembler - maschinennahes programmieren von anfang an empfehlen. kostet 12€ und enthält den 8086-befehlssatz, was fürs erste völlig ausreichend ist.
Sowohl Podschun als auch Hyde sind eher sinnlose Lektüre zum Asm-Einstieg. Vor allem Hyde, er geht sowieso nicht sonderlich in die Tiefe, bietet aber stattdessen an, eine neue Grammatik zu lernen, die nix mit Asm zu tun hat. Beim Podschun waren eher die beigelegten .asm files auf dem Datenträger spannend, aber wo ist der oder sind die denn beim E-Book? Die eher interessanteren Feinheiten im Text gehen in einem Art C-Schlauch-Strahl voller abgehobenem Gesülze ziemlich unter.
eher auch nicht wirklich.
Das heißt, man ist (erstmal) gezwungen, sich diesen roten Aufbauplan selbst zu erstellen, mit Hilfe von Disassemblern und einfachen Programmen oder kleinen Assemblersoucecodes und eben den oben genannten Büchern.
Rein lernpraktisch, denke ich mal, sind Assemblergrundlagen viel schneller gelernt als Hochsprachengeschichten, also kein Grund darauf zu verzichten, auch wenn gerade (wie immer) kein "Asm in 21 Tagen" Kurs verfügbar ist.
also übungsaufgaben erhält man sonst im netz und solange man nicht in der lage ist, komplizierteste mathematische berechnungen einzuprogrammieren, braucht man mmn mit weitergehender programmierung gar nicht anzufangen.
also übungsaufgaben erhält man sonst im netz und solange man nicht in der lage ist, komplizierteste mathematische berechnungen einzuprogrammieren, braucht man mmn mit weitergehender programmierung gar nicht anzufangen.
Kannst du das mal etwas genauer ausführen? Folgt man dieser Logik oberflächlich, dann kann man nur zu dem Schluß kommen, das weitergehende Programmierung nur für Meistermathematiker Sinn macht. Aber was meinst du mit "weitergehender programmierung"?
Komplizierteste mathematische Berechnungen programmieren?
nachfeuer,
was ist eigentlich aus deinem interaktiven Einstiegskurs geworden? Bin nämlich immer noch nicht erleuchte hinsichtlich des Begriffes „Multipass“ oder „Mutlipass-Register“!
mit weitergehender programmierung meinte ich beispielsweise gui-programmierung, wie sie in dem von mir genannten buch anhand von windows angerissen wird, oder auch hardwarenahe programmierung.
meistermathematiker mußt du nicht sein, aber summen-, potenz-, bruch-, wurzel- und vektorrechnung sind schon ganz gut, und programme, die nach eingabe einer funktion die drei ableitungen, die stammfunktion und bei bedarf die steigung, die krümmung und das integral (was nach landläufiger ansicht schon meitermathematik ist) ausgeben, tragen sehr gut zur "hirnaktivierung" bei und werden immer gebraucht, sofern man nicht grad nen texteditor programmieren will. es besteht natürlich die möglichkeit, alles in klickibunti zu machen, aber dafür ist visual basic dann besser geeignet.
HansKlaus,
dann zeig doch bitte mal schnell den Code, der Symbolisch integriert oder differenziert.
Ist ja wirklich trivial - selbst mein uralt CAS-Taschenrechner findet, wie natürlich zu erwarten, die Stammfunktionen beliebiger Funktionen.
es geht doch nicht darum, irgendwelche rechenmaschinen neu zu erfinden, sondern darum, das programmieren zu lernen. für irgendwelche algorithmen machst du nachher copy & paste bzw wandelst den pseudo-code dann in assemblersprache, c, oder was auch immer, um, sofern du es denn schon aufwendig machen willst und nicht einfach irgendwelche funktionsbibliotheken verwendest. wenn du von null mit assembler anfangen willst, ist es in meinen augen das beste, erstmal nur zu wissen, was man machen muß, damit zeichenketten von der tastatur eingelesen werden und was man machen muß, damit irgendwelche zeichenketten auf dem bildschirm ausgegeben werden. dann kommt es dran, diese zeichenketten in zahlenwerte umzuwandeln und zahlenwerte in zeichenketten umzuwandeln. danach kommt dann die obengenannte mathematik dran und dann kann man schon behaupten, man könne die grundzüge von assembler.
wenn einen diese dinge nicht interessieren, wäre visual basic mit sql einfach besser, da man damit supergeile programme bauen kann, ohne großartig das rad neu erfinden oder son bißchen unter die haube gucken zu müssen.
Was hat den bitte schon Assembler mit CASs zu tun? Genau - garnichts: so was frickelt man nicht in Assembler zusammen. Auch Ein- und Ausgabe sind nicht sonderlich erhellend, wenn man sich nicht mit der Spezifischen Hardware (datasheets und co.) auseinandersetzen will. Für Anfänger geht es Hauptsächlich darum den Umgang mit Pointer (direkt/indirekte Adressierung), Register, Flags und dem Stack zu erlernen. Die meisten fangen daher an, mit irgendwelchen Schleifenkonstrukten herum zu spielen, in denen irgendwas berechnet und/oder Ein- oder Ausgegeben wird. Um das zu bewerkstelligen, muss man kein CAS &co implementieren können!
Das erste hab ich, dass liest sich aber wie Mist (Muss man ertragen). Nach dem Inhaltsverzeichnis scheinen mir die letzten beiden Bücher Themen an zuschneiden, welche das erste Buch nicht tut (Falls falsch bitte korrigieren^^).
Der größte Mist ist, warum zeigen die alle Beispiele unter DOS? WinAPI gehört ja da rein, aber DOS ist schon längst tot und dabei mit ner DOSBox parallel rumzuspielen ist ziemlich lästig (Finde ich jedenfalls).
Gibt es eig. auch Bücher wo Assembler anhand von AT&T Syntax (Von mir aus auch Intel), glibc und mit gcc Tools gezeigt wird? glibc wäre auch ein guter DOS ersatz, da das auch für windoof portiert ist .
Nur Masochisten quaelen sich heute noch mit Assembler rum. Lass das lieber die paar Spezialisten bei Grosskonzernen machen, die sich damit abgeben MUESSEN.
Letztlich lernt man dabei doch fast nichts, da man das Grundprinzip in einer Stunde verstanden hat und sich dann nur noch mit Mikrodetails wie "Welches Bit muss in welchem Register stehen; In Welchem Register steht der Rueckgabewert" etc. rumplagt. Weder sehr erleuchtend noch spannend.
Nur Masochisten quaelen sich heute noch mit Assembler rum. Lass das lieber die paar Spezialisten bei Grosskonzernen machen, die sich damit abgeben MUESSEN.
Letztlich lernt man dabei doch fast nichts, da man das Grundprinzip in einer Stunde verstanden hat und sich dann nur noch mit Mikrodetails wie "Welches Bit muss in welchem Register stehen; In Welchem Register steht der Rueckgabewert" etc. rumplagt. Weder sehr erleuchtend noch spannend.
jo, wenn ich mir nur eine Stunde zum Assemblerlernen Zeit gelassen hätte, würde ich ganz genauso daherschreiben.
also ich habe jetzt nicht wirklich viel länger (naja vielleicht 3std) für assembler gebraucht. was wirklich zeit frißt, ist eben das "programmieren", sprich die algorithmen und deren umsetzung. ob man jetzt direkt mit assembler anfangen soll, weiß ich nicht, aber als man den computer entwickelt hat, gab es ja auch nur assembler und man war gezwungen, es zu lernen.
ob jetzt "call schreibe_string" in assembler oder "puts()" in c benutzt, ist dabei mmn scheißegal.
also ich habe jetzt nicht wirklich viel länger (naja vielleicht 3std) für assembler gebraucht. was wirklich zeit frißt, ist eben das "programmieren", sprich die algorithmen und deren umsetzung. ob man jetzt direkt mit assembler anfangen soll, weiß ich nicht, aber als man den computer entwickelt hat, gab es ja auch nur assembler und man war gezwungen, es zu lernen.
ob jetzt "call schreibe_string" in assembler oder "puts()" in c benutzt, ist dabei mmn scheißegal.
Stell Dir mal vor in einer Grossbank werden täglich - sagen wir 40 Millionen Datenbankzugriffe (und das ist eher sehr wenig) gemacht. Man kann sich dann recht leicht vorstellen, wie sich jeder unnötige Zyklus der CPU geradezu potenziert. Bei solchen Programmen, die einerseits "transaktionssicher" - andererseits bei jeder Transaktion aufgerufen werden, ist absolute Effizienz das erste Gebot. Man kann zwar mit gewissen Hochsprachen sehr effizient programmieren - C++ oder Java und sonst so überladenen Programmiersprachen haben dort aber nichts verloren...
Also ich hab zwar selber nix in dem Sektor zu tun aber ich hatte schon die ein oder andere Unterhaltung mit Jemandem der hat und ich kann dir versichern dass solche Bankensoftware nicht in Assembler geschrieben wird
_________________ one point of view will never reveal the entire scene.
Zuletzt bearbeitet von dot am 15:04:45 27.06.2011, insgesamt 1-mal bearbeitet
Also ich hab zwar selber nix in dem Sektor zu tun aber ich hatte schon die ein oder andere Unterhaltung mit Jemandem der hat und ich kann dir versichern dass solche Bankensoftware nicht in Assembler geschrieben wird
Naja... hier zwei Links, einer zum Verständinis - der andere für einen Kurs
also ich habe jetzt nicht wirklich viel länger (naja vielleicht 3std) für assembler gebraucht.
Echt? Toll. Könntest du schnell mal aufzeigen, wie du das gemacht hast bzw. wie es funktioniert, innerhalb von 3 Stunden Assembler zu lernen - inklusive complexen Taschenrechnersimulator mit allem Pipapo erstellen. Hier schauen nämlich viele Einsteiger rein und wir könnten sie einfach auf dein elaboriertes Lernkonzept verweisen und hoffen, das die absurdesten Sprüche und dämlichsten Behauptungen hier im Asm-Forum etwas weniger werden.
Echt? Toll. Könntest du schnell mal aufzeigen, wie du das gemacht hast bzw. wie es funktioniert, innerhalb von 3 Stunden Assembler zu lernen - inklusive complexen Taschenrechnersimulator mit allem Pipapo erstellen.
Gehört das dazu? Taschenrechner?
Die 3 Stunden sind Angeberei, aber im Grunde stimmt das doch. Jeder sollte sich IMO die Grundzüge von Assembler aneignen, damit man die Maschine halbwegs versteht und Assembler lesen kann, und dann wieder was anderes machen!
Was ist an C++ so überladen bitte?
Mit Java bin ich d'accord mit dir.
Ich begreife die Frage nicht richtig. Ich kann ne nette lustige Applikation in C++ mit QT oder GTK oder was auch immer schreiben - ich kann ne nette lustige Applikation in Java mit Swingklassen schreiben - wie auch immer. Das hat nichts mit zig Millionen Transaktionen zu tun. Jeder Bankautomat - jede Kassentransaktion - jede interne Buchng - das gesamte HR usw.
Es geht um die Programmierung ganz unten.. also dort wo jede der erwähnten Transaktionen schlussendlich ankommen...
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.. Wer seine Daten im Griff hat und auch im Team benötigt keine Kapselung der Daten... Dieses Problem ist ein Problem aus der Unix und Windows Welt. 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.
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...
_________________ one point of view will never reveal the entire scene.
Zuletzt bearbeitet von dot am 02:12:38 28.06.2011, insgesamt 5-mal bearbeitet
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:
Zitat:
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.
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...
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.
_________________ one point of view will never reveal the entire scene.
Zuletzt bearbeitet von dot am 12:59:44 28.06.2011, insgesamt 7-mal bearbeitet
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:
class hello_world // Die wunderbare Klasse
{
char *hello_world_sample;
public:
hello_world(void); // mit zwei Methoden char * get_hello_world(void);
};
class hello_world // Die wunderbare Klasse
{
char *hello_world_sample;
public:
hello_world(void); // mit zwei Methoden char * get_hello_world(void);
};
class hello_world // Die wunderbare Klasse
{
char *hello_world_sample;
public:
hello_world(void); // mit zwei Methoden char * get_hello_world(void);
};
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.
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:
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.
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:
Wie du siehst alles voll von Konstruktoren, Destruktoren, templates und Funktionen. Und der MSVC 10 macht draus:
Code:
mov eax, 6
ret
Code:
mov eax, 6
ret
Code:
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++
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: [...]
...
_________________ one point of view will never reveal the entire scene.
Zuletzt bearbeitet von dot am 21:26:35 29.06.2011, insgesamt 4-mal bearbeitet
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.
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??
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.
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).
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.
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.
C/C++ Code:
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
int func(int ret=0) {
return ret;
}
int main() {
func(0);
return 0;
}
C/C++ Code:
1 2 3 4 5 6 7 8
int func(int ret=0) {
return ret;
}
int main() {
func(0);
return 0;
}
C/C++ Code:
1 2 3 4 5 6 7 8
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)
.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
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.
Zitat:
- 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.
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.
@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.
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.
Zitat:
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.
Zitat:
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.
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.
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...
_________________ one point of view will never reveal the entire scene.
Zuletzt bearbeitet von dot am 14:43:09 01.09.2011, insgesamt 2-mal bearbeitet
Ich habe mal auf einer CPU Takte für xor gemessen: http://www.c-plusplus.de/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
Das hat nichts mit irgendeinem Glauben zu tun. xor und sub auf das selbe Register haben eine andere Semantik als ein mov 0.
Intel Optimization Manual schrieb:
[...] Furthermore, they do not consume an issue port or an execution unit. So using zero idioms are preferable than moving 0’s into the register. [...]
Assembly/Compiler Coding Rule 36. (M impact, ML generality) Use dependency-breaking-idiom instructions to set a register to 0, or to break a false dependence chain resulting from re-use of registers.
_________________ one point of view will never reveal the entire scene.
Zuletzt bearbeitet von dot am 21:15:48 01.09.2011, insgesamt 2-mal bearbeitet
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...
Der (code-) cache ist stetig mit den CPU Generationen gewachsen und, gemäß sein Natur, auch sein Geschwindigkeit. Auser in sehr kleine Schleifen (<= 32Byte), machte meiner Erfahrung nach die Befehlsgröße keinen Unterschied mehr. Typisches Beispiel: add eax,1 und inc eax ... wenn man nicht grade für den Pentium 4 programmiert, ist reine Geschmackssache – einen Geschwindigkeitsunterscheide habe ich in (sinnvollen) Algorithmen noch nie festgestellt (genau wie bei XOR vs. MOV).
Intel sieht das anders. Nicht nur bei xor vs. mov, sondern auch bei inc vs add:
Intel Optimization Manual schrieb:
Assembly/Compiler Coding Rule 33. (M impact, H generality) INC and DEC instructions should be replaced with ADD or SUB instructions, because ADD and SUB overwrite all flags, whereas INC and DEC do not, therefore creating false dependencies on earlier instructions that set the flags.
Ich würde mal sagen, gerade in kleinen Schleifen machts keinen Unterschied, weil der ganze Code sowieso im Cache bleibt. Interessant wird das, wenn man mal das Programm als ganzes betrachtet. Die Caches sind nicht wirklich soviel größer, eine SandyBridge CPU hat sogar einen kleineren L2-Cache als mancher Pentium 4. Und selbst wenn, der Speicher ist trotzdem nicht wirklich schneller geworden. Außerdem ist der unterste Cache normalerweise shared und muss alle Cores füttern (mittlerweile gibts da ja mehr als einen von). Und das Problem ist auch nicht der Cache, sondern alles was nicht im Cache ist
_________________ one point of view will never reveal the entire scene.
Zuletzt bearbeitet von dot am 22:48:16 01.09.2011, insgesamt 8-mal bearbeitet
Naja, logisch verknüpfte Operationen wie xor und co gehören natürlich zum Allerletzten, was man bei der Asm-Programmierung lernt, falls überhaupt...Und es hat vermutlich auch noch nie Leute gegeben, die Assembler direkt über den C-Compiler gelernt haben...
Muss das jetzt eigentlich sein, dass ihr euch an so einem Quark festbeißen müsst?
mov ax,0 wird auch gerne für Anfänger geschrieben, die noch gar keine logischen-Verknüpf-Asm-Befehle kennen oder vielleicht um die Lesbarkeit des Codes hier und da zu erleichtern. Früher, in DOS-286 Zeiten, waren xor Befehle schneller, aber mit dem Pentium und stärkerer Risc-Bauform spielen ganz andere Punkte eine Rolle.
Ethon liegt mehrfach daneben, u.a., wie oben schon erwähnt und mit der Annahme, dass heutzutage mit Asm in 286er Realmode Zeit und auf Anfängerniveau programmiert wird und dagegen mit C++ in 2011 mit Performanceoptimierern und Profilern. Viele Asm-Einführungen arbeiten mit Dos auf 286er Niveau und Realmode, einfach, weil es fundamentale Grundlagen sind, die man schnell lernt und die sich relativ einfach auf neuere Entwicklungen übertragen lassen. Das ist so ähnlich, wie wenn beim C++ Anfang nur Konsoleprogramme geschrieben werden. Daraus eine Philosophie über Assembler vs C++ zu entwickeln ist dann so ähnlich tiefschürfend, als würde man schreiben, mit Blitzbasic lassen sich tolle Spiele entwickeln, mit C++ nur Konsolezeugs.
Es ist auch ein Irrtum, zu glauben, dass Assemblerprofis nur in Assembler programmieren und nicht wüßten, was so ein C-Compiler rausspuckt oder umgekehrt, dass gute C-Profis kein Assembler könnten oder bräuchten.
Naja, logisch verknüpfte Operationen wie xor und co gehören natürlich zum Allerletzten, was man bei der Asm-Programmierung lernt, falls überhaupt...Und es hat vermutlich auch noch nie Leute gegeben, die Assembler direkt über den C-Compiler gelernt haben...
Hey, xor war doch nur ein Beispiel.
Es geht mir einfach um Dinge, die als Mensch nicht direkt intuitiv wirken, gibt ja viel wüstere Dinge, die ein Compiler anstellt.
Zitat:
dass heutzutage mit Asm in 286er Realmode Zeit und auf Anfängerniveau programmiert wird und dagegen mit C++ in 2011 mit Performanceoptimierern und Profilern.
Gibt es denn optimierende Assembler? Wüsste nicht davon, mal einen gesehen zu haben.
Und nein, so schlecht hab ich Assembler nicht dargestellt, und wenn doch, wars nicht beabsichtigt.
Zum Rest: Ich kann durchaus Assembler, Reverse Engineering ist ein Hobby von mir. Trotzdem sehe ich mich durchaus in der Lage C++ Code zu schreiben, der ASM-Code in Sachen Performance nicht nachsteht.
Der einzige Standpunkt, der hier von mir vertreten wird, ist dass ASM kein Muss für möglichst performanten Code ist, mehr nicht.
Gibt es denn optimierende Assembler? Wüsste nicht davon, mal einen gesehen zu haben.
Das überrascht leider nicht, denn man sieht den optimierenden Teil in aller Regel im Spiegel.
Ethon_notloggedin schrieb:
Zum Rest: Ich kann durchaus Assembler, Reverse Engineering ist ein Hobby von mir. Trotzdem sehe ich mich durchaus in der Lage C++ Code zu schreiben, der ASM-Code in Sachen Performance nicht nachsteht.
Sag ich doch. Und es ist auch logisch. Du benutzt einen C++ Compiler, der etliche Effizienzevolutionen hinter sich hat, und setzt deine eigenen gegen Null tendierenden Assemblerprogrammierkenntnisse dagegen. (Also wenn dich schon xors im Compilerout überraschen... )
Das einzige Heilmittel dagegen ist, mehr zu lernen und mehr zu üben. Ob nun C++, Java oder Assembler, das ist schnuppe. Aber je mehr du weißt(und abguckst) und je mehr du geübt hast, desto effektiveren Code kannst du programmieren.
Es ist aber nicht wirklich schlimm, wenn man mal von Vorurteil zu Vorurteil hier im Asm-Forum hoppelt, das ist das normalste von der Welt
Ich finde den Vergleich von Assembler und anderen Hoch-Sprachen ziemlich witzlos.
Als Mensch, z.B. das Intel-Compiler-Optimizer-Team, hat man theoretisch immer die Möglichkeit die CPU besser auszunutzen als ein Optimizer, da man Sinn und Ziel vom Code kennt.
Kein Mensch kommt aber auf die Idee für den PC (Win,Linux,...) eine Applikation in Assembler zu entwickeln.
Anders sieht das in der Industrie aus, wenn eine selbstentwickelte Hardware, mit irgendeiner CPU/GPU/DSP,..., womöglich ohne eigenes Betriebsystem, zigtausendmal verkauft werden soll. Da macht man mal eine Abschätzung wie viel Rechenleistung gebraucht wird und kommt nach Jahren dann doch an die Grenzen, weil es ständig neue Ideen und Wünsche gibt. Da kommen durchaus Überlegungen auf mit Assembler das letzte rauszuholen, wohl dem der jemand hat, der das kann. Deshalb gehört das in der technischen Informatik auch zu den Basics.
Siehst du, hier ist auch wieder einer, der Vorurteile über Assembler verbreitet, weil er nichts oder nur wenig weiß:
1)
Wurst schrieb:
Ich finde den Vergleich von Assembler und anderen Hoch-Sprachen ziemlich witzlos.
Verschiedene Sprachen sind für unterschiedliche Dinge gut, und je besser man den Unterschied kennt, desto sinnvoller kann man unterschiedliche Sprachen einsetzen. Aber man kann nicht alles über alle Sprachen wissen und je besser man in Sprache X ist, desto weniger (oder mehr, je nachdem) braucht man eine andere Sprache, weiß aber gleichzeitig um so besser, für welchen Einsatzzweck X nicht optimal ist.
2)
Wurst schrieb:
Als Mensch, z.B. das Intel-Compiler-Optimizer-Team, hat man theoretisch immer die Möglichkeit die CPU besser auszunutzen als ein Optimizer, da man Sinn und Ziel vom Code kennt.
Das Intel-Compiler-Optimizer-Team hat auch nicht die Weisheit mit Löffeln gefressen, wenn es z.B. um Parallelperformance geht. Bei Multicores(z.B. mehr als 16) dürfte es sogar recht schwierig und mühsam sein, die etwa Verzahnung der Befehlsketten von Hand einzustellen. Aber das Intel-Optimizer-Team hat Werkzeuge zum Optimieren, wie Profiler und Thread-Debugger und Optimierzeugs usw., die auch jeder andere nutzen kann, um seinen Code zu optimieren und schnelle Compiler und Libs, die auch jeder (zumindest zahlend) sich zu nutze machen kann. Wenn alle Welt vor Asm davonläuft, ist es natürlich um so leichter, mit Optimierungen jenseits der Algorithmenebene auf den Markt zu kommen. Übung und Know How ist der springende Punkt, nicht das Vorurteil
3)
Wurst schrieb:
Kein Mensch kommt aber auf die Idee für den PC (Win,Linux,...) eine Applikation in Assembler zu entwickeln.
Das ist auch schon wieder falsch, und das kann auch nur einer schreiben, dem die Möglichkeiten neuerer Assembler überhaupt nicht bekannt sind, geschweige denn, sie zu nutzen weiß.
Assembler wie fasm ( http://www.flatassembler.net/ )
oder RosAsm oder Betriebsysteme wie MenuetOS ( http://menuetos.net/ ) oder Linker wie http://www.digitalmars.com/ctg/optlink.html wurden z.B. in Assembler entwickelt. In Linux gibt es das beliebte Programm Midnight Commander (siehe dazu http://www.softpanorama.org/OFM/Paradigm/Ch04/mc.shtml).
Das Original, der Norton Commander wurde in reinem und recht einfachem Assembler entwickelt. Der MC selbst wurde nicht in Assembler gecodet daher auch
etwas viel Hickack, das Ding für Linux umzusetzen. Letztlich: Es ist ein ursprünglich mit Assembler entwickeltes Tool, welches sich dieser Beliebtheit(durchaus noch immer) in der Linuxwelt erfreut.
4)
Wurst schrieb:
Anders sieht das in der Industrie aus, wenn eine selbstentwickelte Hardware, mit irgendeiner CPU/GPU/DSP,..., womöglich ohne eigenes Betriebsystem, zigtausendmal verkauft werden soll. Da macht man mal eine Abschätzung wie viel Rechenleistung gebraucht wird und kommt nach Jahren dann doch an die Grenzen, weil es ständig neue Ideen und Wünsche gibt. Da kommen durchaus Überlegungen auf mit Assembler das letzte rauszuholen..
Auch viel zu allgemein und eher daneben. In der Industrie zählt vor allem, was wirtschaftlich ist, und da kommt es meist auf den Einzelfall an, was jetzt wo wie eingesetzt wird. In gewisserweise haben dort alle Sprachen ihre Berechtigung, also nicht unbedingt das passende Argument für oder gegen irgendeine Sprache.
Stell Dir mal vor in einer Grossbank werden täglich - sagen wir 40 Millionen Datenbankzugriffe (und das ist eher sehr wenig) gemacht. Man kann sich dann recht leicht vorstellen, wie sich jeder unnötige Zyklus der CPU geradezu potenziert. Bei solchen Programmen, die einerseits "transaktionssicher" - andererseits bei jeder Transaktion aufgerufen werden, ist absolute Effizienz das erste Gebot. Man kann zwar mit gewissen Hochsprachen sehr effizient programmieren - C++ oder Java und sonst so überladenen Programmiersprachen haben dort aber nichts verloren...
Ich kenne da einen der bei einer Bank genau in dem Bereich arbeitet. Laut seiner Aussage werden alle Transaktionen in Sp´s umgesetzt. Andere Programmierung erfolgt wenn dann in Java oder vergleichbar abstrahierten Sprachen. Sicherheit geht da ganz klar über Performance, zumal da diverse unterschiedliche Systeme eingesetzt werden.
ASM würde mich informell interesieren, um damit zu arbeiten muß man glaub ich ziemlich freaky sein. Bzw man muß nicht allss können, ein kleiner Einblick reicht aber.
Einmal zu OPTLINK. Es stimmt, das Ding war tatsächlich vollständig in Assembler geschrieben. Aus verschiedenen Gründen hat Walter Bright aber entschieden, OPTLINK zumindest langfristig nach C zu portieren. (Damit niemand durcheinanderkommt: Ursprünglich stammt OPTLINK im Wesentlichen von Steve Russell; benutzt wurde er dann innerhalb des C++-Compilers "Zortech C++" -> "Symantec C++" -> "DigitalMars". Dieser Compiler stammt von Walter Bright. Walter Bright beschäftigt sich also mit "fremdem", hochoptimiertem Assembler-Code, der somit natürlich ziemlich schwer zu verstehen ist.)
Seine Bemühungen hat er hier dokumentiert: http://drdobbs.com/blogs/architecture-and-design/228701319
Dann zum "optimierenden Assembler": Man kann das sinnlos finden (braucht hier sicherlich auch nicht diskutiert zu werden), aber interessehalber: Randall Hyde, der den HLA (High-Level Assembler) entwickelt, plant für zukünftige Versionen einen Optimierer. Hinweise und Andeutungen in diese Richtung:
Vielleicht ist diese "schlechte Angewohnheit" von MASM schon ein Zeichen für Optimierungsversuche von MASM? Und dann heißt es in der Antwort u.a.:
"In general, I have plans of adding a data flow analyzer and an optimizer around version three of HLA. While I certainly intend to provide source level control of the optimizer, if you are offended by an assembler that plays with your source code, then HLA is not for you. On the other hand, if you would like to be able to write readable code and leave it up to the compiler to deal with instruction scheduling and peep-hole optimizations, HLA will be a big win."
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...
Der (code-) cache ist stetig mit den CPU Generationen gewachsen und, gemäß sein Natur, auch sein Geschwindigkeit. Auser in sehr kleine Schleifen (<= 32Byte), machte meiner Erfahrung nach die Befehlsgröße keinen Unterschied mehr.
Ich denke das der Cache(Code+Daten) auf 64Bit-x86 gerne noch etwas grösser sein sollte, weil im 64 Bit-Mode der Cache sich um ein vielfaches schneller füllt als im 16/32 Bit-Mode und deren kleineren Adressen und Register+Werte.
Zitat:
Typisches Beispiel: add eax,1 und inc eax ... wenn man nicht grade für den Pentium 4 programmiert, ist reine Geschmackssache – einen Geschwindigkeitsunterscheide habe ich in (sinnvollen) Algorithmen noch nie festgestellt (genau wie bei XOR vs. MOV).
Verwendet man in einem Code das EAX-Register und möchte danach das AX-Register mit einem Wert beschreiben, dann ist es sinnvoll das EAX-Register mit "xor eax,eax" zu löschen, noch bevor man ein Wert nach AX schreibt.
...
Es gibt verschiedene Möglichkeiten zur Optimierung.
Von sehr grosser Bedeutung ist es darauf zu achten, dass Speicherzugriffe nach Möglichkeit richtig ausgerichtet sind. D.h. WORD-Zugriffe sollten auf gerade Adressen erfolgen welche durch 2 teilbar sind und DWORD-Zugriffe auf Adressen die durch 4 teilbar sind usw..
...
Wenn man ein Register beschreibt und unmittelbar danach auf das selbe Register ein Lesezugriff erfolgt, dann gibt es eine Verzögerung, weil sich so eine Kombination nur schlecht paralell ausführen läßt. (Der XOR-Befehl macht hier eine Ausnahme.)
(Die Intel Core2-Architektur kann beispielsweise 4 Integer-Befehle paralell ausführen. Und das Register-renaming und das Zerlegen in Micro-Ops hat auch seine Grenzen.)
Je nachdem wie viele Befehle gleichzeitig von der jeweiligen CPU abgearbeitet werden können und wieviele Teilstufen dabei intern von der CPU benutzt werden bis ein Befehl vollständig ausgeführt wird und welche Abhängigkeiten zwischgen den Befehlen bestehen, desto großer sollte der Abstand zwischen jenen Befehlen sein welche in einer Register-Abhängigkeit stehen.
...
Anstelle von "add, eax, 1", oder "inc eax" könnte man auch ein "lea eax, [eax+1]" verwenden. Wenn noch weitere Register, oder Werte hinzuaddiert, oder ein Register mit 2,4, oder 8 multipliziert werden soll, dann bringt der einzelne LEA-Befehl noch mehr Vorteile gegenüber mehrerer anderer Befehle.
...
Anstelle von einer Kombination aus push/pop-Befehlen kann man auch mov/mov-Befehle verwenden. Ein Pentium 4 verarbeitet pop/push-Befehle schneller als mov/mov-Befehle, andere CPUs verarbeiten mov/mov-Befehle schneller als push/pop-Befehle.
Jeder der es möchte kann es auf seiner eigenen CPU gerne einmal ausprobieren und es selber messen, ob die Kombination aus push/pop, oder die Kombination aus mov/mov schneller abgearbeitet wird.
Zu diesem Zweck hat "Frank Kotler" eine entsprechende Testroutine(für Linux und NASM) geschrieben:
https://groups.google.com/group/alt.lang.asm/brows ....... hl=de&lnk=gst&q=pushvsmov#de738e9275a9abc7
Etwas abgewandelt läßt sich dieses Beispiel auch für rinige andere Codeoptimierungen verwenden.
Neben den Anleitungen von Intel und AMD worin jeweils die Optimierung deren CPU-Modelle relativ anschaulich mit Beispielen erläutert wird habe ich auf die mal gesucht und etwas darüber gefunden:
Assembly Optimization Tips by Mark Larson
http://www.mark.masmcode.com/
proc WindowProc hwnd,wmsg,wparam,lparam
push ebx esi edi
cmp [wmsg],WM_CREATE
je .wmcreate
cmp [wmsg],WM_SIZE
je .wmsize
cmp [wmsg],WM_SETFOCUS
je .wmsetfocus
cmp [wmsg],WM_COMMAND
je .wmcommand
cmp [wmsg],WM_DESTROY
je .wmdestroy
.defwndproc:
invoke DefWindowProc,[hwnd],[wmsg],[wparam],[lparam]
jmp .finish
.wmcreate:
invoke GetClientRect,[hwnd],client
invoke CreateWindowEx,WS_EX_CLIENTEDGE,_edit,0,WS_VISIBLE+WS_CHILD+WS_HSCROLL+WS_VSCROLL+ES_AUTOHSCROLL+ES_AUTOVSCROLL+ES_MULTILINE,[client.left],[client.top],[client.right],[client.bottom],[hwnd],0,[wc.hInstance],NULL
or eax,eax
jz .failed
mov [edithwnd],eax
invoke CreateFont,16,0,0,0,0,FALSE,FALSE,FALSE,ANSI_CHARSET,OUT_RASTER_PRECIS,CLIP_DEFAULT_PRECIS,DEFAULT_QUALITY,FIXED_PITCH+FF_DONTCARE,NULL
or eax,eax
jz .failed
mov [editfont],eax
invoke SendMessage,[edithwnd],WM_SETFONT,eax,FALSE
xor eax,eax
jmp .finish
.failed:
or eax,-1
jmp .finish
.wmsize:
invoke GetClientRect,[hwnd],client
invoke MoveWindow,[edithwnd],[client.left],[client.top],[client.right],[client.bottom],TRUE
xor eax,eax
jmp .finish
.wmsetfocus:
invoke SetFocus,[edithwnd]
xor eax,eax
jmp .finish
.wmcommand:
mov eax,[wparam]
and eax,0FFFFh
cmp eax,IDM_NEW
je .new
cmp eax,IDM_ABOUT
je .about
cmp eax,IDM_EXIT
je .wmdestroy
jmp .defwndproc
.new:
invoke SendMessage,[edithwnd],WM_SETTEXT,0,0
jmp .finish
.about:
invoke MessageBox,[hwnd],_about_text,_about_title,MB_OK
jmp .finish
.wmdestroy:
invoke DeleteObject,[editfont]
invoke PostQuitMessage,0
xor eax,eax
.finish:
pop edi esi ebx
ret
endp
section '.data' data readable writeable
_title TCHAR 'MiniPad',0
_about_title TCHAR 'About MiniPad',0
_about_text TCHAR 'This is Win32 example program created with flat assembler.',0
_error TCHAR 'Startup failed.',0
proc WindowProc hwnd,wmsg,wparam,lparam
push ebx esi edi
cmp [wmsg],WM_CREATE
je .wmcreate
cmp [wmsg],WM_SIZE
je .wmsize
cmp [wmsg],WM_SETFOCUS
je .wmsetfocus
cmp [wmsg],WM_COMMAND
je .wmcommand
cmp [wmsg],WM_DESTROY
je .wmdestroy
.defwndproc:
invoke DefWindowProc,[hwnd],[wmsg],[wparam],[lparam]
jmp .finish
.wmcreate:
invoke GetClientRect,[hwnd],client
invoke CreateWindowEx,WS_EX_CLIENTEDGE,_edit,0,WS_VISIBLE+WS_CHILD+WS_HSCROLL+WS_VSCROLL+ES_AUTOHSCROLL+ES_AUTOVSCROLL+ES_MULTILINE,[client.left],[client.top],[client.right],[client.bottom],[hwnd],0,[wc.hInstance],NULL
or eax,eax
jz .failed
mov [edithwnd],eax
invoke CreateFont,16,0,0,0,0,FALSE,FALSE,FALSE,ANSI_CHARSET,OUT_RASTER_PRECIS,CLIP_DEFAULT_PRECIS,DEFAULT_QUALITY,FIXED_PITCH+FF_DONTCARE,NULL
or eax,eax
jz .failed
mov [editfont],eax
invoke SendMessage,[edithwnd],WM_SETFONT,eax,FALSE
xor eax,eax
jmp .finish
.failed:
or eax,-1
jmp .finish
.wmsize:
invoke GetClientRect,[hwnd],client
invoke MoveWindow,[edithwnd],[client.left],[client.top],[client.right],[client.bottom],TRUE
xor eax,eax
jmp .finish
.wmsetfocus:
invoke SetFocus,[edithwnd]
xor eax,eax
jmp .finish
.wmcommand:
mov eax,[wparam]
and eax,0FFFFh
cmp eax,IDM_NEW
je .new
cmp eax,IDM_ABOUT
je .about
cmp eax,IDM_EXIT
je .wmdestroy
jmp .defwndproc
.new:
invoke SendMessage,[edithwnd],WM_SETTEXT,0,0
jmp .finish
.about:
invoke MessageBox,[hwnd],_about_text,_about_title,MB_OK
jmp .finish
.wmdestroy:
invoke DeleteObject,[editfont]
invoke PostQuitMessage,0
xor eax,eax
.finish:
pop edi esi ebx
ret
endp
section '.data' data readable writeable
_title TCHAR 'MiniPad',0
_about_title TCHAR 'About MiniPad',0
_about_text TCHAR 'This is Win32 example program created with flat assembler.',0
_error TCHAR 'Startup failed.',0
proc WindowProc hwnd,wmsg,wparam,lparam
push ebx esi edi
cmp [wmsg],WM_CREATE
je .wmcreate
cmp [wmsg],WM_SIZE
je .wmsize
cmp [wmsg],WM_SETFOCUS
je .wmsetfocus
cmp [wmsg],WM_COMMAND
je .wmcommand
cmp [wmsg],WM_DESTROY
je .wmdestroy
.defwndproc:
invoke DefWindowProc,[hwnd],[wmsg],[wparam],[lparam]
jmp .finish
.wmcreate:
invoke GetClientRect,[hwnd],client
invoke CreateWindowEx,WS_EX_CLIENTEDGE,_edit,0,WS_VISIBLE+WS_CHILD+WS_HSCROLL+WS_VSCROLL+ES_AUTOHSCROLL+ES_AUTOVSCROLL+ES_MULTILINE,[client.left],[client.top],[client.right],[client.bottom],[hwnd],0,[wc.hInstance],NULL
or eax,eax
jz .failed
mov [edithwnd],eax
invoke CreateFont,16,0,0,0,0,FALSE,FALSE,FALSE,ANSI_CHARSET,OUT_RASTER_PRECIS,CLIP_DEFAULT_PRECIS,DEFAULT_QUALITY,FIXED_PITCH+FF_DONTCARE,NULL
or eax,eax
jz .failed
mov [editfont],eax
invoke SendMessage,[edithwnd],WM_SETFONT,eax,FALSE
xor eax,eax
jmp .finish
.failed:
or eax,-1
jmp .finish
.wmsize:
invoke GetClientRect,[hwnd],client
invoke MoveWindow,[edithwnd],[client.left],[client.top],[client.right],[client.bottom],TRUE
xor eax,eax
jmp .finish
.wmsetfocus:
invoke SetFocus,[edithwnd]
xor eax,eax
jmp .finish
.wmcommand:
mov eax,[wparam]
and eax,0FFFFh
cmp eax,IDM_NEW
je .new
cmp eax,IDM_ABOUT
je .about
cmp eax,IDM_EXIT
je .wmdestroy
jmp .defwndproc
.new:
invoke SendMessage,[edithwnd],WM_SETTEXT,0,0
jmp .finish
.about:
invoke MessageBox,[hwnd],_about_text,_about_title,MB_OK
jmp .finish
.wmdestroy:
invoke DeleteObject,[editfont]
invoke PostQuitMessage,0
xor eax,eax
.finish:
pop edi esi ebx
ret
endp
section '.data' data readable writeable
_title TCHAR 'MiniPad',0
_about_title TCHAR 'About MiniPad',0
_about_text TCHAR 'This is Win32 example program created with flat assembler.',0
_error TCHAR 'Startup failed.',0
Nächstes Thema anzeigen Vorheriges Thema anzeigen
Sie können Beiträge in dieses Forum schreiben. Sie können auf Beiträge in diesem Forum antworten. Sie können Ihre Beiträge in diesem Forum nicht bearbeiten. Sie können Ihre Beiträge in diesem Forum nicht löschen. Sie können an Umfragen in diesem Forum nicht mitmachen.
c++.de ist Teilnehmer des Partnerprogramms von Amazon Europe S.à.r.l. und Partner des Werbeprogramms, das zur Bereitstellung eines Mediums
für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu amazon.de
Werbekostenerstattung verdient werden kann.
Die Vervielfältigung der auf den Seiten www.c-plusplus.de, www.c-plusplus.info, www.c-sar.de, www.c-plusplus.net und www.baeckmann.de
enthaltenen Informationen ohne eine schriftliche Genehmigung des Seitenbetreibers ist untersagt
(vgl. §4 Urheberrechtsgesetz). Die Nutzung und Änderung der vorgestellten Strukturen und Verfahren in
privaten und kommerziellen Softwareanwendungen ist ausdrücklich erlaubt, soweit keine Rechte Dritter verletzt werden.
Der Seitenbetreiber übernimmt keine Gewähr für die Funktion einzelner Beiträge oder Programmfragmente, insbesondere
übernimmt er keine Haftung für eventuelle aus dem Gebrauch entstehenden Folgeschäden.
Twitter
Facebook
. Danke. 
