Das 6502-Befehlssatz ist ein guter Einstieg in die erste Assemblersprache

• Assembler steht in direktem Kontakt mit der CPU-Architektur, daher ist das erste Lernziel wichtig; der 6502 ist mit seiner einfachen Struktur und einem realen Ökosystem eine gute Einsteigerplattform
• Mit nur 6 Registern und ursprünglich 56 Befehlen lassen sich Grundkonzepte wie Register, Load/Store, logische und arithmetische Operationen sowie Verzweigungen schnell erlernen
• Als echte CPU, die im Apple II, Commodore VIC 20, Commodore 64, BBC micro usw. eingesetzt wurde, eignet sie sich dank Emulatoren, Nachbaugeräten und frei verfügbaren Materialien gut für praxisorientiertes Lernen
• Easy 6502 bietet einen JavaScript-basierten Assembler und Simulator, in dem man direkt im Web Code ausprobieren kann, sodass man schnell ein Gefühl dafür bekommt
• Z80, moderne RISC-Architekturen und x86-x64 sind ebenfalls lernenswert, aber für den ersten Schritt reduziert der weniger komplexe 6502 die Lernhürde

---

Warum sich der 6502 für Einsteiger eignet

• Assemblerprogrammierung ist stärker mit der Hardware verbunden als Hochsprachen, deshalb beeinflusst die erste CPU, mit der man arbeitet, den Schwierigkeitsgrad des Lernens erheblich
• 6502-Assembler ist heute kein besonders angenehmes Umfeld für die Entwicklung praktischer Anwendungen
  • Wer sich nicht speziell für Retro-Programmierung interessiert, muss nicht lange beim 6502 bleiben
• Als Einsteigerplattform liegen die Vorteile in Einfachheit und Realitätsbezug
  • Durch die einfache Struktur lassen sich Grundkonzepte schnell erfassen
  • Es gibt viele reale Geräte, Emulatoren, Bücher und Online-Materialien, wodurch sich ein Lernpfad leicht finden lässt

• Register und Befehle bleiben überschaubar

  • Der 6502 hat nur 6 Register
    • einen Akkumulator
    • zwei Indexregister
    • ein Statusregister
    • ein Stack-Register
    • einen Programmzähler
  • Das einzige 16-Bit-Register des 6502 ist der Programmzähler
  • Die geringe Zahl an Registern ist für echte Anwendungen zwar eine Einschränkung, hilft aber dabei, Rolle und Funktionsweise von Registern zu verstehen
  • Der ursprüngliche 6502-Befehlssatz umfasst nur 56 Befehle
  • Mit diesem kleinen Befehlssatz lassen sich dennoch wichtige Befehlstypen lernen
    • Load/Store
    • logische Operationen
    • arithmetische Operationen
    • Verzweigungen
  • Diese Typen finden sich auch in modernen CPUs in irgendeiner Form wieder
  • Bei x86-x64 ist schon das Zählen von Registern und Befehlen nicht einfach, und auch moderne RISC-Befehlssätze wie ARM lassen sich kaum noch als klein und einfach bezeichnen

Reales Ökosystem und andere Optionen

• Alt, aber lebendig: das Ökosystem

  • Der 6502 wurde Mitte der 1970er Jahre von MOS Technology als günstige und vereinfachte Variante des Motorola 6800 eingeführt
    • Dasselbe Team hatte zuvor den Motorola 6800 entwickelt
  • Danach gewann er schnell an Popularität und wurde in mehreren bekannten Mikrocomputern eingesetzt
    • Apple II
    • Commodore VIC 20
    • Commodore 64
    • BBC micro
  • Emulatoren für diese Geräte sind leicht zu finden, teils gibt es auch moderne Nachbauten
  • Nachfolger des 6502 werden zum Zeitpunkt des Artikels weiterhin produziert, und neue Geräte wie der Neo6502 von Olimex führen ebenfalls 6502-Derivate aus
  • Kostenlose Lernmaterialien sind im Internet reichlich vorhanden, viele davon auf 6502.org

