Beginning ASM

[pate33]

Hi,

also, dann will ich mal anfangen zu fragen... :D

was genau ist assembler?

was brauche ich, um asm zu programmieren?

koennt ihr mal nen beispiel coden posten, dass man mal sieht wie das funtzt... vllt. ein ´hello world!´ proggi, oderso...

thanks

[cYrus]

also assambler weiss nur Codeq was es heisst ;) habs bis jetzt jedenfalls noch nicht herausgefunden..

aber assembler is afaik die hardwarenahste Programmiersprache! Bisschen mehr Bitschubserei als coden :D

so long
dj-cYrus

[pate33]

jaja, schon gut... alter besserwisser... :D

~~~changed~~~

greetz

[FiReFoX]

Assembler ist einen Maschinennahe Programmier Sprache. Sie ist wichtig für echtzeit animationen wie 3D spiel oder anderes. Assembler ist nicht so wie du coden kennst es ist ganze anderst aufgebaut. Es gibt schon befehl nur die Operanden werden in Adresse oder in Symbolischennamen(die vorher definiert sind mit einer adresse) zu gewissen.

Es gibt unterschiedliche Assembler arten für jeden Prozessor einen anderen. Jedoch sind die Befehl die gleichen nur die Speicherplätze und gewissen Register sind anderst angelegt.

Für meinen Teil, glaub ich das ASM 370 am meisten verbreitet ist.

Ich habe son einen verlgeichszettel den werde ich demnächst posten und dann sich ihn jeder anschauen da sind 4 verschiedenen Programmiersprachen oben.

[cYrus]

Original von -silencer-
jaja, schon gut... alter besserwisser... :D


no problem alter Spammer :D

so long

[MrEasy]

hier mal ´n kleines beispielprogramm für nen Z80 µ-Prozessor zur Division zweier binärzahlen:

LD HL,0BAABH ; Dividend
LD A,02H ; Divisor
LD D,080H ; Vergleichswert
LD E,09H ; Schleifendurchlaeufe
LOOP
CP D ; Bit 7 vom Divisor schon eins ?
JP NC,ALINKS ; wenn ja weiter bei ALINKS
AND A ;carry null setzen
RL A ;Divisor nach links schieben
INC E ;Durchläufe um eins erhöhen
JP LOOP ;neuer Vergleich
ALINKS
LD B,A ;Divisor nach B kopieren
LD C,0H ;c löschen (Divisor ganz vorne in BC)
LD A,E ;Durchläufe in A
LD DE,00H ;Ergebnis in DE
LOOP2
AND A ;carry null setzen
RL E ;Ergebnis nach links schieben
RL D ;
AND A ;carry null setzen
SBC HL,BC ;verschobener Wert von Dividend abziehen
JP NC,KLEINER ;Wenn es möglich war, weiter bei kleiner
ADD HL,BC ;sonst wieder dazuzählen
JP WEITER ;und nächster Schritt
KLEINER
INC DE ;wenn das abziehen erfolgreich war, eins zum Ergebnis dazu
WEITER
AND A ;carry null setzen
RR B ;Divisor einen Schritt nach rechts schieben (16 Bit)
RR C
DEC A ;einen Schritt runterzählen
CP 0 ;wenn Anzahl der Schritte erreicht
JP NZ,LOOP2 ;fertig sonst zurückspringen
FERTIG
JP FERTIG

[Felix Kaiser]

Assembler ist die Sprache der CPUs verfasst in Kürzel und Symbole, angepasst an die jeweilige Architektur des CPUs. Die Z80 Architektur dürfte für uns weniger interessant sein, da wir auf x86 bauen. Der Urprozessor, der 8086, beherrschte einst 86 Befehle, kannte 4 Daten-Word-Register, 4 Segmentregister und 4 Zeigerindizes. Die Angaben über Befehl, verwendete Register und Werteparameter werden vom Compiler zu einem Opcode verfasst, jeder Opcode genau ein Befehl. Die Aufgabe des CPU ist später anhand der Bitfolgen im Opcode den Befehl und dessen Parameter zu erkennen und zu verarbeiten. Im Verlauf der Entwicklung und Forschung wurden die Register erweitert. Mit Einführung des 80286 kamen 2 weitere Segmentregister hinzu, Anfänge für 32-Bit Register wurden gemacht und es gab erstmals 2 Betriebsmodi im CPU, den RealMode, auf dem bisher immer gearbeitet wurde, jedoch konnte man nicht mehr als 1Mb RAM verwenden und den Protected Mode, mit welchem man endlich bis zu 64Mb RAM verwenden konnte. Seit dem 80386 gab es vollständige 32-Bit Unterstützung und man unterteilte den ProtectedMode in 16-Bit Betrieb und in 32-Bit Betrieb. Parellel zum CPU konnte ein FPU installiert werden, eine Fließkommaeinheit (nummerischer CoProzessor), welcher seit dem Pentium im CPU integriert ist. Er umfasst 8 Fließkommaregister und wie auch beim normalen CPU der x86 Baureihe kamen auch hier immerwieder neue Befehle hinzu, so musste man auch ständig einen aktuellen Compiler haben, um alle CPU OpCodes in Assembler verfügbar zu haben. Wenn man sich mit Assembler anfreunden will, muss man sich ebenso mit tiefster Systemarchitektur befassen, d.h. u.a. Speicherverwaltung, Interrupts, Integration diverser Hardwarekomponenten, möchte ich jetzt nicht näher erklären. Nur kurz ein kleines DOS-Programm, mit "Hallo Welt" Prinzip, ein einfaches EXE-Modell für Turbo Assembler.

.model small
.stack 200h ; 1 Kb Stack
.data ; Datenbereich
Msg1 db ´Hallo, Welt!´,0Dh,0Ah,´$´
.code ; Codebereich

mov ax,@Data
mov ds,ax ; DS auf Datensegment setzen
mov ah,9 ; DOS Funktion AH=9, Textausgabe
mov dx,offset Msg1 ; Zeiger DS:DX vervollständigen, zeigt auf Msg1
int 21h ; DOS-Interrupt aufrufen
mov ax,4C00h ; DOS Funktion AH=4Ch, Programm beenden, AL=ExitCode
int 21h ; DOS-Interrupt aufrufen, Programm wird somit beendet
end ; Ende des Quelltext

[pate33]

gibt es da irgendeine logik in den beispiel codes? ich meine, fuer mich sieht das alles recht komisch aus...

nur mal so im groben erklären, was da passiert...

[Dominic Suter]

Für mich ist Assembler eine der am logischten Programmiersprachen überhaubt. Da ich eigentlich Elektroniker bin und daher die Hardware dahinter sehr gut verstehe, ist Assembler ziemlich simpel. Man liest die Daten ein, verarbeitet diese und gibt sie wieder aus. Wird die interne Verarbeitung kompliziert, wird auch Assembler ziemlich schnell schwierig.

In einem Programm werden meist Daten eingelesen, verarbeitet, gespeichert ausgegeben etc. Nur dass man in Assembler halt jede Speicherstelle kennen muss und die Daten dann an diese entsprechende Stelle "sendet". Das heisst, Alu, Register, Stack etc. dürfen keine Fremdworte sein, sonst wirst du mit ASM ziemlich Schwierigkeiten haben.

[Alamar]

ja es gibt logik
asm code fängt immer mit
model .... an
das bestimmt ob es nun eine com file oder eine exe wird und dann noch ein paar sachen die ich auch nicht weiß ;)
dann folgt immer.
CODE SEGMENT;
( ausser es ist eine exe file mit vars dann werden die in einem data segment meistens gespeichert)
meinstens wird hier dann ein
start: label gesetzt
jo und der rest ist ja bei den beispielen immer gut erklärt :)
hier steht dann der code
und hier kommt noch ein end start hin;

