Maschinensprache/Assembler - wo gingen eure Erfahrungen los, warum, welche und was sagt ihr retrospektiv dazu?

Ich habe erst relativ spät und nur kurz mit Assembler zu tun gehabt, da ich mir privat lange keinen Rechner leisten konnte - schon gar nicht in der Jugend.

In meiner ersten Ausbildung haben wir SPS in AWL programmiert - nicht wirklich Assembler, aber ähnlich. Und immer noch einfacher als mit Kippschaltern und Zettel, was ich auch noch kennegelernt hab.

In meiner zweiten Ausbildung nach dem Studium haben wir Ampel- und Robotersteuerungen in Assembler programmiert. Aber fragt mich nicht was und wie, das ist ewig her und ich hab das nie wieder gebraucht.

Inline Assembler habe ich dann unter DOS noch gelegentlich genutzt, aber in neuerem Code unter Windows mache ich das praktisch gar nicht mehr.

In den Firmen, für die ich gearbeitet habe, konnte ich von alledem fast gar nichts gebrauchen. Zwar saß ich zuletzt auch mal an einer Steuergeräteanalyse und -modifikation für VW, wo ich das vielleicht hätte ausgraben können / müssen. Aber das Projekt wurde im Spetember 2015 über Nacht eingestampft. Hat mir vielleicht 'ne Blamage erspart.
 
Durch das Reverse-Engineering von Malware bin ich zum ersten Mal tief genug in ASM eingestiegen. Neben Malware-Analyse waren auch Exploits von Speicherfehlern (Buffer Overflow, Integer Overflow, Use-After-Free) ein Thema, wirklich eigene Exploits hab ich bisher aber nie geschrieben bzw. gefunden.

Ging so richtig ca. 2017 los 😅

in welchem Assembler
Bisher nur x86 und x86-64.

auf welchem(n) Gerät(en)
Meistens in einer Windows 7/10 VM.

Wie steht ihr zu Assembler heute?
Einesteils will ich schon noch besser in Reversing werden aber andernteils ist moderne Malware teilweise echt PITA. Genauso sind aktuelle Anti-Exploit Mechanismen schwer zu überwinden. Dafür das aktuelle Entwicklungsumgebungen (Jetbrains, VScode etc) einen das Entwicklerleben echt angenehm machen, sind die Disassembler und Debugger alle irgendwie in der Steinzeit hängen geblieben. Egal ob IDA Pro, Ghidra, WindDbg, Radare2, gdb, Immunity etc. Meine autistischen Züge sind wohl einfach zu schwach um mit dem gebotenen UI irgendwie effektiv arbeiten zu können.

Rein bei der "legitimen" Anwendung von ASM... jedem das seine. Wenn man auf Microcontrollern unterwegs ist oder ganz tief in irgendwelchen Treibern oder Kernels rumpfuscht dann versteh ich manchmal noch die Gründe. Aber IMHO ist das Lesen und Verstehen von Hochsprachen ist schon anspruchsvoll genug. Wartbarkeit und Sicherheit von Code finde ich wichtiger wenn man diesen auf die Allgemeinheit los lässt.
 