• Lernmaterialien, mit denen man sofort praktisch loslegen kann

  • Easy 6502 ist ein E-Book von Nick Morgan und eignet sich für Lernende, die den 6502 kurz und direkt ausprobieren möchten
  • Es enthält nicht nur Text und Bilder, sondern auch einen in JavaScript geschriebenen 6502-Assembler und Simulator
    • Auf der Webseite kann man einfachen 6502-Assemblercode direkt schreiben
  • Visual6502.org ist weniger ein Werkzeug zum Erlernen von Assembler als vielmehr eine Ressource, die die Einfachheit des 6502 visuell zeigt

• Unterschiede zu anderen Einsteigerkandidaten

  • Virtuelle CPUs, die für Lehrzwecke entwickelt wurden, können einen sauberen und „perfekten“ Befehlssatz haben, verfügen aber oft nicht über so viele Lernmaterialien und so viel Community wie der 6502
  • Auch Retro-CPUs wie Z80, 6809 und 68000 sind gute Optionen
    • Diese drei CPUs gelten für ernsthafte Programmierung als besser als der 6502
    • Für das Erlernen grundlegender Konzepte ist die Einfachheit des 6502 jedoch im Vorteil
  • Der Z80 hat deutlich mehr Register als der 6502 und besitzt zudem alternative Registersatz-Varianten, was den Einstieg weniger leicht macht
  • Moderne RISC-Architekturen wie ARM, MIPS und RISC-V sollte ein ernsthafter Assemblerprogrammierer irgendwann lernen
    • Als Einstieg sind sie jedoch nicht ideal
    • Ihre Einfachheit bezieht sich eher auf die interne Implementierung des Chips als auf den Befehlssatz selbst
  • Moderne Mikroprozessoren werden überwiegend in Hochsprachen programmiert, und die direkte Erfahrung mit Assemblerbefehlen hat in den Prioritäten des CPU-Designs keinen hohen Stellenwert
  • Um auf ARM64 eine 64-Bit-Konstante in ein Register zu laden, können unter Einbeziehung von Bit-Shift bis zu 4 Befehle nötig sein
    • Im Vergleich dazu ist das Laden einer Konstante in ein Register beim 6502 deutlich einfacher
  • x86-x64 ist auf modernen Desktops und Servern wohl der verbreitetste Befehlssatz, wobei ARM aufholt
    • Dank fehlender 32-Bit-Größenbeschränkung und eines umfangreichen Befehlssatzes mit variabler Operandenanzahl gibt es Aspekte, in denen sich damit leichter codieren lässt als mit ARM
    • Für Einsteiger bleibt x86-x64 jedoch weiterhin sehr komplex, und 40 Jahre Geschichte haben x86-x64 nicht einfacher gemacht

[GN⁺]

Meinungen auf Hacker News

