Loht es sich noch ASM zu lernen??
-
Hi,
ich stelle mir die Frage ob es sich überhaupt noch lohnt ASM zu lernen? In der Spieleentwicklung wird ja nur noch DX und OGL benutzt und für berechnungen D3DX funktionen!
Loht es sich überhaupt noch ASM zu lernen, und wenn ja, Wieso?
-
Aber klar lohnt sich das...mir fallen dazu spontan folgende Argumente ein
- man bekommt ein besseres Verständnis von dem was Programme machen (der Compiler macht ja auch nur ein Assembler-Programm aus jedem Source)
- ab und zu kann ein bisschen Verständnis von asm helfen, wenn Programme später als Release-Versionen biem Verrecken nur noch ein paar Mschineninfos ausspucken
- in manchen Programmen kann man noch immer ein wenig tunen indem man kleine Rechenroutinen oder so selber schreibt (z.B. speziell auf SIMD oder ähnliches anpasst)
- Betriebssystemprogrammierung und andere Low-Level-Geschichten benötigen Assembler
- Spätestens wenn du die Ehre hast, mal einen Mikrocontroller zu programmieren, wirst du vermutlich asm programmieren müssen. Ist dann zwar kein x86-Asm aber wenn man das Prinzip von einem kennt, kennt man i.A. vom Prinzip her alle
weitere punkte sind herzlich willkommen
ASM auf dem x86 ist solange man mehr in der Spielebranche bleibt möglicherweise nicht mehr soo stark zu gebrauchen aber zum Verständnis und wenn man an Betriebssystembasteleien geht, kann man ASM auch praktisch gebrauchen.
-
ASM ist sehr gut um codes zum optimieren
vergleiche mal den freeware mpeg 1 & 2 encoder TMPGenc in tema speed
(dieser ist in c++ programmiert 1 pass constant bitrate) = 2 stunden durchlaufzeit
mit dem CCE (Cinema craft encoder)
(dieser ist komplett in assembler programmiert nehmen wir die 9 pass vbr
(variable bitrate) = 1 stunde 45
beim 1 durchläuft er das video nur einmal bild gesehen, analysiert und gerendertbeim cce im 9 pass verfahren läuft er z.b 9 mal durch um die minimale dateigröße und maximale bildqualität herauszuholen
und ist trotzdem nocvh schneller
ASM ist in sachen die sehr zeitkritisch sind unschlagbar
-
Zum optimieren lohnt es sich aber eigentlich nur in bestimmten Fällen, wenn es wirklich sehr kritisch ist oder sehr umständliche Algorithmen benutzt werden, wie beim MP3 Coder.
Ich denke Assembler ist eher interessant, wenn es darum geht zu lernen was genau passiert am Computer und Assembler ist auch beim Debuggen immer wieder nützlich.
Wenn man ein OS oder sehr Maschinennahes Programm (zB. BIOS) schreiben will, kommt man um Assembler kaum herrum.
-
und wer so verrückt ist wie ich, der braucht die ganze schei*e um jitter zu schreiben (ja, damit hab ichs
)
-
Natürlich sind REIN-Assembler-Programme auch viel kleiner als z.B. mit dem BCB geschriebene Programme.
Ein Beispiel:
Ein billiger Texteditor OHNE Suchfunktion benötigt beim BCB6 273 KB.
Das gleiche Schreibprogramm benötigt in REIN-MASM32-Assembler geschrieben nur 16 KB.
-
@mastercpp
Aber Ohne Windowsoberfläche, oder?
-
@hmm: ich wette mit.
-
@hmmm
Mit Windowsoberfläche.
-
Aber die muss man dann aber auch noch selber coden, oder? bzw. ist das Programm dann Plattformunabhängig??
-
er hat doch gesagt, mir Windowsoberfläche, also mit der Oberfläche für Windows. Die muss man auch nicht selber Coden, da man ja auf C Funktionen von Assembler aus ohne Probleme zugreifen kann und so einfach die WinAPI Funktionen nehmen kann.
Natürlich ist das nicht Platformunabhängig (das ist im Asm Forum eh ein Fremdwort ;))
-
Ich dachte immer ASM programme sind die kleinsten, die schnellsten und nebenbei auch Platformunabhängig??
-
-
was denn? ist das nicht so?
-
willst du mich veräppeln? Natürlich ist Assembler nicht Platform unabhängig!
-
ASM ist das platformabhängiste überhaupt
Aber mal ehrlich.
Wenn man Algorithmen in C++ vernünftig performance orientiert, wette ich das der Compiler das vernünftig opimiert und ich wette das du es net schneller hinkriegst.
Ausserdem ist nur wirklich in wenigen Programmen so pingelig notwendig auf die Performance zu achten..
Und der Vergleich CCE und TMPGEnc kann ich net zustimmen.
1. bei mir braucht
CCE 2 Pass: 1 1/2 Stunden
TMPGEnc 2 1/2 Stunden
Wobei CCE die erweiterten Befehlssätze vom P4 nutzt und TMPGEnc nicht!
-
NICHT????????????????????????????????????????????????????????????????????
Ich dachte immer ASM wäre das! Weil ja so viele OS damit gecodet werden!!
-
Assembler ist die Plattformabhängigste Sprache die es gibt.
Aber es ist einfach genial. Ich finde es ist sehr gut geeignet um etwas über die Abläufe im PC zu lernen, wie er funktioniert und was er tut.
Ausserdem sind gut geschriebene Assemblerprogramme sehr klein, und schnell.
Moderne Compilier kommen von der Geschwindigkeit auch schon hart ran, aber wenn´s um direkten Hardwarezugriff geht ist Assembler unschlagbar.
Natürlich hat ASM auch Nachteile.
z.B. ist der Sourcecode bei grösseren Programmen meist schon ein wenig unübersichtlich, aber das kann man auch lösen.
Es gibt keine Einheitliche Syntax bei den "Compilern". Eine Codezeile geht in TASM fehlerfrei, in NASM kann man sie wegwerfen, usw.
Ich versuche gerade Assembler ein bisschen unter Linux einzusetzen, dort verwende ich NASM, angefangen habe ich mit TASM.
Aber wenn man z.B. mit NASM beginnt (der ganz gut und gratis ist) und sich dann später einigermassen gut auskennt kann man ASM noch mit C kombinieren, das ist dann unschlagbar (meiner Meinung nach) sehr schnell, klein, und überschaubar, auch wenn man viel ASM Code hat.Ein ASM Prog für Win32 mit 16KB kann ich mir durchaus vorstellen. Sieht dann etwa so aus wie der Editor von MS nur hat halt wesentlich weniger Funktionen, ist aber schön klein.
Fazit -> Es zahlt sich auf jeden Fall auds ASM zu lernen.
mfg
Noob
-
vielleicht sollte man sich auch noch vor augen halten, das nur höchstens 1 Prozent aller verkauften rechner die sind, die wir alle zu hause stehen haben.
80% sind 8 oder sogar 4 bitter mit nur sehr wenig speicher (ram(rom platte sowieso nicht). und die müssen ja auch irgendwie programmiert werden, da nimmt man dann natürlich asm. ist dann natürlich nicht x86.
wichtig ist halt, was du überhaupt am rechner vorhast, wenn du nur programme für die grossen heimrechner schreiben willst, lass asm weg (optimieren kann man sowieso viel besser anhand des algorithmus, den rest macht dann der compiler).ich stelle mal die behauptung auf, das hier niemand (bis auf die ausnahme) mit einem guten c compiler mithalten kann. nur für ganz kleine routinen mag es sinn machen asm einzusetzen, da gibt es dann aber auch immer schon bibliotheken, die das auch genauso schnell machen und dann sogar für alle möglichen architekturen existieren.
wenn du vorhaben solltest auch mal einen bootsektor oder ein kleines os zu schreiben, dann schau die asm auf alle fälle an.
sollte es wirklich in diese richtung gehen, dann lass dich nicht davon abschrecken, das alle schreien, dass das sowieso nichts wird.
denk dabei an die 80% die ich oben erwähnt habe, die rechner bekommen ja auch ein kleines (minimini) betriebssystem.so, ich hoffe ich bin einigen auf den schlips getreten.
und der rest hat mich hoffentlich verstanden.
über inhaltliche fehler würde ich mich gerne aufklären lassen, bei rechtschreib oder grammatikfehlern verweisse ich an meine deutsch lehrer und innen (die hat damals noch keine pisa auf trab gebracht)ciao k.
-
Original erstellt von Lars Skiba:
ASM ist das platformabhängiste überhaupt
Aber mal ehrlich.
Wenn man Algorithmen in C++ vernünftig performance orientiert, wette ich das der Compiler das vernünftig opimiert und ich wette das du es net schneller hinkriegst.Naja, für manche Sachen ist der Compiler recht blind und das macht nix. Ein paar Zeilen Assembler und er ist geheilt.
Hab folgendes in meinem Code zur Primzahlenberechnung:inline bool isPrimeCheckBelow6(u32 p) {//bei p<=6 einfach nachschauen. //Das Bitmuster ersetzt ein ArrayOfBool. return getBit(0x002c,p);//Nur die Bits 2,3,5 sind gesetzt. }; inline bool isPrimeCheckFactorsBelow6(u32 p) {//Teiler 2,3 und 5 mit einer Division testen return getBit(0x208A2882,p%30);//Nur die Bits 1,7,11... sind gesetzt. }
Ob das ok ist hängt davon ab, wie schnell getBit klappt.
Mitinline bool getBit(u32 data,u32 pos) { __asm mov ebx,dword ptr[pos]; __asm bt dword ptr[data],ebx; __asm setc al; }
kann ich den Compiler drauf schubsen, daß ich es gerne sehen würde, wenn er es mal mit dem Befehl bt versuchen würde. getBit() muß inline sein, damit der Optimierer nachher fein zuschlagen kann und das "setc al; cmp al,al; jnz foo" wieder zu einem "jc foo" kleinhacken kann.