Zuletzt bearbeitet:
Mir fällt dazu nur Sentimentales ein... habe damals mit dem Sinclair ZX81 angefangen, irgendwann kam der Spectrum dazu.
Programmiert wurde dann bald in Maschinensprache, die Zahlenkolonnen wurden also selbst ermittelt, den Luxus, in Z80-Assembler schreiben zu können, hatten wir nicht. Naiv wie man war, wurden bekannte Computerspiele nachprogrammiert und dann in einer Computer-Zeitschrift inseriert. Ein Besuch durch die örtliche Polizei aufgrund einer Anzeige wegen Verletzung von Markenrechten/Produktpiraterie o.ä. ließ nicht lange auf sich warten. Die Sache wurde aber eingestellt, als die Herren in Grün da nur ein paar Kiddies antrafen.
Zu dieser Zeit kam auch der Jupiter ACE auf den Markt, falls sich jemand erinnert, ein ZX81-Clone, der aber in Forth programmiert wurde.
Ich konnte ihn mir nicht leisten, habe aber das Handbuch bestellt. Die Sprache Forth fand ich dann eine Zeit lang faszinierend und habe dann einfach in Maschinensprache selbst einen Forth Interpreter geschrieben.
Spaßig war es auch, den Ein-/Ausgang zum Beschreiben der Kassetten als 1-bit Sampler bzw. 1-bit Audio-Ausgang zu missbrauchen. So konnte man mit etwas gutem Willen schon Geräusche mitschneiden oder wieder ausgeben.
Daneben habe ich (wie offenbar auch andere) Hardware-Prototypen mit TTLs und später auch CMOS-Bausteinen gebaut, allerdings nicht in Fädeltechnik, sondern mit Silberdraht auf Lochrasterplatine verlötet, wie ich das heute immer noch mache. Endpunkt war der Versuch, einen Z80 zum Laufen zu bringen, der Einfachheit halber mit SRAM statt mit dynamischem RAM, da ich mir den Refresh nicht zutraute. Dieses Projekt ist aber in irgendetwas gescheitert.
Es folgte dann eine lange Zeit, in der ich lieber Musik und anderes gemacht habe, jedenfalls nicht programmiert.
Im Studium waren dann Modula-2, Prolog und Lisp angesagt (das waren eindeutig die frühen 1990er!) und Maschinensprache spielte keine Rolle mehr.
Zu Hause hatte ich einen Atari ST, den ich mit Mark Williams C programmiert habe, das war eine nette kleine Unix-ähnliche Entwicklungsumgebung einschließlich Shell, Micro-Emacs, Compiler usw.
Die Effizienz des compilierten C-Codes war dann für meine Zwecke ausreichend. Im Wesentlichen habe ich ein sehr rudimentäres Sequencer-Programm geschrieben und ein kleines Textsatz-Programm (das Wort ist etwas übertrieben), mit dem ich meine Seminararbeiten in Proportionalschrift und Blocksatz auf einer Olympus-Schreibmaschine ausdrucken konnte. Ein Ausdruck auf der Schreibmaschine dauerte ewig, das Ergebnis sah aber viel besser aus als mit einem der damals üblichen Nadeldrucker. Dann allerdings brauchte ich LaTeX, der ST und die Olympus gaben ihren Geist auf, und die Sache war obsolet.
Im Moment schreibe ich ja einen Softsynth in C++. Es käme mir aber nicht in den Sinn, Teile davon in Assembler zu schreiben. Da das ganze auf (x86-64) PCs und auf Apple-Rechnern laufen soll, eventuell später auch noch iOS oder Android-Geräten, wäre mir das zu kompliziert, hier alle relevanten CPU-Typen abzudecken. Es gibt ja SIMD-Abstraktionen, die cross-Plattform nutzbar sind, vermutlich werde ich zwecks Optimierung eher zu diesem Mittel greifen und nicht auf das Assembler-Level runtergehen.
 
Zuletzt bearbeitet:
So, jetzt habt ihr mich soweit, ich bestell mit jetzt ein ESP32 RP2040 Board und setze einige Ideen um ...
... Es käme mir aber nicht in den Sinn, Teile davon in Assembler zu schreiben. Da das ganze auf (x86-64) PCs und auf Apple-Rechnern laufen soll, eventuell später auch noch iOS oder Android-Geräten, wäre mir das zu kompliziert, hier alle relevanten CPU-Typen abzudecken. Es gibt ja SIMD-Abstraktionen, die cross-Plattform nutzbar sind, vermutlich werde ich zwecks Optimierung eher zu diesem Mittel greifen und nicht auf das Assembler-Level runtergehen.
Sicherlich wäre der Aufwand für mehrere Plattformen recht groß. Allerdings ist das Schreiben in Maschinensprache ja auch nur die eine Seite der Medaille. Ich kann mich noch sehr gut an Bugs erinnern, bei denen der Maschinencode fehlerhaft war im Zusammenspiel mit dem Prozessor. So etwas bekommt man eine Ebene drüber vermutlich niemals heraus ... soll heißen, nur Lesen können kann auch schon nützlich sein.
 
