Archiv verlassen und diese Seite im Standarddesign anzeigen : Assembler
xaverseppel
2004-02-27, 12:47:08
Wollte mal fragen für was Assembler-Programmierung gut ist. Weil wir das gerade in der Schule lernen und ich einfach mal wissen wollte, ob man das irgendwo nochmal gebrauchen kann!
zum cracken von kopierschutz. :D
Assembler Programmierung ist immer spezifisch für die Prozessorarchitektur, wenn man auf Z80 Asm lernt kann man das nicht direkt auf X86 übertragen und umgekehrt.
Wenn man einen Compiler oder ein OS programmieren will muss man Asm können, ansonsten ist es nur ganz nett um sich anzugucken ob ein Compiler aus deinen Befehlen guten Machienencode macht.
xaverseppel
2004-02-27, 13:45:50
also brnigt es in bestimmten richtung schon etwas wenn man es kann!
Lokadamus
2004-02-27, 13:55:41
mmm...
Du kannst Assembler auch jederzeit in die "normalen" Programmiersprachen einbinden, allerdings mögen die meisten Compiler das nicht so gerne, weil sie dann selber einiges nicht mehr optimieren können. Teilweise erreicht man durch ASM eine bessere Performence, aber es ist immernoch die Frage, ob sich der Einsatz von Asm in einer höheren Sprache lohnt (nur wenn es um pure Performence geht und/ oder der Aufwand nicht zuviel Zeit kostet) ... ansonsten ist es ein gutes Hintergrundwissen, um die Sachen wie Pointer besser zu verstehen oder Fehler zu vermeiden, bzw. den Grund dafür zu erkennen ...
Viele Programmierer brauchen das nie in ihrem Leben....
Wenn du allerdings Geschwindigkeit brauchst kommst du mehr oder weniger nicht drumrum. Die meisten C-Compiler bieten dir in direkten Zugriff ueber Intrinsics, die das ganze gut wartbar und uebersichtlich machen ohne an Geschwindigkeit zu verlieren...
Assembler hat zwar schon seine Daseinsberechtigung, ist aber für den "normalsterblichen" Programmierer absolut uninteressant. Wenn das irgendwo gebraucht wird, lernt man's eben extra.
Assembler wird zum Beispiel vornehmlich benutzt, um Microcontroller zu programmieren, da dort Speicher und Leistung stark begrenzt sind und man nur somit den Code optimal auf die Architektur optimiren kann.
Mit den leistungsfähigeren Microcontrollern stirbt allerdings Assembler auch in diesem Bereich langsam aus und wird durch C ersetzt.
-huha
Metal Maniac
2004-02-27, 22:18:39
Ich kann mal zusammenfassen, was in der Einleitung unserer Vorlesung "Maschinennahe Programmierung" steht:
Gründe für Assembler:
- Assembler ist die Sprache der Prozessoren; um Vorgänge im Rechner zu verstehen, muss man Assembler verstehen
- einige sehr maschinennahe Operationen können nicht in geläufigen Programmiersprachen beschrieben werden
- bei extremen Echtzeit-Bedingungen kommt man nicht umhin, kleine, extrem zeitkritische Programme in Assembler zu erstellen
- Mikrocontroller in Massenprodukten besitzen meist wenig Speicher; zeitaufwendige Programmierung in Assembler ist somit bei hohen Stückzahlen billiger als zusätzlichen externen Speicher hinzuzufügen
xaverseppel
2004-02-27, 22:30:51
danke schön für die vielen erklärungen! jetzt weiß ich wenigesten bescheid wofür man es gebrauchen kann! ;D
Matti
2004-03-01, 16:03:02
daß man mit ASM sehr kleine Programme schreiben kann (<100 Bytes), ist mir klar. Aber von der Performance her ist ASM afaik nicht unbedingt besser, als der Code von einem gut optimierenden Compiler. Jedenfalls muß man schon ein ASM-Voll-Profi sein, um schnelleren Code zu erzeugen.
micki
2004-03-01, 16:33:50
Original geschrieben von Matti
daß man mit ASM sehr kleine Programme schreiben kann (<100 Bytes), ist mir klar. Aber von der Performance her ist ASM afaik nicht unbedingt besser, als der Code von einem gut optimierenden Compiler. Jedenfalls muß man schon ein ASM-Voll-Profi sein, um schnelleren Code zu erzeugen.
wenn man kein profi ist, dann erstellt man ja auch mit java schnellere programme als mit c++;
man muss schon genau wissen was man macht, damit es besser wird als eine optimierte generische lösung.
MfG
micki
Matti
2004-03-01, 17:51:26
Original geschrieben von micki
wenn man kein profi ist, dann erstellt man ja auch mit java schnellere programme als mit c++;
Java KANN gar nicht schneller sein als C, weil Java interpretiert wird! ...und wenn doch, hat man einen sehr schlechten C-Compiler.
Java wird nicht interpretiert und es gibt viel bessere Gründe dafür Java nicht zu benutzen als Performance.
Bei ganz einfachen Programmen (for-schleife mit irgendwelchen sehr einfachen Rechnungen) ist Java innerhalb von 10% mit C, auch bei maximaler Optimierung bei C.
Matti
2004-03-01, 18:07:45
stimmt schon, daß Java in manchen Fällen kaum langsamer als C ist, aber Java ist nie schneller.
Java ist ein Bytecode-Interpreter. D.h. der Quellcode wird zu einem schneller interpretierbaren Code compiliert, der dann bei der Ausführung interpretiert wird. Dadurch wird's zwar etwas langsamer als C, aber es ist (theoretisch) plattformunabhängig und wesentlich schneller als voll-interpretierte Sprachen.
micki
2004-03-01, 18:24:33
das hatten wir hier schon öfters, java kann interpretiert werden, wird aber zumeißt mit einem JIT (just in time compiler) für die hardware compiliert, du kannst mit gcc java als ganz normale executable erstellen lassen und laut den c't benches bei denen die sehr viele lame bugs hatten, war java öfters schneller.
MfG
micki
Matti
2004-03-01, 18:31:46
was sind Lame-Bugs? ...sicherlich meinst du nicht Fehler im MP3-Encoder ;)
micki
2004-03-01, 19:48:25
klassen by value und nicht bei const referenz zu übergeben und andere kleinigkeiten die sich sehr summieren...
MfG
micki
govou
2004-03-01, 21:38:14
Wenn du mal ein gescheiten Emulator schreibst, wäre asm auch nicht verkehrt (Inline-Assembler)
Kinman
2004-03-01, 22:56:12
oder z.T. auch für shader programmierung ;)
mfg Kinman
micki
2004-03-01, 23:10:21
was auch sehr wichtig ist, ist um zu wissen was der compiler gemacht hat.
z.b.
http://www.flipcode.com/tutorials/tut_fastmath.shtml
manchmal castet der compiler auch anders als man sich das eigentlich gedacht hat, da kann es auch einfacher sein mal in den assembler-source zu schauen als zu debuggen.
dann gibt es auch spezielle befehle auf manchen cpus oder es gibt sie nicht. z.b. gibt es auf der ARM7 cpu keine division, anstatt dort zu dividieren, ruft man lieber einen interrupt auf der das macht oder denkt sich einen anderen weg aus das zu machen was man möchte. aber dafür gibt es dort befehle die wie in den shadern mehrere dinge in einem takt ausführen können. z.b. *pBuffer++=0; ist nur ein cpu cycle, wenn man sich mit assembler und cpus nicht auskennt, verspielt man viele optimierungen dafür.
MfG
micki
HellHorse
2004-03-01, 23:55:32
<ot>
*auch noch was zu Java und JIT sag*
Wir hatten letzthin einen Gastvortrag von einem Typen der an GNU CLASSPATH arbeitet und der meinte, wenn man Java-Bytecode kompiliert/jit'et kann man wegen der Typensicherheit von Java Compileroptionen fahren, die mit C nicht gehen/unsicher sind.
Er hat's nicht ausgeführt und ich habe nicht nachgefragt.
Java Sourcecode kann man mit dem gcj (Teil der gcc) auch dirket in nativen Code überstetzen.
</ot>
HajottV
2004-03-02, 10:53:46
Original geschrieben von HellHorse
<ot>
*auch noch was zu Java und JIT sag*
Wir hatten letzthin einen Gastvortrag von einem Typen der an GNU CLASSPATH arbeitet und der meinte, wenn man Java-Bytecode kompiliert/jit'et kann man wegen der Typensicherheit von Java Compileroptionen fahren, die mit C nicht gehen/unsicher sind.
Er hat's nicht ausgeführt und ich habe nicht nachgefragt.
Java Sourcecode kann man mit dem gcj (Teil der gcc) auch dirket in nativen Code überstetzen.
</ot>
Das glaube ich schon insofern nicht, als daß C++ keinen Deut weniger typsicher ist als JAVA.
In C++ castet man Pointer... in JAVA Referenzen. In JAVA wird zusätzlich noch der Typ überprüft, was langsam ist.
Davon abgesehen: Der JIT taugt nicht so viel. *) Okay, ist allemal besser als Bytecode, aber im Vergleich zu einem optimierenden C++ Compiler ist das Schrott.
Gruß
Jörg
*) Wenn Du das mal nachprüfen möchtest, dann lass mal den Stack bei JAVA überlaufen (-> JVM kackt ab) und geh dann in den Visual Studio Debugger. Da kann man sich dann den compilierten Bytecode prima angucken. [Das ging mit 1.3, keine Ahnung, ob es mit 1.4 noch klappt.]
Ergänzung: Hab's gerade mit 1.4 ausprobiert... damit läßt es sich nicht mehr reproduzieren.
micki
2004-03-02, 11:43:30
es geht nicht um c++ sondern um c, c ist im gegensatz zu c++ typ unsicher,
während man in c++ sowas schreibt wie
const unsigned int DIVISOR = 2;
const float DIVISOR2= 2.5f;
ist es für c eher folgendes typisch/gedacht:
#define DIVISOR 2
#define DIVISOR 2.5f
das gilt auch für macros in c, in c++ nutzt man ja inline funktionen deren parametertypen definiert sind.
aber es ist für jeden der assembler kann (und weiß wie man darin optimiert) klar, dass eine sprache die direckt auf eine cpu kompiliert wird einiges an performance mehr heraushollen kann als eine sprache die auf eine virtualmaschine compiliert.
MfG
micki
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.