[Felix Kaiser]

Alamar, nich ganz, aber so ähnlich ;)

[Patrik Graf]

Hi! :D

Kann mir jemand sagen, wo ich den Intel oder AMD Befehlssatz herbekomme?

Thanx

[Felix Kaiser]

Den Befehlssatz kannst du überhaupt nicht bekommen. Aber du kannst bei der Intel Website bzw. bei der AMD Website mal mit Hilfe der Suchfunktion nach einer Dokumentation über die Befehlssätze suchen. Oder bei Google. Eine Komplettdokumentation von Intel zum i386 Befehlssatz (CPU,FPU) könnte ich dir geben. Textformat, ca. 800Kb groß.

[Patrik Graf]

Das wäre echt spitze! :D

Meine eMail: webmaster@grafitty.de

Thanx!

[Bolle]

Original von MrEasy

LD HL,0BAABH ; Dividend
LD A,02H ; Divisor
LD D,080H ; Vergleichswert
LD E,09H ; Schleifendurchlaeufe
LOOP
CP D ; Bit 7 vom Divisor schon eins ?
JP NC,ALINKS ; wenn ja weiter bei ALINKS
AND A ;carry null setzen
RL A ;Divisor nach links schieben
INC E ;Durchläufe um eins erhöhen
JP LOOP ;neuer Vergleich
ALINKS
LD B,A ;Divisor nach B kopieren
LD C,0H ;c löschen (Divisor ganz vorne in BC)
LD A,E ;Durchläufe in A
LD DE,00H ;Ergebnis in DE
LOOP2
AND A ;carry null setzen
RL E ;Ergebnis nach links schieben
RL D ;
AND A ;carry null setzen
SBC HL,BC ;verschobener Wert von Dividend abziehen
JP NC,KLEINER ;Wenn es möglich war, weiter bei kleiner
ADD HL,BC ;sonst wieder dazuzählen
JP WEITER ;und nächster Schritt
KLEINER
INC DE ;wenn das abziehen erfolgreich war, eins zum Ergebnis dazu
WEITER
AND A ;carry null setzen
RR B ;Divisor einen Schritt nach rechts schieben (16 Bit)
RR C
DEC A ;einen Schritt runterzählen
CP 0 ;wenn Anzahl der Schritte erreicht
JP NZ,LOOP2 ;fertig sonst zurückspringen
FERTIG
JP FERTIG



und da is ne logik drin?

[Felix Kaiser]

In Assembler ist nur Logik drin. Man braucht um Assembler zu verstehen nur den Befehlssatz der CPU kennen.

[Bolle]

kann mir denn mal einer den befehlsatz für 686er cpu`s schicken?

j-h.boll@web.de wäre nett wenn das einer machen würde

[Felix Kaiser]

Den Befehlssatz gibt es nicht. Die Architektur für unsereiner heißt x86. Da seit dem 386er nichts großartiges hinzugekommen ist, zur Grundarchitektur, wird die auch oft als ´i386´ (Intel386) bezeichnet. Ich kann dir die i386, i387 spezifischen Befehle per Mail senden, offizielle Doku von Intel (ca. 830Kb Dok).

Eine Doku für alle wirst du nicht finden. In der 486er Epoche wurden einzelne Befehle hinzugefügt, ein paar grundliegende Pentiumbefehle gibt es, die von anderen Herstellern übernommen wurden und dann so vendorspezifische Befehlssätze ´SMD´, ´3dNow!´ oder MMX was sich auch bei anderen Herstellern schließlich etabliert hat.

Trotzdem brauchst du nur i386, i387 (für Fließkommaoperationen) kennen, eventuell noch ein paar Kniffe aus 486er oder ältesten Pentiumzeiten. Mehr steckt heute auch nich drin :)
Ausreizung aller machbaren extravaganten Befehle findest du auch nur in hardwareintensiven / optimierten Dingen wie DirectX, Video Codecs, Hardware Renderer und Filter etc.

Wenn du Interesse hast, mail mir ... Ich machse dir als RAR fertig.

[Bolle]

jo, wäre geil wenn du das machen könntest.
j-h.boll@web.de

thx

[Felix Kaiser]

Jo kein Thema 8)

[Messiah_of_Death]

also wenn man bei AMD anruft bekommt man 2 Bücher kostenlos zugeschickt. Da stehen die Befehle und Erläuterungen drinnen inkl. der AMD-spezifischen Befehle. Mein Bekannter war begeistert...

hm.. solte man heute noch DOS coden oder Win32

das einzige was ich mal geschnallt hab war ASM mit nem 8085 (<- kein Tippfehler !) ; nem MidiCom ...

[Schaf]

yo, der 8085er ist kewl, den haben wir grad inner schule, zusammen mit dem 6502! was ich sagen wollte: passt auf, das ihr asm nicht zu sehr generalisiert! denkt daran, dass es für jede prozessorFAMILIE gaaanz andere befehle gibt, oder zumindest heißen sie anders. das führt dazu, das asm auf jedem proz ne ganz andere programmiersprache ist, als auf nem anderen. also schön immer dazuschreiben, für welchen proz der code gilt. hatte jemand anderes (sorry, weist net mehr wer) schonmal hier auf dem board vorgeschlagen.

asm != asm;

ps: der ganze asm-kram, der nicht pc/mac betrifft -> ins bald vorhandene elektronik-board ;)

[Dominic Suter]

@Messiah_of_Death

Wo muss man bei AMD anrufen? Ich wäre brennend an den Büchern interessiert....

[Messiah_of_Death]

jetzt wirst du mich vielleicht erschlagen, aber ich hab wenn ich mich recht erinnere damals in der AMD-Hauptzentrale angerufen und hab gefragt, ob sie etwas für Assemblerprogrammierer hätten... :D
Dann wollten die meine Adresse und ein paar Tage später hatte ich die Teile. Die Telefonnummer stand auf deren Seite glaub ich (jetzt find ich die nicht)

vielleicht hilft des: Online Doku Order Form (http://www.amd.com/de-de/Processors/TechnicalResources/0,,30_182_3559_702^743,00.html)

[Dominic Suter]

Vielen Dank. Ich habs jetzt einmal damit probiert, sonst telephoniere ich denen einmal.

Gruss Stönggi

[Messiah_of_Death]

wie sieht&acute;s aus `?? Schon irgendeine Reaktion von AMD ?

[Dominic Suter]

