source code

[Mithrandir]

Original von istdaswirklichwichtig
>Assembler mögen nur ganz bestimmte masochistische Charaktere...

das sind die vorurteile...
ich programmier in Assembler fast genauso bequem wie in C++ dank macrobenutzung. Ok Strings sind verdammt schwer, aber alle meine C++ progs die zuviele Strings benutzt haben sind immer abgeschmiert und ich konnte den fehler nicht finden.

C++ ist ja auch nicht grade das gelbe vom Ei. Aber Assembler ist nicht bequem, das ist kein Vorurteil, das ist eine Tatsache. Wenn schon Strings in Assembler "verdammt schwer" sind, wie sieht es dann mit wirklich komplexen Strukturen aus?

Original von istdaswirklichwichtig
Einem Kumpel von mir war das noch nicht genug. Er hat versucht, ein Spiel nur via batchdateien zu schreiben! Nur standart Dos-Befehle zulässig. Kein qBasic, debug oder sonstige Sachen, mit denen es "zu einfach" wäre... Und er hat es geschafft! Es ist im übrigen mehr als ein Textadventure. Vielmehr ist es ein Rollenspiel... Komplett mit Kampfsystem & Co. Mit ansi sogar relativ spielbar! :rolleyes:

Toll. Man kann sich das Leben schon schwer machen. Klar, wenn man die Herausforderung sucht, programmiert man Sachen einfach nur für das Gefühl, das sich einstellt, wenn es funktioniert...

Es gibt doch so schöne Sachen, z.B. Objektorientierung,

Wer braucht denn so einen Quatsch?

OO ist absolut geil! Das hat einfach Stil; gerade wenn mehrere Leute zusammenarbeiten ist das Konzept der Kapselung ungblaublich gut. Programme bekommen einfach bessere Strukturen mit OO. Und die Wiederverwendbarkeit und auch Anpassbarkeit von Code ist hoch.

[Ex-Admin]

Das heisst übrigens OOP und bedeutet Objektorientierte Programmierung

[fryfan]

es wurde in letzter zeit ja nicht nur der windows code geklaut, in der spiele branche wurde eine beta von half life 2 und der code geklaut und auch von anderen spielen wurden betas geklaut...
ich kann nicht verstehen wie valve half life 2, ihr millionen projekt auf einen mit dem internet verbunden server/pc stellen kan... :rolleyes:

[Mithrandir]

Original von codemonkey
Das heisst übrigens OOP und bedeutet Objektorientierte Programmierung

Ich sage trotzdem OO, das bedeutet Objekt-Orientierung.

[DichterDenker]

@Wegweiser



du bist also auch so ein Freak wie ich?

Für Windowsprogrammierung benutz ich FASM
[Links nur für registrierte Nutzer]
,für Linux NASM (und für das Betriebssystem das ich grad in reinem Assembler schreibe ... letzten Sonntag hab ich den Sheduler fertiggemacht *ganz stolz sei*)

>Ich wünschte, ich könnte damit auch wirklich was machen...

Ich könnt dir ein paar Tutorials schicken wenns dir was bringt...

@Mithrandir

Komplexe Strukturen sind im Prinzip Strings...und sogar noch leichter Handzuhaben als diese...
Ich dachte da eher an Funktionen die
aus einem Userstring ne Zahl machen mussten oder umgekehrt
oder wildcard-strings suchen
da kriegt man dann ne funktion die 5 übereinanderliegende schichten hat was sehr eklig ist...

>OO ist absolut geil! Das hat einfach Stil; gerade wenn mehrere Leute
>zusammenarbeiten ist das Konzept der Kapselung ungblaublich gut.

Mag sein. Dafür habe ich die absolute Macht über die Hardware *hehehehe*

[sparty2]

Ach Kinder...

OOP und Assembler schiessen sich ja nicht gegenseitig aus. Es ist prinzipiell auch möglich (teilweise) objektorientiert in Assembler zu programmieren. Nur ist das halt extrem mühsam und fehleranfällig. Der Vorteil von OOP und AOP (Aspektorientierte Programmierung) liegt ja gerade darin dass die Produktivität und Wartbarkeit bei größeren Softwareprojekten extrem gesteigert werden.
Der ehemalige Vorteil der Assemblerprogrammierung, die höhere Ausführungsgeschwindigkeit, ist in Zeiten superskalarer CPUs mit Out-Of-Order Excution und Register-Renaming eher ins Gegenteil verkehrt, da die Abhängigkeiten zwischen den einzelnen Befehlen für eine optimale Ausführung dermassen komplex geworden sind dass ein Compiler einen deutlich besseren Code erzeugt. Spätestens bei CPUs wie Intel's Itanium mit VLIW-Architektur ist die Programmierung "von Hand" nicht mehr sinnvoll.
Und nicht zuletzt gilt bei fast allen Programmen die 90/10 Regel:

90% der Zeit verbringt ein Programm in 10% des Codes.