• Ich finde es schwer, der Aussage zuzustimmen, dass die Einfachheit des 6502 besser sei als die des 68000.
  Der 68000 hat mehr Register und breitere Datentypen, ist aber strukturell einheitlich. Im Grunde wiederholen sich zwei Arten, A und D, als D0~D7 und A0~A7; was mit D0 geht, geht auch mit D3. Strukturelle Einfachheit muss gegen Einfachheit beim Programmieren abgewogen werden, und beim 6502 stößt man schon bei nur leicht komplexeren Programmen ständig an Grenzen.
  Der beste Weg, zu lernen, wie man die Grenzen kleiner Maschinen umgeht, ist eher, diese Grenzen zu ignorieren und ein erfahrener Software Engineer zu werden. Als Anfänger ist es besser, mit etwas zu beginnen, das mehr Adressierungsarten bietet, große Arrays leichter handhabbar macht und großzügigere Register- und Integer-Breiten hat.

  • Ich sehe es ähnlich, aber aus einer anderen Perspektive. In den letzten Jahrzehnten habe ich hauptsächlich im Demo-Bereich mit 6502, 68k, z80 und x86/64 gearbeitet, und bei diesem Artikel fragte ich mich sogar, ob er vielleicht von einer KI geschrieben wurde.
    Es wird behauptet, der 6502 sei einfach, weil er sechs Register habe, aber wenn man eine Woche mit dem 6502 arbeitet, merkt man, dass man es praktisch mit drei Registern zu tun hat. Daher kommt auch der Spitzname Semaphor-CPU.
    Der 6502 ist unterhaltsam und sauber, aber wenn man einen modernen Ansatz will, ist er nicht geeignet. Wenn man dem Ruhmespfad der 90er folgen möchte, sollte man mit MIPS anfangen – oder einfach mit Neon. Auch beim Z80 kann man angesichts der Register und der Komplexität durchaus sagen, dass er dem, was man heute antrifft, ähnlicher ist.
    Moderne Assemblersprache ist an sich nicht grundsätzlich kompliziert. Wenn man mit FASM beginnt, ist es nicht schwer, aber ein Low-Level-Ansatz wird immer schnell komplex. Dann fängt man an, Makros zu bauen, und am Ende setzt man seine eigene, armselige C-ähnliche Schicht darauf.
  • Zu lernen, wie man die Grenzen kleiner Maschinen umgeht, ist ein guter Schritt auf dem Weg zu einem erfahrenen Software-/Hardware-Engineer.
    Der Vorteil kleiner Systeme liegt darin, dass man das Ganze vollständig verstehen kann – vom Silizium über das Betriebssystem bis zur Software.
    Der 6809 ist einfacher als der 68K, leistungsfähiger als der 6502 und recht orthogonal, hat aber keine vergleichbare Software-Basis. Meiner Ansicht nach hat Motorola bei den Befehlssätzen und der Architektur aus Programmierersicht des 6809 und 68K eine ziemlich gute Richtung eingeschlagen. PDP-11/VAX und NS32K habe ich ebenfalls als ähnlich orthogonal in Erinnerung.
  • Der 6502 ist als Spielzeug-Assembler besser als der Z80, aber das heißt nicht viel. Es ist auch schwer zu sagen, dass er eindeutig besser wäre als der AVR-8-Bit-Befehlssatz.
    Wenn man an eine modernere Plattform denkt, spricht vieles dafür, RISC-V statt MC68k zu lehren. RISC-V ist, wenn man nur den grundlegenden Integer-Befehlssatz betrachtet, sehr einfach und elegant und ähnelt zugleich modernen Architekturen wie ARM, Aarch-64 und MIPS. Es gibt sowohl 32-Bit als auch 64-Bit, und die offizielle Dokumentation ist gut zugänglich.
    MC68k hat zu viele Eigenheiten, die heute kaum noch relevant sind. Ein Vorteil ist vielleicht, dass er auf mehreren Hardware-Plattformen verwendet wurde und es noch eine aktive Retro-Community gibt; das ist aber eher ein interessanter Aspekt als tatsächlich relevant.
  • Auch der 68K ist wegen des 24-Bit-Busses, der Alignment-Einschränkungen und der etwas unklaren Unterstützung für Array-Indizierung ein wenig unbequem. Dass es keinen Skalierungsfaktor gibt, stört ebenfalls.
    Der 68020 kommt ziemlich nah an das Maximum dessen heran, wie sehr eine Befehlssatzarchitektur C ähneln kann, und er fühlt sich in der Nutzung sehr gut an.
  • Ich habe Programmieren mit dem 6510 gelernt, stimme aber zu, dass der Befehlssatz des 68000 deutlich besser sowie leichter zu lesen und zu lernen war. Ich würde ebenfalls den 68000 wählen.
    Allerdings war es sehr lohnend, auf frühen Commodore-Computern mit dem 65XX zu arbeiten. Weil es keinen Speicherschutz gab, konnte man den Videospeicher direkt verändern, Sprites, Fonts, Rahmen und Interrupts manipulieren und auch selbstmodifizierenden Code schreiben. 68000-Assembler auf dem Amiga war eine sicherere und stärker kontrollierte Umgebung.