Nein, nur ne Mail, dass sie den Kontakbogen zur Zeit nicht bearbeiten koennten :(

Na ja, werde einmal anrufen. Ich hoffe bloss, dass die die beiden Buecher auch in die Schweiz versenden ohne dass horende Gebueren anfallen ?(

[SpyWar]

@Felix Kaiser: könntest du mir die doku vom intel i386 befehlssatz auch schicken?

an: oliver558_@freenet.de

thx

[Jan Krüger]

Für einen Einstieg in Assembler für Win32 kann ich http://win32asm.cjb.net empfehlen. Ist zwar etwas zu bunt und ein bisschen unübersichtlich, aber da finden sich viele nette Sachen (inkl. der Microsoft Assembler).

[Patriot]

hi!

Hab ne frage: Braucht man nen eigenen editor, um asm zu proggen???

MfG,
Patriot

[Jidder]

im Prinzip kannst du problemlos mit Notepad deine Sachen tippen.

Wenn du allerdings schön buntes Syntaxhighlighting haben willst, kannst du entweder Proton (http://www.meybohm.de/), der sehr schlank ist und den ich auch verwende, RadASM (http://radasm.visualassembler.com/), der auf Assembler spezialisiert ist, oder Ultraedit (http://www.ultraedit.com) nehmen, für den du allerdings noch ein Wordfile runterladen musst. Ultraedit ist auch Shareware oder so.

[Patriot]

und das muss ich unter test.asm speichern oder was?
und was ist mit nem compiler ? wo bekomm ich einen und wie verwende ich ihn?

MfG,
Patriot

[Jidder]

und das muss ich unter test.asm speichern oder was?
ja zum Beispiel.

Du brauchst keinen Compiler, sondern einen sogenannten Assembler. Zum Beispiel NASM. Den gibts unter http://nasm.sourceforge.net -> Download -> Win32 Binaries -> die .zip mit der aktuellsten Version. Zur Zeit ist es die nasm-0.98.39-win32.zip (http://prdownloads.sourceforge.net/nasm/nasm-0.98.39-win32.zip?download).

Wenn du nicht Windows verwendest, musst du NASM natürlich entsprechend für eine andere Plattform downloaden. Die Wahl ist übrigens unabhängig von der Plattform, für die du später Programme schreiben willst. Du kannst also z.B. mit der Windows-Binary problemlos DOS- und Linux-Programme erstellen. Anders herum ist das auch kein Problem.

In dem Archiv gibt es zwei exe-Dateien, uns interessiert aber nur nasmw, der Assembler. Wenn du z.B. ein .com-Programm erstellen willst, kannst du das so assemblieren: nasmw test.asm -fbin -otest.com

Das -fbin sorgt dafür, dass eine Binärdatei erstellt wird (eine .com-Dateiei ist eine reine Binärdatei ohne spezielle Header). Das -otest.com gibt an, dass die Ausgabedatei test.com heißen soll.

Du kannst nicht direkt mit NASM .exe-Dateien erstellen. (Oder zumindest nicht auf elegantem Wege.) Dazu brauchst du einen Linker, die die NASM-Ausgabe zu einer .exe-Datei linkt. Ein Linker ist bei NASM nicht dabei. Bei TASM hingegen schon, aber ich weiss nicht ob und wo es das gibt. Da sollte dir Google weiterhelfen. Aber .com-Dateien sollten fürs erste sowieso reichen.

[Patriot]

das ist doch ne maschienen sprache.. kann man damit nur am pc arbeiten oder auch andere maschienen programmieren?

[Pointer]

Jo, kommt drauf an, ob die Maschine nen Mikrocontroller/-prozessor hat um den Anforderungen von Assembler gerecht zu werden (Register/Stack/...).

~Pointer

[Jan Krüger]

Klar, aber der Assemblerdialekt ist für jeden Prozessor unterschiedlich. Ein Motorola-68k-Prozessor hat z.B. mit den im PC-Bereich gängigen x86-Prozessoren fast nichts gemeinsam, was den Assemblerdialekt angeht.

[Pukys]

Klar, aber der Assemblerdialekt ist für jeden Prozessor unterschiedlich. Ein Motorola-68k-Prozessor hat z.B. mit den im PC-Bereich gängigen x86-Prozessoren fast nichts gemeinsam, was den Assemblerdialekt angeht.

Äh, ich finde gerade, daß ihr euch in den Detaildiskussionen ein wenig verrennt und einen wichtigen Aspekt einfach vergesst: Was IST Assembler, und was macht es aus (und so besonders)?

Ja, Assembler ist eine maschinennahe Programmiersprache und das bedeutet: Sie ist extrem nah am Mikroprozessor. Das heißt, daß Assembler a) systemabhängig ist: Andere Prozessorfamilie, anderer Assemblerdialekt. Und b) (WICHTIG) Assembler eines zwingend voraussetzt, nämlich das Wissen, wie der Prozessor funktioniert, wie seine Programmierphilosophie aussieht, wie das Speicherinterface funktioniert und c) man auch weiß, wie höhere Programmiersprachen ihre Interface aufbauen, um Assemblermodule an diese anzubinden. Letzteres ist ua. betriebssystem- und compilerabhängig!

Denn reine Assemblerprogramme schreibt keiner mehr, das wäre zuviel des Masochismus. Als Anschauungsobjekt oder als proof of concept ist das o.k., aber da die Compiler inzwischen einen so guten Code erzeugen, schreibt man handoptimierten Assemblercode nur noch in extrem zeitkritischen Bereichen oder in den zentralen Kerneltreibern.

Teilweise sind die Compiler so gut, daß sie sogar besseren Code erzeugen als der Mensch, weil sie genau wissen, wie die Timings von Befehlen zusammenpassen, und welche Befehle am besten parallel ausgeführt werden können: Mit handgefeilten Code holt man beim eigentlichen Codegenerator kaum noch was raus. Nennenswerten Einfluß hat da nur noch die Programmstruktur: Im Extremfall eines selbstmodifizierenden Messagepassingsystem für neuronale Netze kann ein sich selbst modifizierendes, interpretiertes Smalltalk deutlich schneller sein, als ein kompiliertes Programm. Es kommt immer auf den Kontext an.

Da ich zur Zeit Embedded Systeme mit eigenem Betriebssystem programmiere, habe ich noch regelmäßig mit Assembler zu tun. Trotzdem macht der Assembleranteil selbst bei so hardwarenahen Anwendungen kaum 5% aus. Der Aufwand lohnt nicht und der Geschwindigkeitsvorteil ist nahe 0.

[Xpyder]

Na, ich weiß nicht recht - so lange der Geschwindigkeitsvorteil nur NAHE Null und nicht GLEICH
Null ist, lohnt sichs immer.
Wenn man bei ner 3D-Pixelroutine ne Millionstel Sekunde
spart, ist das bei 800x600 zB fast halbe Sekunde pro Frame.
(Nur mal so als Beispiel.)

Und: Würde mehr in Assembler gecodet, wären Dinge wie Windows oder ähnliches
vermutlich auch nicht so ätzend langsam. Denn trotz mehrerer Gigahertz,
riesigem RAM und gigantischer Festplatten passiert in Win absolut NIX in Echtzeit.
Frag mich manchmal: Wie monströs muß ein Rechner werden, damit er dann auch
endlich mal für ne Firma wie Microsoft schnell/groß genug dimensioniert ist?
Wahrscheinlich wird es, wenn es dann Quantenrechner gibt, wieder ne neue
Windows-Version geben, die das DIng auf 286er Speed bremst...

Ich habe ein Programm namens MPXPLAY hier, geschrieben von nem Freak. Und
wahrscheinlich größtenteils Assembler. Spielt MP3, OGG und
diverses anderes ab. Anforderung dafür: 486er, 66 MHz.
An der Stelle trennen sich die Coder von den Skript-Usern...

Und: Die Compiler, die eben Sprachen übersetzen, muß ja auch jemand coden.
Und Assembler/Maschinencode ist nunmal der direkteste Weg,
mit dem Rechner zu kommunizieren. Richtige Optimierung kann imo kein
Programm übernehmen. Diverse Tricks mit Registern sich einfach zu abstrakt
(weil an die jeweilige Aufgabe angepaßt), als daß ein Compiler da
"von allein drauf kommt".

Ich bin jedesmal begeistert, wenn ich die Speedvorteile von Assembler sehe.
Und davon abgesehen kann man mitunter in Assembler Dinge einfacher darstellen,
wofür man sich in Hochsprachen total kompliziert ausdrücken muß.
Ein Beispiel war neulich im Board die Programmierung mit Strings und Zahlensystemen.
Gruselig, welche Konstrukte da in Hochsprache bemüht werden mußten für so eine
primitive Aufgabe...