Erst C64, dann Amiga mit Seka, später mit Devpac und ASM-One. Seit Jahrzehnten nix mehr gemacht.
 
Zuletzt bearbeitet:
Mental Hangover 2 habe ich damals übrigens live via Beamer auf der Silents/TRSI Party in Dänemark gesehen (müsste so um 1990 gewesen sein). MH2 war aber ein Videodemo und lief via VHS.
Budbrain hat mit dem Megademo damals die Demo-Competitipn gewonnen (kann aber jetzt sein, dass ich das mit der Dexion Converence verwechsle, was ebenfalls in Dänemark stattfand)

The Silents gibts glaube ich heute immer noch.
Ihr erste kommerzielle Nummer war: Pinball Dreams und dann Pinball Fantasies auf dem Amiga. Sie gründeten „Digital Illusions“, was später zu DICE wurde (heute bekannt mit der Battlefield Series).

Alle haben ausschließlich mit ASM programmiert. Kompakte codes, extrem schnelle Routinen und elegante Umsetzung.

Und AFL (Alpha Flight) sollte nun wirklich jedem ein Begriff sein, der damals einen C64 besaß 👍🏻
TRSI steht übrigens für: Tristar + Red Sector Inc.
 
Zuletzt bearbeitet:
...
The Silents gibts glaube ich heute immer noch.
Ihr erste kommerzielle Nummer war: Pinball Dreams und dann Pinball Fantasies auf dem Amiga. Sie gründeten „Digital Illusions“, was später zu DICE wurde (heute bekannt mit der Battlefield Series).

Alle haben ausschließlich mit ASM programmiert. Kompakte codes, extrem schnelle Routinen und elegante Umsetzung.
...

Ja, danke für die Geschichtsstunde, jetzt wo du es nochmal aufzählst, fällt es mir auch wieder ein. Die Pinballs kenne ich natürlich, war bei mir immer sehr beliebt, da man gut 20 Minuten zocken kann und wieder raus, im Gegensatz zu vielen anderen Games. Bin nicht mehr so der Gamer, gibt so viele andere Dinge, die weniger passiv sind. Das mit DICE, ja klar, hätte klingeln müssen. Aber so Ego-Shooter, ich sag mal so, habe ich mal probiert. Wird mir irgendwann zu repetitiv. So ein Witcher 3 dagegen ... das war mein letztes Game, länger her schon. ;-)

Ja, die Demo-Parties damals, das war schon recht cool! Nerdkram ;-)
 
Pinball Dreams und dann Pinball Fantasies auf dem Amiga
Ohja - die waren legendär. Die waren so geil, das selbst mein Mütterlein - die Videogames leidenschaftlich verachtet - diese Games mit Leidenschaft gezockt hat.
Aus der Demoszene sind einige Top Programmierer hervorgegangen.

Erstaunlich, was die Leute aus den wenigen Kilobytes zaubern konnten. Daran musste ich letzthin wieder denken, als mein Maustreiber sagenhafte 500MByte aus dem Netz saugen musste...
Gibt afaik heute noch 1kbyte Contests.
 
Nach Basic auf dem ZX81 und 800XL bin ich erst mit dem Amiga in Assembler eingestiegen, erst mit Seka, später dann mit dem ASM-One.
Den 68k zu programmieren fand ich damals dank des Befehlssatzes ziemlich komfortabel und der Amiga war auch wegen den Co-Prozessoren (Copper, Blitter, Paula ect)
und den späteren AGA-Modellen ziemlich fähig.
Leider hat Commodore dann nach dem A1200/4000 einfach den Anschluß verpasst.