D.h. 90% des Codes sind völlig irrelevant für die Ausführungsgeschwindigkeit und diese 90% in Assembler zu programmieren ist reine Zeitverschwendung. Innerhalb der verbleibendne 10% mag es bei sehr rechenintensiven Aufgaben hin und wieder sogar angebracht sein, einzelne Teile in Assembler zu optimieren, aber das ist wirklich sehr selten.
Wer mit Software Geld verdienen will, der hat normalerweise nicht die Zeit diese in Assembler zu schreiben. Selbst bei 8-Bit Microcontrollern hält C immer mehr Einzug, da es einfach produktiver ist. Nur in Ausnahmefällen werden größere Programme dafür noch neu in Assembler geschrieben.

sparty2

[Mithrandir]

Original von sparty2
OOP und Assembler schiessen sich ja nicht gegenseitig aus. Es ist prinzipiell auch möglich (teilweise) objektorientiert in Assembler zu programmieren.

Vermutlich liegts an meinen unzureichenden Assembler-Kenntnissen, aber ich täte mir vermutlich ziemlich schwer so etwas wie Kapselung, Vererbung, Substituierbarkeit, oder Polymorphismus und v.a. die Abstraktion mit Assembler zu verwirklichen...


Mir ist meine Zeit halt wichtiger, als die Zeit, die mein Rechner arbeitet, deshalb meide ich Assembler.

[sparty2]

Original von Mithrandir
Vermutlich liegts an meinen unzureichenden Assembler-Kenntnissen, aber ich täte mir vermutlich ziemlich schwer so etwas wie Kapselung, Vererbung, Substituierbarkeit, oder Polymorphismus und v.a. die Abstraktion mit Assembler zu verwirklichen...

Kapselung geht recht einfach. Vererbung könnte durch eine Kopie der VTable erreicht werden... aber Du hast schon recht, es ist in der Realität von Hand nicht sinvoll machbar.
Und für die "Speed-Freaks" bleibt ja auch in C++ der Inline-Assembler und in Java die Native-Methods.

sparty2

[John Donne]

Original von istdaswirklichwichtig
du könntest den kernel (wahrscheinlich "win.com") disassemblieren.

P.S: für alle die es nicht wissen: Assemblercode ist eine für Menschen lesbare Form von Maschinensprache. disassemblieren heißt eigentlich nur die Maschinensprache lesbar zu machen. (naja viele betrachten assembler als zu schwierig aber ich komm gut damit zurecht )

Die Frage ist doch, was Lesbarkeit bedeutet. Ich habe zeitweise viel in Assembler programmiert, aber unkommentierten Assemblercode halte ich auf jeden Fall für sehr schwer lesbar, wenn man unter Lesbarkeit das Erfassen der Programmlogik (Datenstrukturen, Algorithmen,...) versteht. Mit dem Ergebnis einer Disassemblierung können die meisten Menschen kaum etwas anfangen. Da durchzusteigen ist derart zeitaufwendig, daß man den Code in vielen Fällen gleich selbst entwickeln kann.

Ich möchte mich weitgehend Mithrandir anschließen: Wenn ich einen PC programmieren, werde ich das in den seltensten Fällen in Assembler tun. Inline reicht für die wenigen zeitkritischen Fälle meist völlig aus. Wenn ein embedded system zup rogrammieren ist (vielleicht ein ABS-System mit harten Echtzeitanforderungen) spricht vieles für Assembler...

In Assembler fühlte ich mich lange Zeit so, als müßte ich täglich das Rad neu erfinden. Mir ist das auf die Dauer einfach zu anstrengend. Und ich kann mir nur schwer vorstellen, mit Methoden des Software Engineering wirklich große Projekte in Assembler anzugehen, weil ich nicht glaube, daß irgendjemand den zusätzlichen Zeitaufwand für XY-Anwendungen bezahlt. Zudem ist an dem Argument von sparty2, daß Compiler und anderen Codegenration Tools heute auf vielen Leveln guten Code erzeugen, viel Wahres dran.

Grüße
John

[DichterDenker]

>Mir ist meine Zeit halt wichtiger, als die Zeit, die mein Rechner arbeitet,
>deshalb meide ich Assembler.

Naja bei Routinesachen bin ich mit Assembler genauso schnell wie mit HLLs.

>Der ehemalige Vorteil der Assemblerprogrammierung, die höhere
>Ausführungsgeschwindigkeit, ist in Zeiten superskalarer CPUs mit Out-Of-
>Order Excution und Register-Renaming eher ins Gegenteil verkehrt, da
>die Abhängigkeiten zwischen den einzelnen Befehlen für eine optimale
>Ausführung dermassen komplex geworden sind dass ein Compiler einen
>deutlich besseren Code erzeugt. Spätestens bei CPUs wie Intel's Itanium
>mit VLIW-Architektur ist die Programmierung "von Hand" nicht mehr
>sinnvoll.

Kann ich mir kaum vorstellen. Der Compiler wurde ja auch von jemandem programmiert. Und ein Programmierer der ein Programm programmiert das besser programmiert als er ist parodox...