• Als ersten Befehlssatz zum Lernen von Assembler halte ich 6502 für keine gute Wahl. Man verbringt viel Zeit damit, mit den Eigenheiten einer cleveren, aber tief fehlerbehafteten Architektur umzugehen.
  Diese Ausweich-Idiome lassen sich nicht gut auf bessere Architekturen übertragen, die nicht an die Werkzeug- und Budgetbeschränkungen von MOS damals gebunden waren.
  Wenn man einen kleinen, aber leistungsfähigen Befehlssatz mit ein paar Eigenheiten lernen möchte, ist ARM v6M besser. Er wird auch heute noch in relevantem Umfang produziert, und moderne Open-Source-Toolchains bieten gute Unterstützung für Debugger, Compiler, Assembler und Linker.
  Wenn einem die Offenheit der Architektur wichtig ist und man eine noch weniger ausgereifte Plattform in Kauf nehmen kann, sollte man einen RISC-V-MCU wählen. Wenn man sich nicht entscheiden kann, nimmt man den RP2350.
  Der ARMv6M-Befehlssatz ist klein, und auch das Laden von Konstanten erfordert keine langen, langweiligen Befehlssequenzen, wenn man wie dokumentiert PC-relative Loads verwendet. Man braucht weder selbstmodifizierenden Code noch die Zero Page, um Speicher zu indizieren, und die Registerbreite entspricht dem Adressraum. Weil er 32 Bit hat, ist er tatsächlich leichter zu lernen und zu lehren als die meisten 8/16-Bit-Befehlssätze. Falls das langweilig klingt: keine Sorge. Auch ARMv6 hat genug Eigenheiten, die sich für Code Golf nutzen lassen.

  • Ich mag die 6502-Architektur, aber wenn Einsteiger, die sich für alte Computer interessieren, noch keine Assembler-Erfahrung haben, verweise ich sie normalerweise in eine andere Richtung.
    Ich habe mit PIC16-Assembler angefangen und mich mit mehreren Architekturen ein wenig beschäftigt, aber in Sachen Sauberkeit gefiel mir MIPS32 am besten.
    Als kleine Ergänzung: Man kann weiterhin neu gefertigte 6502, MCUs mit 6502-Kern und Peripherie-Chips von Western Design Center kaufen. Sie werden auch bei Anbietern wie Mouser verkauft.
    https://www.mouser.com/c/?m=Western%20Design%20Center%20%28W...
  • Früher habe ich viel 6502-Assembler geschrieben, und dabei ging ziemlich viel Zeit dafür drauf, mit einer 8-Bit-Architektur umzugehen.
    Schon das Multiplizieren zweier 16-Bit-Zahlen braucht einen ordentlichen Codeblock. Es erscheint nicht besonders sinnvoll, neue Programmierer damit ringen zu lassen.
    Wie gesagt: Die frühen ARM-Befehlssätze sind eine gute Wahl.
  • Auch ARM hat für Einsteiger wegen der Art, wie Immediate-Werte in Befehlen codiert werden, einige schmerzhafte Stellen. Es kann wenig intuitiv sein, warum manche Immediate-Werte oder Offsets funktionieren und andere nicht.
    Natürlich ist das ein Problem, das es in vielen Assemblersprachen gibt, aber am Anfang wäre ein Befehlssatz ohne solche Probleme wünschenswert.
  • Ich kann mir kaum vorstellen, worauf sich „tief fehlerbehaftet“ beziehen soll.
  • Ich muss immer wieder an Ben Eaters 65C02-Breadboard-Serie[1] denken. Gibt es eine Möglichkeit, das, was in diesen Videos gemacht wird, auch mit einer ARM-CPU nachzubauen?
    [1] https://youtube.com/playlist?list=PLowKtXNTBypFbtuVMUVXNR0z1...