(Manche Hochsprachen übertreiben die Abstraktion dermaßen, daß man, WENN man mal
etwas Computer-/Systembezogenes machen will, das total umständlich formulieren muß.
(Kaum vorstellbar, daß so eine Sprache dann im Ergebnis wirklich optimierten Code
erzeugen würde...)

Tschuldigung, falls ich nerve. Mußte ich halt mal loswerden.
(Btw: Auch, wenn sich's von manchen Leuten so anhört:
Assembler wurde NICHT erfunden, damit's keiner verstehen/benutzen kann.)

-----------------------------
Was in asm nicht geht, muß man löten.

[Pukys]

Na, ich weiß nicht recht - so lange der Geschwindigkeitsvorteil nur NAHE Null und nicht GLEICH
Null ist, lohnt sichs immer.
Wenn man bei ner 3D-Pixelroutine ne Millionstel Sekunde
spart, ist das bei 800x600 zB fast halbe Sekunde pro Frame.
(Nur mal so als Beispiel.)

Das sind die glorreichen (und extrem seltenen) Ausnahmen, darauf gehe ich aber noch genauer ein. Bei einem 1GHz-Prozessor mit angenommener 1-Befehl-pro-Takt-Architektur hieße das, daß du in der inneren Schleife pro Pixel 1000 Taktzyklen sparst. DAS fällt in die Kategorie Algorithmenoptimierung, nicht Codeoptimierung. Wenn du in einer solchen Schleife pro Durchlauf 1000 Takte durch reine Befehlsoptimierung rausholen willst, muß die Schleife schon so enorm groß und komplex sein, daß der Geschwindigketisgewinn nur noch marginal ist. Soviel zu deinem Rechenexempel.

Und: Würde mehr in Assembler gecodet, wären Dinge wie Windows oder ähnliches
vermutlich auch nicht so ätzend langsam. Denn trotz mehrerer Gigahertz,
riesigem RAM und gigantischer Festplatten passiert in Win absolut NIX in Echtzeit.
Frag mich manchmal: Wie monströs muß ein Rechner werden, damit er dann auch
endlich mal für ne Firma wie Microsoft schnell/groß genug dimensioniert ist?
Wahrscheinlich wird es, wenn es dann Quantenrechner gibt, wieder ne neue
Windows-Version geben, die das DIng auf 286er Speed bremst...

Entgegen aller Aussagen sind die eigentlichen Betriebssystemkerne und das GDI vom Code her hochoptimiert und sehr stabil. Das Problem ist, daß das GDI halt sehr generisch ist, und Windows an sich unter einem riesigem Ballast an versteckter Funktionionalität und Kompatiblitätsaspekten zu alten Versionen in die Knie geht. Das gleiche Problem gibt es mehr und mehr übrigens auch unter Linux.

Ich habe ein Programm namens MPXPLAY hier, geschrieben von nem Freak. Und
wahrscheinlich größtenteils Assembler. Spielt MP3, OGG und
diverses anderes ab. Anforderung dafür: 486er, 66 MHz.
An der Stelle trennen sich die Coder von den Skript-Usern...

Ich hab' mal einen MOD-Player zu 80% in 386-PM-Assembler implementiert - er wahr wahnsinnig schnell und ca. 4kb groß. War eine Woche Arbeit und ich war sehr stolz darauf. In C wäre der gleiche Player deutlich größer geworden, hätte ca. 75%-80% der Geschwindigkeit erreicht. Dafür hätte ich das Teil in zwei Tagen zusammengestrickt.
Es hat Spaß gemacht, ich hab' ne Menge gelernt und es war kewl. Aber ich hatte die Zeit, und Geld keine Sache. In einer real existierenden Welt kann man sich das aber kaum leisten, denn 5 Tage Arbeit mehr für 20% Mehrleistung ist eine Investition, die keiner macht: Es rechnet sich einfach nicht.
Dazu sind Assemblerprogramme schwer zu handhaben und fies zu debuggen, ihre Komplexität steigt im Gegensatz zu Hochsprachenprogrammen deutlich schneller an, genauso wie die schieren Codegrößen.
Bei einigen 100 bis wenigen 1000 Zeilen ist das handhabbar, aber was ist mit 10.000, 100.000 Zeilen? Wie lange willst du an einem Betriebssystem entwicklen, bis es marktreif ist. 10 Jahre? Nur damit es dann in handoptimiertem Assembler läuft? Was ist mit den ganzen zusätzlichen Bugs, die sich dann einschleichen, da Bugs einerseits von der Codekomplexität und andererseits von der Codemenge abhängen? Für Programme, die irgendwann einfach laufen müssen, ist Assembler heute nicht mehr machbar, nicht bei der geforderten Komplexität der Programme.
Heute ist ja schon das Win32-API ohne ein Framework nur noch mühsam handhabbar, unter Assembler ist das ein komplett wahnsinniges Unterfangen.

Und: Die Compiler, die eben Sprachen übersetzen, muß ja auch jemand coden.
Und Assembler/Maschinencode ist nunmal der direkteste Weg,
mit dem Rechner zu kommunizieren. Richtige Optimierung kann imo kein
Programm übernehmen. Diverse Tricks mit Registern sich einfach zu abstrakt
(weil an die jeweilige Aufgabe angepaßt), als daß ein Compiler da
"von allein drauf kommt".

Nein. Ganz defintiv nein. Man kann einen (modernen) Compiler schon sehr gut hinten, was er tun soll. Aber meist kommt er schon selber drauf. Die modernen Compiler sind wahre Meisterwerke. Mal ein kurzer Überblick, was ein Compiler so tut:



Der Compiler nimmt einen Sourcecode und jagt ihn durch einen Parser. Hier werden die ganzen Parserfehler und Syntaxfehler generiert.
Danach wird aus den Token-Stream (die extrahierte Information) ein sprachabhängiges Modell generiert. Semantische Strukturfehler fallen hier heraus.
Dieses Modell wird in ein Statusnetz übeführt, das Logiken repräsentiert und die Variablen werden in die Typen aufgelöst. Hier werden die Logiken optimiert, sofern dies widerspruchsfrei möglich ist. Am Ende sind z.B. geschachtelte if-Kunstrukte und case-Anweisungen, sowie die verschiedenen Schleifentypen von der Logik her gleichwertig aufgelöst.
Jetzt erst wird ein Prozessormodell an das Logikmodell angelegt und versucht, das Logiknetz an den Prozessor angepasst. Der Compiler nimmt dabei eine erste Gewichtung der Variablen vor. Zudem werden die Schleifen aufgelöst und gehintet. Einige Prozessoren, z.B. der i860/i960 können gehintete Schleifen und Sprünge optimiert ausführen, z.B. mit der Information, ob ein Sprung wahrscheinlich ist, oder nicht.
Der Codegenerator generiert einen (noch) prozessorunabhängigen Zwischencode.
Das Prozessormodell wird auf den Zwischencode angewendet, und peephole-Optimierungen vorgenommen (z.B. Integermultiplikationen durch shift/add-Konstrukte ersetzen, wenn es vorteilhaft ist).
Das Prozessormodell bestimmt das Callframe und ob vektorisiert werden kann/muß, d.h. ob es sinnvoll ist, Schleifen zu unrollen.
Jetzt wird prozessorabhängiger Maschinencode erzeugt.
Das Prozessormodell bestimmt die Timings der einzelnen Befehle, und ob mehrere Ausführungseinheiten existieren. Der Codegenerator sortiert die Befehle so um, daß die Einheiten maximal ausgelastet werden und überlappende Befehle in minimaler Zeit ausgeführt werden.
(optional) In einem Profilerlauf wird der Code nochmals gehintet und mittels Feedback an den Codegenerator zurückgegeben. Der neue GCC, sowie der Intel-C-Compiler und einige andere Compiler beherrschen dieses Verfahren.
Die modernen Compiler erzeugen einen Code, der, je nach Algorithmenqualität, in Sachen Geschwindigkeit handoptimierten Code in nichts hinterhersteht.

Ich bin jedesmal begeistert, wenn ich die Speedvorteile von Assembler sehe.
Und davon abgesehen kann man mitunter in Assembler Dinge einfacher darstellen,
wofür man sich in Hochsprachen total kompliziert ausdrücken muß.
Ein Beispiel war neulich im Board die Programmierung mit Strings und Zahlensystemen.
Gruselig, welche Konstrukte da in Hochsprache bemüht werden mußten für so eine
primitive Aufgabe...

Wo die Grenze zwischen Logik und Technik zu ziehen ist. s.u.
Strings sind meistens Bitschubsereien, daher eher bei Technik als bei Logik einzusortieren.

(Manche Hochsprachen übertreiben die Abstraktion dermaßen, daß man, WENN man mal
etwas Computer-/Systembezogenes machen will, das total umständlich formulieren muß.
(Kaum vorstellbar, daß so eine Sprache dann im Ergebnis wirklich optimierten Code
erzeugen würde...)

Wenn man es systembezogen machen muß sollte man es tun. In allen Fällen sollte man sehr genau abwägen, weil man sich den vermeintlichen Vorteil durch Inkompatiblität und reduzierte Portablität erkauft. Und wenn ein Algorithmus Assembler vorraussetzt um performant zu sein, sollte man den Algorithmus noch mal durchdenken.

Ich war auch mal in der Demoszene, ist schon paar Jährchen her, und Assembler war dort auch eher in den zeitkritischen Zentralbereichen angesagt. Unter DOS kam - man höre und staune - meistens Borland Pascal als Framework zum Einsatz. Der Grund ist einfach, aber wenig schmeichelhaft für Borland: Der BP-Compiler baut einen sehr berechenbaren Code, und sein Codegenerator war unter aller Sau, die ideale Schnittstelle für Inline-Assembler und dazugelinkte Prozeduren... *g*

Das wirft schon einen Blick darauf, wie programmiert wurde. Der Algorithmus, die Idee, wurde zunächst in Pascal umgesetzt, die Performance war dementsprechend. Dann wurde der Algorithmus immer weiter verfeinert. Und anschließend ausgewählte Teile des Algorithmus in Assember optimiert. Aber mitnichten bestand das ganze Programm aus Assembler. Nur ausgewählte Teile.

Außerdem ist der Gewinn durch Assembler oftmals ein Phyrrussieg. Ein Beispiel. Es gibt einen Effekt namens statics dissipation, der bei Assemblerprogrammierern oftmals zuschlägt und im Embedded-Bereich die Entwickler immer wieder einholt. Während viele Hochsprachler für Temps (also temporäre Werte, speziell irgendwelche Buffer) eben kurz auf dem Heap anlegen und wieder wegwerfen, scheuen Assemblerprogrammierer oft den Aufwand einer Heapverwaltung. Die Lösung: statics, also statische Variablen. Die müssen aber relativ großzügig angelegt werden um auch worst-case-Szenarios abdecken zu können. Das bläht das Image auf, und kann gerade bei kleinen Systemen ohne MMU zu großen Problemen führen. Programmierer, die sich der Vorzüge einer MMU und Paging leisten, belegen dann halt zwischendurch komplette Pages. Was zu einem anderen Problem führt, nämlich oftmal zum swapping, bis hin zum trashing. Was das Programm nicht schneller, sondern teilweise deutlich langsamer macht.

Tschuldigung, falls ich nerve. Mußte ich halt mal loswerden.
(Btw: Auch, wenn sich's von manchen Leuten so anhört:
Assembler wurde NICHT erfunden, damit's keiner verstehen/benutzen kann.)

Hochsprachen wurden erfunden, damit man sich auf das Wesentliche - den Algorithmus und die Problemlösung - konzentrieren kann und sich nicht mit der Abstraktion von Bitschubsereien und der Darstellung der Logik in Bits herumärgern muß.
Anders ausgedrückt:

Assembler ist die Abstraktion der Technik,
Hochsprache ist die Abstraktion der Logik.

Beides hat seinen Sinn. Beides hat seinen Platz. Man muß nur wissen, wo man die Grenze zieht. Im Idealfall bewegen sich beide aufeinander zu.

Was in asm nicht geht, muß man löten.

Möglicherweise nicht mal das. Das ist dann der Zeitpunkt, wo man ein schönes Buch in die Hand nehmen und sich klar machen sollte, daß Bäume schon einige Milliarden Jahre existieren, ohne daß sie die Digitaltechnik wesentlich tangiert hätte. Unmöglichem begegnet man am besten mit philosophsicher Ruhe.

[Xpyder]

(Thema: 3D-Optimierung)
Das sind die glorreichen (und extrem seltenen) Ausnahmen, darauf gehe ich aber
noch genauer ein. Bei einem 1GHz-Prozessor mit angenommener
1-Befehl-pro-Takt-Architektur hieße das, daß du in der inneren Schleife pro
Pixel 1000 Taktzyklen sparst....
Gigahertz ist mir egal. - Ich code auf einem 486er. Auf nem GHz-Prozessor kann jeder
Nappel in Interpreter-BASIC schon flüssige 3D-Routinen bauen. Das ist keine Herausforderung.

(Thema: Win und asm)
Entgegen aller Aussagen sind die eigentlichen Betriebssystemkerne und das GDI
vom Code her hochoptimiert und sehr stabil. Das Problem ist, daß das GDI halt
sehr generisch ist, und Windows an sich unter einem riesigem Ballast an
versteckter Funktionionalität und Kompatiblitätsaspekten zu alten Versionen in
die Knie geht. Das gleiche Problem gibt es mehr und mehr übrigens auch unter
Linux.
Was daran wirklich das Erschreckende ist: Private Coder schaffens, kompatibler zu dem
ganzen MS-Kram zu sein, als MS selbst. (Beispiel: DOSBOX v0.64 von... weiß grad nicht)
Will sagen: Privatleute haben nicht alle Specs und können teilweise nur RATEN, wenn sie
bestimmte Sachen implementieren/supporten.
MS dagegen hat alle Specs, weil sie selbst ja die Programme und Standards entwickelt haben
und tun sich absolut schwer mit Abwärtskompatibilität. Das schieben die jedesmal als
Entschuldigung vor:
"Sorry, wir haben damals zu scheiße gecodet - entweder wir schreiben ein schnelles OS,
was zu nix mehr kompatibel ist, was wir früher gemacht haben - oder wir schreiben ein
kompatibles OS, was dann eben langsam wird."
(Meine Meinung: Würde man viel von dem "Spielzeug" weglassen, das in Windows enthalten ist,
wär es schneller und sicherer. Das Spielzeug braucht kein Mensch. Manche bilden sich nur ein,
es zu brauchen - aber erst, seit sie es gesehen haben. Wenn man Leuten lange genug einredet,
daß sie irgendwas "unbedingt brauchen", glauben sie's halt leider irgendwann.)

(Thema: MP3-Player für 66 MHz)
Ich hab' mal einen MOD-Player zu 80% in 386-PM-Assembler implementiert - er wahr
wahnsinnig schnell und ca. 4kb groß. War eine Woche Arbeit und ich war sehr
stolz darauf. In C wäre der gleiche Player deutlich größer geworden, hätte ca.
75%-80% der Geschwindigkeit erreicht. Dafür hätte ich das Teil in zwei Tagen
zusammengestrickt.
Es hat Spaß gemacht, ich hab' ne Menge gelernt und es war kewl. Aber ich hatte
die Zeit, und Geld keine Sache. In einer real existierenden Welt kann man sich
das aber kaum leisten, denn 5 Tage Arbeit mehr für 20% Mehrleistung ist eine
Investition, die keiner macht: Es rechnet sich einfach nicht.

Ich dachte, wir reden hier vom Coding und nicht von Geld. Ich finde es
schlichtweg Sch*, daß sowas für private Coder schon ne Rolle spielt, "ob sich etwas
rechnet". - Ich überlasse solche Überlegungen lieber den Bonzen.

Dazu sind Assemblerprogramme schwer zu handhaben und fies zu debuggen, ihre
Komplexität steigt im Gegensatz zu Hochsprachenprogrammen deutlich schneller an,
genauso wie die schieren Codegrößen.
Ich denke mal nicht, daß asm-Programme größer sind als Hochsprachen-Programme. Eher umgekehrt.
Das einzige, was größer ist, sind die Sourcen.

Bei einigen 100 bis wenigen 1000 Zeilen ist das handhabbar, aber was ist mit
10.000, 100.000 Zeilen? Wie lange willst du an einem Betriebssystem entwicklen,
bis es marktreif ist. 10 Jahre? Nur damit es dann in handoptimiertem Assembler
läuft? Was ist mit den ganzen zusätzlichen Bugs, die sich dann einschleichen, da
Bugs einerseits von der Codekomplexität und andererseits von der Codemenge
abhängen?
Tja. Bloß gut, daß MS das nicht macht - sonst wäre Windows ja voller Bugs...

(Thema: Compiler)
Nein. Ganz defintiv nein. Man kann einen (modernen) Compiler schon sehr gut
hinten, was er tun soll. Aber meist kommt er schon selber drauf. Die modernen
Compiler sind wahre Meisterwerke. Mal ein kurzer Überblick, was ein Compiler so
tut:
[...]
Die modernen Compiler erzeugen einen Code, der, je nach Algorithmenqualität, in
Sachen Geschwindigkeit handoptimierten Code in nichts hinterhersteht.

[Xpyder]

Habe mal einen C64-Emulator programmiert. Abgesehen vom "Pascal-Frame" drumherum
(das ich nur benutze, damit er ne EXE draus macht...) ist das DIng 100% asm - und nur
diesem Umstand verdanke ich, daß er auf meinem 133 MHz Rechner mit voller Framerate
(50 fps) läuft. Er ist noch nichtmal maximal optimiert, aber hab schon noch diverse Ideen.
Also: C64-CPU läuft mit 1MHz. Pixel werden mit 8 MHz gezeichnet. Ich kann die aber nicht
"blockweise", sondern muß sie "zeilenweise" abarbeiten. Es gibt zB einen Modus, der
4-farbig ist, d.h. immer 2 bits ergeben 1 Pixel (so "Doppelpixel" halt). Die Farben werden
aber von woanders geholt... Also hab ich mir was ausgedacht:

nach EAX lade ich alle 4 Farben. 3 der Farben sind "Standard", die vierte halt "variabel"
für jedes Zeichen. Daher lad ich dieses nach AL. Es ist die Farbe für die Kombi 11.
Dann lad ich BL mit dem Bitmuster, das an der Stelle liegt (das ich zu interpretieren hab)
(BH ist 0) - und dann 2 linksschieben (*4), dann lad ich ECX mit einem Wert aus einer
1024 Bytes großen Tabelle. Diese Tabelle enthält für jedes der 256 Bitmuster 4x4 Werte,
nämlich immer 0,8,16 oder 24. Und zwar jeweils 0, wenn das "vorhergehende" Bitmuster eines
Pixels gleich war (also z.B. 00=00, 10=10), oder 8, wenn es eins "größer" war... Man wird
gleich sehn, was ich meine. Als "vorhergehendes" Bitmuster für den ersten Wert wird halt 11
angenommen - weil ich in AL ja den Wert für 11 habe.
So. Und nun "rechne" ich das "Pixelmuster" zusammen (in EDX)

rol EAX,CL; mov DH,AL; shr ECX,8; rol EAX,CL; mov DL,AL; shr ECX,8; ror EDX,16
rol EAX,CL; mov DH,AL; shr ECX,8; rol EAX,CL; mov DL,AL;

Abgesehen von den 8 und 16, die ich da für das "rotieren" hole (aber aus dem Code -
nicht aus anderem Speicher) mach ich in der gesamten "Berechnung" nur mit Registern
rum. Es ist nunmal der "zentrale Bereich". Dieses "8-Pixel-Block"-Zeichnen ist halt
das, was auch den realen C64 "timed". (D.h. die CPU kriegt ihr Timing wirklich vom
Grafikchip, weil innerhalb eines Befehlstaktes 8 Pixel gezeichnet werden.)

Ich arbeite eben gern mit wraparounds, nutze voll diese 8-Bit-Register aus, arbeite
mit Absicht mit Bereichsüberläufen (schon als ich noch kein ASM gecodet hab, hab
ich in PASCAL immer Festkommazahlen mit LONGINTs simuliert, auf die ich "parallel"
zwei WORDs oder 4 BYTEs gelegt habe).

Und diese Idee mit der "Rotations-Tabelle", damit ich in EAX die ganze Zeit die
vier Farben halten kann und halt die aktuelle immer an AL "rotiere" (wie so'n Rädchen
mit nem "Fenster" dran...) - Jetzt sag bloß, auf sowas wäre ein Compiler von allein
gekommen?

(Mal ne Anmerkung: Ich selbst habe zwar nur einen 486er. Aber ich schätze,
obenstehender Code ist eine Freude für jeden Pentium, nicht wahr?
- Glaub sind alle pairable.)

Btw: Ich arbeite ganz gern mit Tabellen. Mancher mag jetzt sagen, Tabellen würden
Speicher fressen. Aber: Mitunter wird vergleichbarer Code genauso groß. Und: wenn ich
extreme Geschwindigkeitseinsparungen dadurch habe, kann man dafür auch mal 256 Bytes
oder so opfern. (Anmerkung: Vorher hatte ich dasselbe Ding mit einer SCHLEIFE
realisiert, die die jeweils unteren 2 Bits ausmaskierte, in BX schrieb und dann aus
einer Tabelle, die die 4 Farben enthielt, die Farbe geholt hat.)

Und: Ich finde es nicht schlimm, sondern eher cool, Algorithmen an die Gegebenheiten
der jeweiligen Maschine anzupassen - das macht sie nochmal um einiges effizienter.
Daß jemand stolz darauf ist, gute maschinenferne Algorithmen zu bauen, ist zwar OK,
(wegen Portierbarkeit) aber andererseits spricht imo nichts dagegen, auf jeder Maschine
getrennt nochmal den Code speziell dafür zu optimieren.

Oder anders ausgedrückt: Wenn wir sowieso alle Computer so behandeln, als gäbe es nur
eine einzige Sorte davon (ohne deren Besonderheiten zu nutzen/berücksichtigen),
dann bräuchte es auch nur eine Sorte geben.
(Es spräche ja imo nichts dagegen, Hardware mal einigermaßen zu standardisieren.
Dann bräuchte man ENDLICH keine Treiber mehr!)

Und: EIGENTLICH sind alle IBM-PCs zueinander kompatibel, weil selbe CPU und gleiche
Hardware. Daß ein Linux- und ein Windows-Rechner NICHT mehr kompatibel sind, KANN
also nicht an der Hardware liegen, sondern liegt IMMER an der Software.

Daß Software aus kommerziellen Interessen MIT ABSICHT inkompatibel ist, kann man zwar
aus Sicht von BONZEN durchaus verstehen - aber es ist keine Rechtfertigung dafür, daß
es eigentlich beschissen ist.

(Thema: Lösungen in asm und Hochsprache)
Wo die Grenze zwischen Logik und Technik zu ziehen ist. s.u.
Strings sind meistens Bitschubsereien, daher eher bei Technik als bei Logik
einzusortieren.
Ja, sicher. Aber wenn sich dann schon die Frage stellt: Wie kann ich die
Ziffern rückwärts speichern? (und sich sowas zu nem Problem auszuwachsen
scheint) - Dann sollte man sich fragen, ob da die Hochsprache nicht schon
ein wenig zu abstrakt ist. Denn sowas sollte z.B. ohne weiteres
jederzeit möglich sein!

[Xpyder]

Wenn man es systembezogen machen muß sollte man es tun. In allen Fällen sollte
man sehr genau abwägen, weil man sich den vermeintlichen Vorteil durch
Inkompatiblität und reduzierte Portablität erkauft. Und wenn ein Algorithmus
Assembler vorraussetzt um performant zu sein, sollte man den Algorithmus noch
mal durchdenken.

Nö. Finde ich nicht. Warum soll man die Vorteile, die einem z.B. geteilte
Register, 64k Pages (ja! - sowas kann auch ein VORTEIL sein!) und ähnliches
bieten, denn nicht nutzen?
Ich persönlich finde, daß es nicht darum geht, wer den abstraktesten
Algorithmus findet, sondern, daß man ein schnelles Programm schreibt.
Und wer findet, daß es - um elegant aussehender Algorithmen willen - nur lohnt,
bis zu dieser Ebene zu optimieren und den Rest dem Compiler zu überlassen -
na meinetwegen...
Aber ich gebe immer zu bedenken: Der CPU sind Algorithmen egal. Und auch, wie
nett der Quelltext aussieht. Mich interessiert, was der Rechner wirklich
macht, wenn ich das Programm ausführen lasse.
Ach ja: Und ob ein Sprung "wahrscheinlich" ist oder nicht - weiß z.B. bei einem
Emulator ein Coder immer besser als ein Compiler. Der Compiler müßte an
dieser Stelle ja verstehen, was das Programm macht - also welchen Zweck
es erfüllt. Und das wäre schon künstliche Intelligenz.

Ich war auch mal in der Demoszene, ist schon paar Jährchen her, und Assembler
war dort auch eher in den zeitkritischen Zentralbereichen angesagt. Unter DOS
kam - man höre und staune - meistens Borland Pascal als Framework zum Einsatz.
Der Grund ist einfach, aber wenig schmeichelhaft für Borland: Der BP-Compiler
baut einen sehr berechenbaren Code, und sein Codegenerator war unter aller Sau,
die ideale Schnittstelle für Inline-Assembler und dazugelinkte Prozeduren... *g*
Endlich versteht mal jemand, wieso ich PASCAL (als "Rahmen") benutze.
Hatte das vor ner Weile mal versucht zu erklären...

Das wirft schon einen Blick darauf, wie programmiert wurde. Der Algorithmus, die
Idee, wurde zunächst in Pascal umgesetzt, die Performance war dementsprechend.
Dann wurde der Algorithmus immer weiter verfeinert. Und anschließend ausgewählte
Teile des Algorithmus in Assember optimiert. Aber mitnichten bestand das ganze
Programm aus Assembler. Nur ausgewählte Teile.
Tja. Genau so arbeite ich auch.
Es hörte sich nur letztens so an, als wär's kompletter Schwachsinn, heute überhaupt noch
Assembler zu lernen.
(Zeit-UN-kritische Dinge - also Zeug außerhalb von Schleifen u.ä. setz ich natürlich auch
nicht immer alle in ASM um. Die Zeitersparnis ist hier wirklich "quasi" Null -
da sie sich ja nicht mehr potenziert. Da haben wir uns wohl letztens mißverstanden.)


Außerdem ist der Gewinn durch Assembler oftmals ein Phyrrussieg. Ein Beispiel.
Es gibt einen Effekt namens statics dissipation, der bei Assemblerprogrammierern
oftmals zuschlägt und im Embedded-Bereich die Entwickler immer wieder einholt.
Während viele Hochsprachler für Temps (also temporäre Werte, speziell
irgendwelche Buffer) eben kurz auf dem Heap anlegen und wieder wegwerfen,
scheuen Assemblerprogrammierer oft den Aufwand einer Heapverwaltung. Die Lösung:
statics, also statische Variablen. Die müssen aber relativ großzügig angelegt
werden um auch worst-case-Szenarios abdecken zu können...

Kenne das Problem - nur gut, daß PASCAL eine Lösung anbietet. Die temporären Variablen
einer Subroutine ("procedure") in PASCAL werden ja immer auf den Stack geschmissen...
(D.h. ich kann "Variablen" auch für asm-Routinen anlegen.)
Und ne Heap-Verwaltung hab ich mir davon abgesehn aber trotzdem mal geschrieben.
Dynamische Pointer. Nette Geschichte.

Hochsprachen wurden erfunden, damit man sich auf das Wesentliche - den
Algorithmus und die Problemlösung - konzentrieren kann und sich nicht mit der
Abstraktion von Bitschubsereien und der Darstellung der Logik in Bits herumärgern muß.
Anders ausgedrückt:
Assembler ist die Abstraktion der Technik,
Hochsprache ist die Abstraktion der Logik.
Das Wesentliche ist für mich immer, es schnell und ressourcensparend
hinzubekommen - denn das unterscheidet ja zwei Programme, die dasselbe tun, voneinander.
Der Algorithmus wäre in beiden Fällen ja der gleiche. - Aber die Umsetzung
kann von unterschiedlicher Qualität sein. Und wer schon beim Entwickeln eines geeigneten
Algorithmus seine Probleme sieht, der sollte sich überlegen, ob er wirklich coden will.
Denn diese zu entwickeln - also sein Problem auf eine "Formel" abzubilden - ist eigentlich
die Grundvoraussetzung für jeden Coder - egal ob Skript, Hochsprache oder Assembler.

[Xpyder]

Und, übrigens: Ich ärgere mich nicht herum, wenn ich asm-Bitschubsereien code. Das ist
genau das, was mir am Coding Spaß macht. Das, was mich nervt ist eher, für den Mist so
Oberflächen u.ä. zu bauen, weil das halt so Skript-Mist ist, den auch irgendwelche Designer oder
so Semi-Coder (halt so HTML-"Programmierer" oder sowas) machen können - es interessiert mich
eben nicht, mangels Herausforderung.
Will sagen: Geht man davon aus, daß das Programm ein Interface zwischen Mensch und CPU ist, gestalte
ich lieber die CPU<->Programm Seite dieses Interfaces als die Programm<->Mensch Seite.
(Vermutlich, weil mir Maschinen irgendwie näher stehen als Menschen. Für Menschen ist so
Menschen-Scheiß wie "Kosten-Nutzen-Rechnung" (also Geld) und "Programmierbequemlichkeit" wichtiger
als "Effizienz". Und für mich halt nicht. Deswegen versteht mich auch keiner.)

Beides hat seinen Sinn. Beides hat seinen Platz. Man muß nur wissen, wo man die
Grenze zieht. Im Idealfall bewegen sich beide aufeinander zu.
Sehe ich genauso.
(Und nochmal: Es ist nicht so, daß ich immer alles in asm mache! Ich verwahre
mich nur dagegen, daß man asm als etwas, das "heutzutage kein Mensch mehr braucht"
oder so, darstellt.)
Es gibt nur, wenn irgendwas zu langsam läuft, zur Zeit zwei Sorten Leute.
Die einen sagen:
"Wenn Dir mein Programm zu langsam läuft, kauf Dir 'n schnelleren Rechner."
Die anderen sagen:
"Wenn Dir mein Programm zu langsam läuft, muß ich es optimieren."

Und ich finde: "Kauf Dir 'n schnelleren Rechner" sollte ein Coder erst sagen,
wenn er alles, was softwareseitig möglich ist, um es schneller zu kriegen,
getan/versucht hat.
Nochmal zu Windows: Das, was die meisten Leute heutzutage von Windows nutzen,
ist nicht mehr als das, was auch schon Win 3.11 konnte.
Nur brauchen sie heute dafür Rechner, die über hundertmal so schnell sind und
das 50-bis-1000-fache an Speicher und Festplatte benötigen.
An dieser Stelle sollte man (als Programmierer) nachdenklich werden.
(Um zu erkennen, daß an dieser Geschichte was faul ist, braucht man
nur die vier Grundrechenarten und etwas gesunden Menschenverstand.)

(Thema: "Was in asm nicht geht, muß man löten.")
Möglicherweise nicht mal das. Das ist dann der Zeitpunkt, wo man ein schönes
Buch in die Hand nehmen und sich klar machen sollte, daß Bäume schon einige
Milliarden Jahre existieren, ohne daß sie die Digitaltechnik wesentlich tangiert
hätte. Unmöglichem begegnet man am besten mit philosophsicher Ruhe.

Eigentlich hatte ich das ja nur als Footerzeile benutzt - wie manche andere Leute sowas
auch manchmal machen. Gemeint ist damit ja eigentlich, daß, wenn es in Hochsprache nicht
geht, man ja immer noch asm hat. Und erst, wenn das nix mehr hilft, es dann
wirklich als "softwareseitig nicht lösbar" angesehen werden kann.
Nicht, daß ich was gegen Bücher hätte - eher im Gegenteil.

Aber... Bäume, philosophische Ruhe... - irrelevanter Menschen-Scheiß (siehe oben).
Kann ich absolut nix mit anfangen, da es keines meiner Probleme löst.
(Abgesehen davon, hat sich die Digitaltechnik in den letzten 50 Jahren schneller
entwickelt als Bäume und ähnliches in den letzten 50 Millionen Jahren. - Finde nicht,
daß man sowas nicht zur Abwechslung auch mal anerkennen sollte.)

Soll ich mal sagen, wie ich das Problem löse, daß ich manchmal bei einem Projekt "festhänge"
und nicht weiterkomme? - Wie jeder Coder weiß, hilft es ja, zu seinem Quelltext "Abstand" zu
bekommen (ihn also eine Weile nicht sehen) - um nicht "betriebsblind" zu werden. Nach einem
Monat oder so schaut man sich den Quelltext wieder an und sieht das Problem auf den ersten Blick,
weil man wieder "unvoreingenommener" drangeht.
Deswegen habe ich immer einige Projekte gleichzeitig am Laufen. Komme ich bei einem nicht weiter,
setze ich ein anderes fort (oder starte auch mal ein neues). Dadurch habe ich eine schöne
"Rotation" drin. Ein weiterer Vorteil daran ist, daß man mitunter bei Projekten, die nichts
miteinander zu tun haben, zu Erkenntnissen kommt, die man dann für das jeweils andere Projekt
benutzen kann. Und schlußendlich ist da ja auch noch der Vorteil, daß man, obwohl man Abstand
gewinnen will, trotzdem nicht auf programmieren verzichten muß.
Denn Bäume/Wiese/Natur gibt mir überhaupt nichts. Einen Tag ohne Computer dagegen könnte ich
mir nicht vorstellen. (Ja, ich weiß - ich bin ein Freak...)

Irgendwer fragte mich mal: "Du hängst immer nur alleine am Rechner rum - was hättest Du nur vor
100 Jahren gemacht, als es noch keinen Computer gab?"
Und ich sagte darauf: "Dann hätte ich ihn wohl erfunden."
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Achja: ENTSCHULDIGUNG AN ALLE BOARD-TEILNEHMER!
Eigentlich wollte ich das nicht schon wieder in eine Grundsatzdiskussion ausarten lassen.
Aber was soll man machen? Ich will sowas auch nicht einfach ignorieren, wenn
ich finde, daß ich dazu etwas sagen muß.

[Xpyder]

Es gibt einen C64-Emulator namens VICE.
Eigentlich guter Ansatz, weil er wirklich jeden Side-Effect
der C64 Chips abdeckt.
Aber er halt auf mehrere Systeme immer "portiert".
Letztens haben sie stolz reingeschrieben, daß sie ein paar
ASM-Routinen entfernt (!) und durch C-Routinen ersetzt haben(!!)
- (quasi als "Verbesserung").

Tja. Leider muß man auch sagen, daß dieser Emulator mit
jeder neuen Version langsamer wird, ohne wirklich erkennbare neue
Features. Einige Bugs verschleppt der schon seit 6 oder 8 Versionen
immer weiter.

Also den "Nutzen" für den Endverbraucher kann ich dann nicht mehr ganz
erkennen, daß das einzige, was er von ner neuen Version hat ist, daß
sie langsamer ist. - Weil es einen User (zurecht!) nicht interessiert,
ob die Entschuldigung dafür ist, daß es das Ding dafür auch auf irgendeinem
System, das er nicht hat, auch noch gibt.
Für ihn ändert sich nur, daß er ein langsameres Programm bekommt. Oder
einen schnelleren Rechner braucht.

Und: An der Stelle geht's noch, weil das Ding ja Freeware ist.
(Bzw GNU Dingens...)

Aber: Wenn eine kommerzielle Softwarefirma sagt: "Dafür, daß
unsere Software nicht so optimiert ist, kostet sie ja auch weniger,
weil Entwicklungskosten gespart."
Kann ich nur sagen:
1.) müßten nach dieser Theorie die (imo permanent viel zu überzogenen)
Preise für Anwendungen/Spiele enorm fallen - was sie nicht tun.
2.) Selbst dann würde man das, was man beim Softwarekauf wirklich einspart
(was ja de facto eigentlich NICHTS ist) - dafür ständig in neue Hardware
investieren müssen, damit die Software dann wieder schnell
genug läuft.

Der Endverbraucher ist also doppelt angeschissen. Erstens teure Software.
Zweitens, weil Software-Entwicklungskosten gespart werden,
auch ständig neue teure Hardware.
Einzige Möglichkeit: Man beteiligt sich nicht am Rechner-/Hardware-Wettrüsten.
(Man ist dabei sowieso immer der Verlierer.)

Ich weiß: Leute wie Ich sind der Alptraum jedes Industriebonzen.

[bbfy]

also maschienhahes programmieren d.h. assembler wird so complieirt wie dus geschrieben hast 1:1 zu computersprache also befahl mov heisst übersetzt 10 also und einweiterer vorteil bei assembler ist extrem hohe rechengeschwindigkeit und die programme brauchen viel weniger platz als wenn die z.B. mit c++ geschrieben wurden :D also dann viel spass beim erlernen
ach und für jeden prozessor gibt es bestimmte besonderheiten aber sonsten ist alles gleich:)