Programmiert hatte ich ein paar Demos und Tools, u.a. für TRSI, Rebels, Cryptoburners, Dual Crew Shining und ein paar mehr.
War schon eine echt coole Zeit!

Fabriziert hatte ich u.a. sowas:
 
Ist das Wirewrap draht oder welcher Draht?
Das war nur einfacher dünner Basteldraht von Conrad oder Reichelt. Hatte den Vorteil, das ich hier verschiedene Farben hatte, Blau für Masse, Rot für VCC, Gelb für Digital-Signale und Grün für die Analog Signale an den Muxern.
Das Abisolieren der jeweigen Drahtenden war etwas friggelig, schlussendlich hatte ich das einfach per Lötkolben gemacht - ein paar Sekunden dranhalten und schon war das Ende abisoliert.
Am Ende war das Abisolieren/ Wegschmelzen per Lötkolben und gleichzeitiges verzinnen ein Durchgang - unprofessionell aber effizient :mrgreen:
 
Zuletzt bearbeitet:
Mich würde mal interessieren, was ihr so damals in welchem Assembler, auf welchem(n) Gerät(en) gemacht habt, und wie ihr das im Nachhinein beurteilen würdet.
C-64 Synthesizer komplett in 6502 ASM sowie später für 6510 - zunächst sogar für den VC20. Am Anfang nur über Tastatur spielbar, dann auch über MIDI.
In der umgebauten Version ging das dann sogar auch für den Amiga:

Der Yamaha lief dann zusammen mit einen Synthy im 64.

Wie steht ihr zu Assembler heute?
Schon Mitte der 1990er habe ich nur noch C gemacht. Die Compiler sind gut genug, ums effektiven Code zu generieren. Letztmalig kam Assembler professionell bei der AV-Optimierung einer C-Software für den AMD-K6 1997/1998 zum Einsatz. Der K6 hatte spezielle Befehle, die viele Compiler nicht unterstützten. Das war es dann aber.

Vieles ist in C einfach schneller und effektiver zu formulieren. Das allerletzte mal gab es ASM für den Motorola im Chameleon - im privaten Einsatz:
Es gab da eine Optimierung in Coldfire-Assembler bei einem Treiber.
In der Chammy habe ich dann übrigens den umgekehrten Weg beschritten und den SID aus dem C-64 direkt in C nachgebildet, um die Sounds zu haben. Heute baue ich sowas bevorzugt in Python. Ist aber auch 1-2 Ebenen darüber.
Im professinellen Umfeld ist Tempo und Effizienz gefordert. Nur in wenigen Nieschen sind die Stückzahlen so hoch, dass man sich die größere Entwicklungsarbeit leistet. Ich hatte in den letzten 15 Jahren alle erdenklichen Projekte, aber nie mehr irgendwo ASM gesehen.

Was das eigene Tun angeht, bin ich auch kurze Zeit später auf FPGAs umgestiegen, wie die meisten wissen. Auch dafür wurde eine C-64-Emulation des SID erzeugt - zusammen auch mit etwas analoger Modellierung um den ominösen Ausgangstransistor ins Spiel zu bringen.

Teile der ersten Modellierung für sowohl ein TI TMS320-Modell aus den 1990ern (Studienzeit), als auch die Algos im FPGA 10 Jahre später, waren zunächst nur in C formuliert und wurden mittels "Catapult C" übersetzt. Schon da war also Assembler raus. Auch die Softcores in den FPGAs wurden - obwohl nicht sehr leistungsfähig und damit bei den langsamen FPGAs der 2000er platzbelegend - immer in C programmiert. Schon um 2005 hatten wir Cyclone mit NIOS zusammen mit einem einfachen Linux am Start. Willst du da Multitasking machen, bist du schon mit C schnell am Ende und brauchst C++.