• Aus der Perspektive von jemandem, der Studierenden über viele Jahre Assembler beigebracht hat: Ich stimme zu, dass 6502 für Anfänger gut ist. Allerdings liegt das nicht nur an den Vorzügen der 6502-Sprache selbst.
  Ich habe 68K, MIPS, ARM, x86 und anderes unterrichtet, und der wichtigste Grund, warum die Studierenden beim 6502 so positiv reagierten, war der Kontext rund um die CPU. Wir programmierten mit dem 6502 eine reale, leicht verständliche Maschine: das Nintendo Entertainment System.
  Einfaches Memory-Mapped I/O, kein Betriebssystem, keine Pipeline-Befehle, keine Delay Slots, kein Netzwerk, kein unnötiges Rauschen. Es ist im Grunde eine einfache Kiste mit Takt, CPU, ein paar Speicheradressen, Zusatzchips und Ein-/Ausgabe, die auf Speicheradressen gemappt ist. Der 6502 hat nicht den einfachsten Befehlssatz, aber die Einfachheit dieses Systems hilft enorm.
  Auch die Einschränkungen des 6502 waren wichtig, damit die Studierenden verstanden, warum die Befehle so aussehen. Die CPU wurde innerhalb der damaligen Grenzen entworfen und verdrahtet, und das spiegelt sich in der Programmierweise wider.
  Die Wahl von 6502 und NES für den Anfängerunterricht war erfolgreich. Nicht weil es der 6502 war, sondern weil der 6502 dazu zwang, das System, das Bits bewegt, selbst einfach zu halten.
  Nachdem die Studierenden den 6502 ausprobiert und gesehen hatten, wie sich NES-Tiles auf dem Bildschirm bewegen, ließ sich leicht und natürlich darauf aufbauen: wie der 68000 Dinge anders handhabt, wie MIPS entstand, wie Pipelining und Delay Slots genutzt werden und wie man RISC und CISC vergleicht. Hat man die Grundlagen, wird die Weiterentwicklung sehr einfach.

• Wenn man nicht gerade einen heute verwendeten Befehlssatz lernen will, überrascht es mich etwas, dass PDP-11-Assembler kaum als guter Einstieg genannt wird.
  Vielleicht liegt das daran, dass PDP-11 das Erste war, was ich richtig gelernt habe, aber die frühen Mikroprozessoren fühlten sich alle wie ein Rückschritt an. Ich habe zwar einige Jahre Z80-Assembler geschrieben, würde ihn heute aber nicht empfehlen. Es ist kein orthogonaler Befehlssatz, und der 6502 hat viel zu wenige Register, um wirklich ein gutes Gefühl für das Schreiben von Assembler zu vermitteln.

  • Heutzutage ist es ziemlich schwierig, eine PDP-11 zu bekommen, und auch Betriebssysteme, Compiler usw. aufzutreiben ist nicht einfach.
    Wenn man PDP-11 mag, bekommt man beim MSP430 ähnliche Vorteile in etwas eingeschränkter Form und beim 68000 in etwas verstärkter Form.
    Aber eigentlich ist es am besten, solche Relikte zu vergessen und RISC-V zu lernen. Oder man nimmt eine der vielen Arm-Varianten. Persönlich habe ich eine emotionale Schwäche für den ARM7TDMI, mit dem ich Mitte der 2000er viel gearbeitet habe. Der Thumb-Modus ist vielleicht etwas leichter zu lernen als der ursprüngliche Arm-Modus, aber beide sind nicht so befriedigend wie RISC-V.
  • Stimme zu. PDP-11 ist um Welten angenehmer, da gibt es keinen Vergleich.
    Man könnte zwar argumentieren, dass die Adressierungsarten konzeptionell komplexer sind als bei RISC, aber in der Praxis sind die 6502-Adressierungsarten wahrscheinlich schwerer zu verstehen als die der PDP-11.
  • Wenn man PDP-11-Assembler lernt, versteht man auch, warum manche C-Idiome so sind, wie sie sind. Zum Beispiel ist ein Pointer auf einen Pointer eine native Adressierungsart, die direkt der Architektur entspricht.
  • Der -11-Befehlssatz ist ein Meisterwerk der Ingenieurskunst. DEC hatte alles, was nötig gewesen wäre, um das Mikrocomputer-Geschäft vollständig zu dominieren.
    Aber DEC ignorierte diese Chance, und IBM nahm diesen Platz mit dem unbeholfenen 8086-Befehlssatz ein.
    Heute gibt es keinen Zweck mehr, -11 zu lernen.

• Ich verstehe nicht ganz, wie man zu diesem Schluss kommt. Wenn Studierende zum ersten Mal mit Computerprogrammierung in Berührung kommen, kann es sinnvoll sein, mit einer Spielzeug-/Kleinsprache ohne praktischen Nutzen zu beginnen. Aber Assembler sollte nicht die erste Sprache sein, die man lernt.
  Assembler ist ein sehr praktisches Werkzeug und wird üblicherweise viel beim Debugging und Reverse Engineering eingesetzt. Warum also Zeit in den Assembler einer Plattform stecken, die vor langer Zeit verschwunden ist?
  Der beste Weg, Assembler zu lernen, ist Experimentieren. Man schreibt Code in seiner Lieblingssprache und sieht sich die ausgegebene Zwischen-Assemblerdarstellung an, oder man schaut mit objdump oder gdb ins Innere. Man kann auch Dinge ändern und sehen, was passiert.
  Mit Emulatoren alter Computer geht das ebenfalls, ist aber schwieriger. Schon um ein einziges Stück Text auf dem Bildschirm auszugeben, muss man die Architektur, die Hardware und die ROM-Funktionen dieses Computers lernen, und dieses Wissen lässt sich kaum auf x86-64 unter Linux oder Windows übertragen.

  • Ich hatte Schwierigkeiten, C zu verstehen, bis ich auf dem 68HC11 Hexadezimalzahlen und Assemblerprogrammierung lernte; erst dann ging mir ein Licht auf.
    Für komplette Anfänger waren Konzepte wie Pointer viel zu abstrakt und schwer zugänglich, aber als ich in Assembler indirekte Adressierung lernte, wurde plötzlich klar, warum es in C Pointer gibt und wie sie funktionieren.
    Davor hatte ich hauptsächlich Python benutzt, das deutlich stärker abstrahiert ist. Oft wird vergessen, dass Funktionen wie Pointer wegen Hardware- und Performance-Einschränkungen existieren. Wenn man nicht weiß, was in der CPU tatsächlich passiert und warum, bleibt das intuitive Verständnis begrenzt.
  • Wenn man einige Monate mit Hardware arbeitet und Assembler programmiert, versteht man die grundlegende Funktionsweise eines Computers auf eine völlig andere Weise als mit Hochsprachen.
    Seit der Highschool habe ich keine einzige Zeile Assembler mehr geschrieben, aber das grundlegende Verständnis dafür, wie Operationen ausgeführt werden und wie Register funktionieren, hat es mir viel leichter gemacht, die Gründe, Bedingungen und Ausnahmen bei Programmierung und Optimierung zu verstehen. Sauberen und effizienten Code weiß ich dadurch ebenfalls mehr zu schätzen.
  • Wir haben das sogar als Zehnjährige ziemlich gut hinbekommen, als zweite Sprache nach einem Comicbuch zur BASIC-Programmierung.
    Wer ein wenig Vergangenheit kosten möchte, findet sie hier:
    https://www.atariarchives.org/
  • Es gibt grob zwei Wege, Programmieren zu lernen: den Top-down-Ansatz, der von abstrakten Konzepten zur konkreten Implementierung hinabsteigt, zum Beispiel SICP, und den Bottom-up-Ansatz, der mit konkretem Low-Level-Code beginnt und Abstraktionen natürlich entstehen lässt.
    Da ich Elektrotechnik studiert habe, begann ich ganz selbstverständlich mit Assembler (Motorola HC11). Gegen Ende des Kurses hatten alle unabhängig voneinander Makros für Dinge wie for-Schleifen gebaut, und von dort war der Übergang zu C ganz natürlich. Am Ende des C-Kurses entstand ebenso natürlich objektorientierter Stil in C, was in den nächsten C++-Kurs führte.
    Der Nachteil dieses Ansatzes ist, dass es keinen schrittweisen Pfad zu funktionalen Paradigmen oder allgemein zu nicht-imperativen Paradigmen gibt. Außerdem gewöhnt man sich an, ständig darüber nachzudenken, wie eine Sprache intern funktioniert, was manchmal kontraproduktiv sein kann. Selbst als ich Haskell lernen wollte, wollte mein Kopf zuerst verstehen, wie der Interpreter arbeitet.
    Assembler zu lernen bedeutet nicht nur, eine Sprache zu lernen, sondern zu verstehen, wie die Maschine funktioniert: Busse, speicherabgebildete Peripherie und so weiter. Auf alten Plattformen ist dieser Teil viel einfacher. Deshalb ist für Anfänger alles andere beim HC11 freundlicher, auch wenn ARM-Befehle vielleicht leichter zu lernen sind als die CISC-Befehle des HC11.
  • Beim dmd-Compiler zeigt -vasm beim Kompilieren den erzeugten Assembler an. Das wurde auch als wenig sinnvoll bewertet, nach dem Motto, man könne doch objdump oder -S verwenden, aber wenn man es selbst ausprobiert, versteht man, warum es praktisch ist: Es gibt direkt nur den Assembler aus, ohne den umfangreichen Boilerplate, der zum Erzeugen einer Objektdatei nötig ist.
    Angenommen, man arbeitet zum Beispiel am AArch64-Codegenerator, genauer an der Codeerzeugung für Gleitkommaoperationen, und hat diese Funktion:
    float test(float a, float b) { return a * b; }
    Wenn man mit dmd -c test.c -arm -vasm kompiliert, werden Adresse, hexadezimale Instruktion, Befehlsmnemonik und die URL zur Befehlsspezifikation ausgegeben.
    Ich weiß, dass der Code nicht völlig korrekt ist. Ich sagte ja, dass er noch in Arbeit ist :-)