Es gab mal eine kurze Zeit zwischen 2003 und 2007, da waren die AVRs stark im kommen. Die Foren waren voll mit ATMEL-Enthusiasten, die vereinzelt eben auch noch mit ASM hantierten. Das waren aber auch Leute, die entweder Spezielles wollten oder altersbedingt am ASM hingen.
 
Alpha Flight, zumindest vom C64, sollte wirklich jedem ein Begriff sein genauso wie Ikari + Talent, The Ruling Company, Eagle Soft und, und, und, so viele geile Leute damals auf dem C64 gewesen...

Wenn jemand ein paar Intro von damals im Browser sehen möchte, hier mal einige von Alpha Flight und von mir...

 
so viele geile Leute damals auf dem C64 gewesen...
Der C64 war der Wegbereiter für eine ganze Generation von kreativen Musikern- aber auch Ingenieuren! WIR (tm) haben genau passend ab 1980 die richtigen "Spielzeuge" gehabt, um Programmieren und Elektronik draufzuhaben, lange bevor wir in der ersten Vorlesung saßen. 10 Jahre später war die Nummer durch und die Computer zu kompliziert, um damit zu lernen. Die heutigen spielen nur noch und wissen von Ports, Befehlen, Strömen und LEDs nichts mehr. Der Zusammenhang ist verloren gegangen. Ich habe den Riss live erleben können, als ich Laborbetreuer an der Uni war: Zwischen 1996 und 1998 gab es plötzlich einen rapiden Abfall der Kenntnisse der Anfänger: Niemand von denen hatte mehr einen Heimcomputer programmiert. Die fingen all bei Null an. 10 Jahre später hat es nochmal einen Bruch gegeben: Ab da kamen die ersten an, die G8 Abi hatten und dann die Bologna-Studiengänge anfingen.
:amen:
 
Zuletzt bearbeitet:
Ich meine nicht dieses pseudo Alexa Gerede.

Das werden wir nicht mehr anders erleben? Wenn ich mir die "Online-Welt" so ansehe, bin ich auch nicht mehr so sicher, ob die Menschheit dafür schon bereit ist. Mein erster Gedanke dabei ist: "Noch mehr Schaden, noch schneller.", deswegen bleibe ich lieber bei Musik. Wenn ich wieder entwickeln sollte, dann in dem Bereich. Damit macht man Leute wenigstens glücklich und nicht unzufrieden und gestresst oder unglücklich (FB, Instagram und der ganze Rotz.)

... Übrigens trinke und rauche ich nicht ;-)
Siehst du!

Weise Entscheidung. Nein, tue ich beides auch nicht mehr. Also trinken nur bei gegebenen Anlässen und da auch nur in Maßen und nach Laune.

Back to machine code. Ich fand damals auf dem Amiga den Blitter so klasse, endlich Vektorgrafik ohne selbst einzelne Punkte zu setzen. Wie ahnungslos ich da noch war, da wusste ich noch nicht von der Vectrex.
 
Da wir beim Thema ASM (und teils Demos) sind:
Was lässt sich (gepackt) so innerhalb 64k realisieren (ja, 64 kilobyte!) ? Wie gross sind noch mal hp-Druckertreiber? ..oder Adobe Acrobat?

-> https://www.sequencer.de/synthesizer/threads/digitaler-minimalismus-64kb-demos.151269/

Es geht noch kompkater, aber 64k ist schon mal eine gute Basis um zu zeigen, was man mittels ASM da so hinbekommt (inkl. Musik).
Du hast in den meisten Rechnern keine vollen 64K frei - da ist das BASIC drin, dann noch diverse andere Dinge und Spezialadressen - also 38k beim C64, der Spectrum hatte 48k - da ist natürlich auch noch ein bisschen Zeug was vom System genutzt wird dabei.
Das ist allerdings auch nicht so, dass es da nur um Menge geht - du musst ja nicht konkrete Bilder sichern sondern machst auch viel Konstruktion und dann wird alles auch "kleiner" - wogegen ja in Demos sehr gern Bilder und Effekte eingebaut werden um zu zeigen, was man am Ende machen könnte und kann.
So gesehen sind die Demos von "heute" beeindruckender als das was man damals machte. Der Link zeigt ja eher was heute mit ganz anderer Technik geht. Mit den alten Geräten muss man ja noch die Welt nutzen die da dran hängt.
 