• Für mich war der 6502-Befehlssatz eine gute erste Assemblersprache.
  1977 lebte ich in einer kleinen Hütte in Oregon und kaufte mir zum Zeitvertreib einen Apple II. Innerhalb eines Jahres arbeitete ich an einem Programm, aus dem später Apple Writer wurde, und es war komplett in Assembler geschrieben.
  https://en.wikipedia.org/wiki/Apple_Writer
  Hier heißt es, 6502-Assembler sei ziemlich roh und schwer zu schreiben, und rückblickend stimme ich dem zu. 1977 hatte ich allerdings keinen Vergleichsmaßstab.
  Da es auf dem Apple II keine schnelle Hochsprache gab, wurde mein kleines Programm mangels Alternativen zu einem Apple-Produkt.
  Wenn man darüber nachdenkt: Apple Writer passte in 8 KB RAM, leistete aber echte Arbeit. Es gab sogar eine Makrosprache, die Leute zur Bearbeitung von Adresslisten verwendeten.
  Kürzlich habe ich mein Hauptsystem auf 96 GB RAM aufgerüstet, um DeepSeek leichter lokal auszuführen, und ich habe auch eine RTX 4090. Da wurde mir plötzlich klar, dass in diesen RAM fast 12 Millionen Exemplare von Apple Writer passen würden.
  Ziemlich surreal, aber seit 1977 gab es schon mehrmals Anlass, so etwas zu sagen.

• Als Assemblersprache für den Einstieg bevorzuge ich RISC-V. Das Design ist gut und intuitiver, es gibt Unterstützung durch moderne Sprachen und Tools wie GCC, LLVM und Rust, und es läuft in QEMU sowie auf tatsächlich käuflicher Hardware.

  • ARMv7 erfüllt diese Kriterien ebenfalls und lässt sich gut schreiben. Es kann inline innerhalb von BBC Basic auf dem Acorn Archimedes verwendet werden.
  • Als ich zuletzt nachgesehen habe, gab es für RISC-V noch keinen Makroassembler, der diesen Namen verdient.
  • Wenn es um „tatsächlich käufliche Hardware“ geht: Als ich zuletzt nachgesehen habe, wurde auch der 65C02 noch hergestellt und verkauft.
    Er kann sogar mit sagenhaften 14 MHz laufen.

• Das Thema der Einfachheit des 6502-Befehlssatzes ist für mich persönlich ein wunder Punkt. Wer diese Einfachheit für gut hält, scheint nie über Hello World hinausgekommen zu sein.
  Etwas mittelmäßig Komplexes auf dem 6502 zu programmieren, ist schwierig. 8 Bit sind viel zu einschränkend, etwa schon bei der Bildschirmadressierung des Commodore 64. Multiplikation und Division muss man selbst implementieren, und selbst 16-Bit-Addition/Subtraktion ist zwar einfach, aber effizient umgesetzt keineswegs trivial.
  Wenn es darum geht, grundlegendes Assembler zu lernen, ist die Plattform 8086+DOS im Vergleich deutlich leichter zu handhaben.

  • Im Kontext des ersten Kontakts mit Assembler ist es eher ein Vorteil, Multiplikation/Division selbst implementieren zu müssen.
    Verschiedene Multiplikations- und Divisionsalgorithmen nach Assembler zu übertragen, ist eine sehr gute Lernmethode.
  • Einschränkungen sind Teil des Spaßes. 8086-Assembler macht entsprechend weniger Spaß.
    Wenn man ohnehin etwas lernt, das heute nicht relevant ist, weil es nicht x86-64, RISC-V oder ARM ist, ist mir nicht klar, worin der Vorteil von 8086 liegen soll.
  • Der Assembler, den ich am meisten geschrieben habe, war vermutlich 8086, genauer gesagt 80286 im Real Mode.
    Ich mochte jeden Moment davon, und die Segmentregister haben mich auch kaum gestört.

• Ich besuche eine technikorientierte Schule mit Schwerpunkt Informatik; dort hat ein Informatikprofessor, der Retro mag und gern seinen eigenen Arcade-Automaten zeigt, statt des vorgesehenen Lehrplans zu 8808-Assembler den Fokus auf 6502 gelegt.
  Ehrlich gesagt war das eine der besten Lernerfahrungen meines Lebens, und ich würde mir nicht wünschen, dass es anders gewesen wäre. Besonders greifbar und wirklich interessant wurde es dadurch, dass er uns sogar Ben Eaters Breadboard-Computer bauen ließ.

• Mein erster Kontakt mit Assemblersprache war PDP-10, und alles, was ich hatte, war das DEC-10-Prozessorhandbuch.
  Ich war völlig verwirrt. Es gab Hunderte von Befehlen, und die Erklärungen waren undurchsichtig. Ich wusste überhaupt nicht, was ein Register ist, was ein Akkumulator ist, was eine Adresse ist oder was ein Stack ist. David Rolfe schrieb mir ein paar Subroutinen, die ich für meine Fortran-Version von Empire brauchte, was ein wenig half, aber ich war immer noch verloren.
  Eines Tages fragte ich meinen Freund Shal Farley, was ein Stack sei, und er sagte: „Stell dir einen Stapel Teller vor. Du legst einen Teller oben drauf (push) und nimmst einen wieder herunter (pop).“ In diesem Moment ging mir ein Licht auf, und ich verstand es sofort.
  Danach begann ich, mit einem 6800-Mikroprozessor auf einer kleinen Platine zu arbeiten. Er hatte etwa 40 Befehle, die alle auf eine Karte passten. 40 Befehle waren leicht zu lernen, und plötzlich ergab alles Sinn.
  Als ich dann wieder zum -10-Handbuch zurückkehrte, begann alles darin Sinn zu ergeben.