Du hast in den meisten Rechnern keine vollen 64K frei - da ist das BASIC drin, dann noch diverse andere Dinge und Spezialadressen - also 38k beim C64,
Genauer sind beim c64 38911 Bytes an RAM verfügbar (gewesen). Das sieht man auch gleich nach dem Einschalten.
Man kann das aber teils umgehen und mehr RAM nutzen.
der Spectrum hatte 48k - da ist natürlich auch noch ein bisschen Zeug was vom System genutzt wird dabei.
Und beim VC20 sogar nur 5kb all-inclusive ;-)
Das ist allerdings auch nicht so, dass es da nur um Menge geht - du musst ja nicht konkrete Bilder sichern sondern machst auch viel Konstruktion und dann wird alles auch "kleiner" - wogegen ja in Demos sehr gern Bilder und Effekte eingebaut werden um zu zeigen, was man am Ende machen könnte und kann.
So gesehen sind die Demos von "heute" beeindruckender als das was man damals machte. Der Link zeigt ja eher was heute mit ganz anderer Technik geht. Mit den alten Geräten muss man ja noch die Welt nutzen die da dran hängt.
Mir geht's darum, dass die 64kb-Demos alles beinhalten (Texte, Code, Musik, ggf. kleine Texturen - Grafik kaum, das wird gerendert) - in ausgezeichneter Qualität (oft HD-Auflösung wahlweise einstellbar) daherkommen - und dennoch gepackt nicht über 64kb hinausgehen.
Wenn ich mir z.B. das Demo fr-019 "Poem to a Horse" von Farbrausch anschaue, was vor 20 Jahren programmiert wurde (!), dann müsste alleine der Text über 64k hinausgehen (sofern es ASCII/HEX-Text im Code wäre, was es sicherlich nicht ist, sondern ebenfalls gerendert). dann noch die Musik in ausgezeichneter Qualität - und all das nicht über 64kb.
 
Zuletzt bearbeitet:
Ja, das ist eine Kunst für sich - und das ist eher wie ein Battle, eine Challenge - und wer sie nimmt wird sie auch durchziehen.
Wenn wir müssten, würden wir alle minimaler arbeiten (können).
Wie effizient ist dann eine Frage die man sich stellt. Aber man braucht viel Zeit. Ja, man könnte Dinge natürlich auch komprimieren und so weiter. Das sind Menschen mit 7 Gehirnen.
 
Das ist ja eher so eine "neue" Variante der 64kB-Challenge... Da wird dann beim Klick auf die .exe bestimmt nicht nur was entpackt sondern gleich mal was vorgerendert und irgendwo gecached. Das alles wird temporär auch "etwas" mehr RAM benötigen. Und CPU-Zyklen auch... ;-) Trotzdem beeindruckend.
 
in ermangelung einer powercore SDK bin ich etwas assembly-artigem erstmals in flowstone begegnet und konnte nach 5 minuten mein vorurteil bestätigen, wonach ich für so etwas zu doof bin.

ich muss immer das, was ich mache, auch in einer für mich verständlichen form vor mir sehen, sonst bin ich raus.

programmieren ist für mich teil meiner kreativen arbeit, dabei will und kann ich nicht gleichzeitig über theoretische informatik nachdenken.

ein biquad sollte bitte mit expr beginnen und nicht mit kwww kkkk kwkk 0k0k 00ww, ich bin doch kein alien!
 


Zurück
Oben