Assembler 65xx - Vergleich mit heute

Es gibt 32 Antworten in diesem Thema, welches 7.764 mal aufgerufen wurde. Der letzte Beitrag (4. August 2014 um 20:58) ist von bome.

  • Ich habe heute mal kurz ein Assembler-Tutorial zu den aktuellen Intel-Prozessoren quergelesen. Liege ich mit meiner Annahme richtig, dass im Grunde gar kein so grosser Unterschied zwischen damals und heute besteht...ausser natürlich mehr Register, Anzahl Bits etc.....

    Mir erscheint zumindest der Sprung bei den Hochsprachen und Libraries von Basic 2.0 z.B auf die aktuelle C#/.NET Version wesentlich grösser - auch wenn das vllt so ein Äpfel mit Bananen-Vergleich ist ;)

    Mich würde mal die Meinung von jmd. interessieren, der in beiden Welten schon Erfahrung gesammelt hat.

  • Ich habe eine Idee, ich weiß nicht wie weit das stimmt:

    Die Verbesserung durch guten hardwarenahen Code macht einen festen Faktor ungefähr aus. Würde mich auch nicht wundern, wenn Menschen in ASM nur ihre paar Befehle nutzen, die beim C64er z.B. schon alle Befehle sind.

    Wenn Du aber einen schlauen Rechenweg hinbekommst, dann kannst Du bei großen Datenmengen, die Du bearbeiten möchtest, schon Zeit sparen. Der Supercomputer ist auch nur um einen konstanten Faktor ungefähr schneller und ein langsamerer Rechner mit der richtigen Arbeitsweise schlägt den Supercomputer ab einer bestimmten Datenmenge locker.

  • Immer noch arbeiten Prozessoren auf der untersten Ebene, und schubsen Datenwörter hin und her und verarbeiten sie. Doch sehe ich Erweiterungen in zwei Bereichen: einmal beim Befehlssatz und einmal in der internen Realisierung. Beim Befehlssatz findet man zum Beispiel vermehrt Operationen aus dem Bereich des Threading (Mutex/Lock-Operationen) und Virtualisierung. Intern ist die Optimierung weit fortgeschritten und es ist faszinierend welche Vorhersagen und Umsortierungen der Befehle der Prozessor vornimmt, um möglichst viele Mikrobefehle parallel arbeiten zu können.

  • Mir fallen da spontan drei Unterschiede ein zwischen 6502 und x86 oder auch 68000, die einem das Leben als Programmierer auf letzteren um einiges erleichtern:

    1.) Der 6502 kennt keinen Befehl zum indirekten Aufruf einer Funktion bzw. Methode.
    Normalerweise programmiere ich Objekte in x86 so, daß der Objektzeiger in ESI vorliegt, um dann mittels

    Code
    CALL	[esi + methoden_offset]


    eine (dynamische) Methode aufzurufen. Beim 68000 kennt man ein ähnliches Verfahren, z. B. vom Amiga:

    Code
    JSR	methoden_offset(Ax)


    worauf dann allerdings noch ein JMP abs.L folgt zum eigentlichen Methodenanfang.
    Um dies beim 6502 zu simulieren, benötigt man eine Reihe von Befehlen:

    Code
    LDY	#methoden_offset
    	LDA	(op), y
    	STA	patch + 1
    	INY
    	LDA	(op), y
    	STA	patch + 2
    patch:	JSR	$ffff


    Kommt dies häufig im Programm vor, so kann man die Kernroutine auf die Zeropage auslagern:

    Code
    call:	LDA	(op), y
    	STA	patch + 1	; spart einen Takt durch Zeropageadressierung
    	INY
    	LDA	(op), y
    	STA	patch + 2	; spart einen Takt durch Zeropageadressierung
    patch:	JMP	$ffff		; JMP abs umgeht außerdem den Bug in JMP (abs)


    Der Aufruf erfolgt dann mit

    Code
    LDY	#methoden_offset
    	JSR	call


    Jedoch verbraucht dieser Aufruf im Verhältnis zu den großen Brüdern sehr viel mehr Taktzyklen. Theoretisch ist eine objektorientierte Programmierung auf dem 6502 also zwar möglich, aber im Regelfall zu umständlich und zu langsam.

    2.) Der Stack beim 6502 ist relativ klein bemessen. 256 Bytes ist wahrlich nicht viel. Spätestens bei einer Rekursionstiefe von mehr als 128 stürzt das Programm ab. Nun kommen die meisten Programme sicherlich auch ohne große Rekursionen aus. Was aber wirklich stört, ist, daß der 6502-Stack nicht geeignet ist, die von Hochsprachen wie C oder Pascal (und entsprechend alle Nachfolger) verlangten lokalen und temporären Daten dort abzulegen. Bei x86 oder 68000 ist dies kein Problem. Der Zugriff gestaltet sich zudem recht einfach:

    Code
    MOV	eax, [esp + lokale_variable]

    oder

    Code
    MOVE.L	lokale_variable(a7), d0


    Wollte man auf einem 6502 dies nachahmen, müßte man zuerst die Werte mittels PHA auf den Stack bringen, dann mit TSX den Stackzeiger nach X laden und die Adressierungsart abs, x verwenden, um auf die einzelnen Stackelemente zugreifen zu können. Da der Stack aber zu beschränkt ist für eine größere Anzahl an Daten, ist diese Methode nicht zu empfehlen. 'Pascal auf dem C64', UCSD-Pascal und andere Hochsprachenimplementierungen verwalten daher einen eigenen getrennten 16-Bit Stack, auf dem sie ihre Daten speichern können.

    3.) Zuletzt kann auch die Anzahl der Register von Bedeutung sein, wenn es z. B. um die Parameterübergabe geht. Drei Register sind wirklich nicht viel hierfür. Beim x86 werden die Parameter (standardmäßig) auf dem Stack übergeben. Dabei ist genau definiert, welche Register von einer Funktion überschrieben werden dürfen und welche nicht. (Schreibt man direkt in Assembler, hat man natürlich die Freiheit, die Register zu verwenden, wie man will.) Das Betriebssystem des Amigas übergibt im Regelfall die (ersten vier) Parameter in den Registern d0/d1 und a0/a1, welche gleichzeitig als Scratchregister fungieren. Die meisten in 6502-Assembler geschriebenen Programme arbeiten jedoch statt dessen mit globalen Werten, auch bei den Parametern. Es ist nicht untypisch folgendes in einem Programm zu sehen:


    Um den Overhead bei der Parameterübergabe zu sparen, sind die Programmierer dann bei (zumeist) konstanten Parametern dazu übergegangen, diese direkt an den JSR-Aufruf hinten dranzukleben, so daß der PC als Zeiger auf die Daten dient. Klassisches Beispiel:

    Code
    JSR	schreibe_string
    	ASC	'Hier ist der String'
    	HEX	00	; Endmarker des Strings
    	...		; Hier geht das Programm nach Aufruf von schreibe_string weiter


    Diese Aufruftechnik ist meines Wissens auf anderen Prozessoren nicht so geläufig. (Wer mehr weiß, bitte melden.)

    Typisch für viele Programme auf dem 6502 ist auch, auf der Zeropage Variablen (wie aus dem obigen Beispiel) zu deklarieren, die einer ganz bestimmten Semantik unterliegen, z. B. 'xcoo' oder 'taste', auch wenn diese nur temporär gebraucht werden. Beim x86 oder 68000 werden solche temporären Variablen in den Registern gelagert, so daß eine explizite Definition als Variable im Speicher weniger häufig ist. Anders gesagt: Die Speichernutzung ist (besonders bei alten Programmen) auf dem C64 oder AppleII weniger optimal.

    Zusammengefaßt:
    Der 6502 programmiert sich schon anders als der 68000 oder x86 oder ARM. Bei letzteren ist die Umsetzung von Hochsprache auf Prozessor viel näher am Originaltext. Beim 6502 muß man manchmal um die Ecke denken und auch längere Wege in Kauf nehmen, um das Ziel zu erreichen. Oder man verzichtet von vornherein auf bestimmte Konstrukte und begnügt sich mit einer einfachen prozeduralen Programmierung. Meiner Meinung nach ist 6502-Assembler eine Sprache für sich, und man muß in 6502-Assembler denken, um das Ziel optimal zu erreichen. Bei den anderen Prozessoren kann man sich viel mehr an den Hochsprachen orientieren.

  • Mir erscheint zumindest der Sprung bei den Hochsprachen und Libraries von Basic 2.0 z.B auf die aktuelle C#/.NET Version wesentlich grösser - auch wenn das vllt so ein Äpfel mit Bananen-Vergleich ist ;)

    Logisch. Reale Prozessoren arbeiten immer noch nach dem einfachen Schema "Instruktion - Datum". Das war's. Alles andere wäre vermutlich zu aufwändig. Für die immer "wilderen" Abstraktionen sorgen Compiler und Laufzeitumgebungen.

    Was dich vielleicht interessieren könnte wären virtuelle Maschinen wie die JVM oder die CLR, da sieht das dann ein wenig anders aus und auch der "Assembler-Code" ist komplexer. (edit: letztendlich übersetzt die virtuelle Maschine das dann aber wieder in etwas schön einfaches für die reale Maschine)

  • Etwas, was der 6502 fast überhaupt nicht abdeckt, sind mathematische Funktionen. Insbesondere Floating-Point. Moderne CPUs unterstützen dies auf Assembler-Ebene bis hin zu trigonometrischen Funktionen, Logarithmus, Exponentialfunktion usw. Im Grunde kann man dort dann wie mit einem Taschenrechner arbeiten, was auf dem 6502 ja nicht einmal bei Integer-Operationen geht.

    Auch Vector- und Matrix-Operationen werden mitlerweile in Assembler direkt unterstützt.

    Bitte melde dich an, um diesen Link zu sehen.

  • Schon länger nicht mehr, aber was willst Du wissen? Vektor- und Float-Operationen werden beim ARM über Coprozessoren unterstützt. Das sind natürlich keine externen Chips - diese Einheiten sind durchaus im Kern integriert, nur werden sie halt mit den Coprozessor-Assemblerbefehlen angesprochen.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Ich habe heute mal kurz ein Assembler-Tutorial zu den aktuellen Intel-Prozessoren quergelesen. Liege ich mit meiner Annahme richtig, dass im Grunde gar kein so grosser Unterschied zwischen damals und heute besteht.

    Ich würde sagen, das kommt ganz gut hin. Zumal die x86-Architektur in ihren Grundzügen gerade mal zwei Jahre jünger ist als der 6502 und massiv auf dem 8080 aufbaut. Wenn man noch die Mini-Computer von DEC und Co. dazunimmt, kann man den Spieß sogar umdrehen und die meisten 8-bittigen Mikroprozessoren als zusrechtgestutzte Varianten verstehen. Wirklich umdenken muß man eigentlich erst beim ARM und seinem 8-bittigen Urahn, dem 8x300 oder auch der 1-Bit-Maschine von Motorola (Nummer grad entfallen- 14500 oder sowas?)

    der Sprung bei den Hochsprachen und Libraries

    ...was aber hauptsächlich an den massiv erweiterten Betriebssystem-Funktionen liegt. Ketzerisch gesagt: Heutiges BASIC ist kaum mehr als BASIC 2 von Commodore mit Zugang zu tonnenweise Systemfunktionen. Von den 'echten' Erweiterungen der Sprache, wie in den 80ern durch neue Befehle für Grafik mit teils eigener Syntax, ist man längst abgekommen.

    Der 6502 kennt keinen Befehl zum indirekten Aufruf einer Funktion bzw. Methode.

    Doch, das geht sehr wohl- entweder durch Push-Call-Sequenzen oder JMP(xxxx). Ist auch nicht schlimmer als vieles andere, das beim 6502 in mehrere Operationen zerfällt- was ihm ja den Ruf einer gewissen RISC-Ähnlichkeit eingebracht hat.

    Der Stack beim 6502 ist relativ klein bemessen.

    Du hast bis zu 128 Stacks mit vollen 65K Adreßraum... Daten-Stacks gehen beim 6502 über Zeropage-Pointer.

    Zuletzt kann auch die Anzahl der Register von Bedeutung sein,

    156 8-Bit-Regtister sind wenig? Aber hallo...!

    OK, fairerweise muß man sagen, daß gerade der 6502 massiv auf kleien Chipfläche (und danit niedrigen Preis) getrimmt wurde und ursprünglich gar kein General-Purpose-Prozessor sein sollte, sondern eher ein Steuerchip für Geräte. Dafür waren drei Register gut und 128 Stack-Ebenen mehr als reichlich. Wenn man aber die Abstraktionsebene eins hochschiebt, hat man halt 128 Pointer-Register, mit denen man deutlich mehr anfangen kann als mit den Indes-Adressierungsarten des Z80. Genauso die 'vielen' Register des Z80... ich bin irgendwie auch nur damit beschäftigt, die in den Akku zu schaufeln, wen ich irgendwas sinnvolles damit tun will. Beim i86 wird das tendenziell etwas besser, aber leider auch langsamer. Und der 68000 nervt mit seiner strikten Trennung zwischen Adress- und Datenregistern.

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

  • Danke für die Beiträge!

    Ich habe inzwischen eine relativ neue Forth Implementierung für den C64 entdeckt Bitte melde dich an, um diesen Link zu sehen., bei der es möglich ist, direkt Assembler zu verwenden.

    Denke, werde damit etw. rumspielen...

  • Auf dem C64 nimmt man am besten gleich 100% Assembler. :)

  • Und der 68000 nervt mit seiner strikten Trennung zwischen Adress- und Datenregistern.

    Fand ich bei meiner Programmierung des 68000 in Assembler nicht so das Problem. Das man endlich mal genug Register hatte hat mir gut gefallen.

  • Ketzerisch gesagt: Heutiges BASIC ist kaum mehr als BASIC 2 von Commodore mit Zugang zu tonnenweise Systemfunktionen. Von den 'echten' Erweiterungen der Sprache, wie in den 80ern durch neue Befehle für Grafik mit teils eigener Syntax, ist man längst abgekommen.


    Auch wenn ich BASIC auf den Tod nicht ausstehen kann: Das stimmt dann doch nicht. Wenn man VB.NET als Referenz für "heutiges Basic" nimmt dann wären da schonmal Objektorientierung und moderne Kontrollstrukturen...

  • mc71
    Danke für die Antwort. Bitte gestatte mir jedoch eine Antwort auf Deine Antwort.

    Doch, das geht sehr wohl- entweder durch Push-Call-Sequenzen oder JMP(xxxx). Ist auch nicht schlimmer als vieles andere, das beim 6502 in mehrere Operationen zerfällt- was ihm ja den Ruf einer gewissen RISC-Ähnlichkeit eingebracht hat.

    Die Betonung lag auf "keinen Befehl zum indirekten Aufruf". Natürlich kann man mit dem 6502 alles mögliche programmieren. Schließlich ist der 6502 Turing-vollständig. Magnetic Scrolls emulierten bekanntlich für ihre Adventures eine Untermenge des Befehlssatzes vom 68000. Und ausreichend viele Disketten vorausgesetzt könnte der 6502 auch Linux oder Windows 64-Bit emulieren. Aber das ist nicht der Punkt. Der 6502 hat nun mal den Nachteil, daß der Mehraufwand von JSR abs zum indirekten Aufruf viel höher ausfällt als beim 68000 oder x86. Außerdem muß man bei Push-Call aufpassen, daß man die Adresse anpaßt (-1 wegen RTS), und JMP (xxxx) ist, wie Du sicherlich weist, wegen eines Bugs beim Original 6502 mit Vorsicht zu genießen.

    Du hast bis zu 128 Stacks mit vollen 65K Adreßraum... Daten-Stacks gehen beim 6502 über Zeropage-Pointer.


    Es gibt aber für die Zeropage-Pointer keine Befehlssunterstützung z. B. zum vollständigen 16-Bit Inkrementieren und Dekrementieren oder direkten Schreiben von Werten. Alles muß stets über den Akkumulator laufen. Auch benötigt man auf dem Original 6502 immer das X- oder Y-Register für die Adressierung, wodurch dieses Register für anderweitige Aufgaben verloren geht. Der 65c02 hat nicht umsonst die Adressierungsart (zp) hinzubekommen. Beim 6502 braucht man (für einen 16 Bit-Stack) z. B. folgende Befehlsfolge:

    Code
    LDY	#0
    	LDA	(sp), y
    	INC	sp
    	BNE	skip
    	INC	sp + 1
    skip:


    Verglichen mit

    Code
    MOVE.L	(sp)+, d0


    ist das halt weit, weit mehr.

    156 8-Bit-Regtister sind wenig? Aber hallo...!


    Die Zeropageadressen zählen nicht wirklich als Prozessorregister, auch wenn man sie sich auf einer abstrakten Ebene so vorstellen kann. Das Ansprechen benötigt generell einen Taktzyklus mehr, da der Wert erst aus dem Speicher in den Prozessor geladen werden muß. Will man z. B. Vergleichsoperationen durchführen, muß man den Wert erst in ein (freies) Register laden und dann vergleichen. Kostenpunkt: mindestens 5 Taktzyklen. Wenn man so denkt, wie Du es formulierst, dann hätte der 68000 65536 Register mehr, weil er auch die gekürzte Adressierungsart abs.W kennt.

    ich bin irgendwie auch nur damit beschäftigt, die in den Akku zu schaufeln, wen ich irgendwas sinnvolles damit tun will. Beim i86 wird das tendenziell etwas besser, aber leider auch langsamer. Und der 68000 nervt mit seiner strikten Trennung zwischen Adress- und Datenregistern.


    Yep, ich muß gestehen, daß ich den 6502 auch stets dem Z80 vorgezogen habe. Der alte 8086 war m. M. n. ein typischer Intel: Kein orthogonaler Befehlssatz, statt dessen spezialisierte Register, überflüssige Befehle (XLAT), eine umständliche Speicheradressierung (Segmente!), kurz: Schrott. Was die Register des 68000 anbelangt, so fiel es mir damals (geklautes TM) nicht so auf, als ich vom 6502 rüberwechselte. Da war man froh, daß man überhaupt so viele Register hatte. Nachdem ich mich aber mit diversen RISC-Prozessoren beschäftigt habe, fällt es mir auch schwerer, zum 68000 zurückzukehren, obwohl ich ihn immer noch x86 vorziehen würde.

  • Wie sieht es mit ARM ASM aus, macht das wer?

    Ich kenn jemand, der es nutzt um Bitcoin Kram auf Smartphones zu beschleunigen. Hab es mal kurz überflogen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Fand ich bei meiner Programmierung des 68000 in Assembler nicht so das Problem. Das man endlich mal genug Register hatte hat mir gut gefallen.

    Ja, schon. Und unter heutigen Aspekten von Speicherschutz, virtuellem Speicher etc. ist ein getrennter Satz Adreßregister gar nicht mal so verkehrt- ich meine die Architektur kam sogar mal aus dieser Überlegung heraus zustande? Aber es ist halt auch unflexibel, 'viel Äpfel' und 'viel Birnen' einzubauen um für alle Fälle gerüstet zu sein- und dennoch auf die Nase zu fallen, falls man mal ausnahmsweise 'mehr Äpfel' braucht, während die Birnen vor sich hin welken. (Siehe auch die RISC-Idee der möglichst effizienten Ausnutzung der Chipfläche)

    Bitte gestatte mir jedoch eine Antwort auf Deine Antwort.

    Du fragst ernsthaft nach, ob Du in einem Diskussions-Forum diskutieren darfst?

    Es gibt aber für die Zeropage-Pointer keine Befehlssunterstützung z. B. zum vollständigen 16-Bit Inkrementieren und Dekrementieren oder direkten Schreiben von Werten.

    Ja, Pointer-Arithmetik ist bei allen 8-Bittern mehr oder weniger limitiert- das hat aber mit der technischen Implementierung nix zu tun. Siehe (mal wieder) den Z80 mit seiner vergeigten 16-Bit-Arithmetik und seinen Pseudo-Indexregistern.

    Tip: Es gibt Prozessoren, die ihre ganze Registerbank im Hauptspeicher halten udn mittels 'Basis-Zeiger' sogar beliebig umherschieben können. *das* ist flexibel, auch wenns ohne Cache nicht unbedingt der Performance-Killer ist.

    Tip2: Man behauptet immer wieder, der RCA COSMAC habe keienn Call-Befehl. Stimmt, man kann sich einen solchen aber mit einer kleinen Subroutine selbst bauen und ist trotzdem schneller und _wesentlich_ flexibler als alle fest verdrahteten Calls dieser Welt. Denn man ist nicht an einen einzelnen Stackpointer gebunden, den man womöglich ncihtmal auslesen kann, sondern hat die freie Auswahl aus 8 universellen Pointern.

    Auch benötigt man auf dem Original 6502 immer das X- oder Y-Register für die Adressierung, wodurch dieses Register für anderweitige Aufgaben verloren geht.

    Nach meiner Erfahrung ist das nur selten ein Problem (und vor allem dann, wenn der Programmierer auf Z80 gelernt hat), denn oftmals braucht man eh einen Index auf den Pointer. Und klar, der 6502 hat extrem wenige Register... auf dem Chip, dafür aber _wirklich_ viele in der Zeropage. Nur mit dieser Semantik ist überhaupt erklärbar, daß man mit dem 6502 ein universelles Computersystem bauen kann und nicht nur Microwellen-Zeitschaltuhren. Denn wie Du weiter oben schon gesagt hast: Touring-Vollständigkeit allein reicht nicht, es muß auch halbwegs flott von statten gehen.

    Verglichen mit

    MOVE.L (sp)+, d0

    ist das halt weit, weit mehr.

    Klar. Prinzipielles Problem, sobald das Maschinenwort kürzer als das Speicher-Adreßwort ist. Das hat aber mit dem Alter der Prozessor-Architektur wenig zu tun (siehe Ursprungsfrage), das gabs schon zeitgleich zum 6502 in wesentlich eleganter, und der 68000er ist nichtmal fünf Jahre jünger.

    Die Zeropageadressen zählen nicht wirklich als Prozessorregister, auch wenn man sie sich auf einer abstrakten Ebene so vorstellen kann. Das Ansprechen benötigt generell einen Taktzyklus mehr, da der Wert erst aus dem Speicher in den Prozessor geladen werden muß.

    Ja, die Implementierung ist suboptimal. Aber denk Dir einen Cache dazwischen, setze vor jede Zeropageadresse ein 'R' und Du hast die Semantik eines 256-Byte-Registerfiles.

    Yep, ich muß gestehen, daß ich den 6502 auch stets dem Z80 vorgezogen habe.

    Was heißt hier 'auch'? der Z80 ist mein absoluter Lieblingsprozessor, sowohl software- wie hardwaretechnisch. Es gab den VC20 aber nicht mit eiem solchen, udn gerade als langjähriger Nutzer sind mir die Macken und leeren Werbeversprechen umso deutlicher bewußt. Und- ich habe eine gewisse Vorliebe für Prozessoren, die irgendwas 'anders' machen als üblich. Frag mich nach dem Businterface des (angeblich) PC-losen Fairchild F8, oder dem Arithmetikbefehl des Rockwell PPS-8 (da ist der Befehl nur ein index in eine Tabelle, in der der eigentliche Opcode und Operand drinstehen!)

    Der alte 8086 war m. M. n. ein typischer Intel: Kein orthogonaler Befehlssatz, statt dessen spezialisierte Register, überflüssige Befehle (XLAT), eine umständliche Speicheradressierung (Segmente!), kurz: Schrott.

    Zeig mir _irgendeinen_ 8-bitter mit orthogonalem Befehlssatz. Wie sollte dann der (zum 8080 befehlskompatible) 8086 einen solchen habne können? Diese Quellcode-Beinahe-.Kompatibilität war aber ein wichtiges Verkaufsargument, weil man mit geringem Aufwand ein leistungsfähigeres System zusammenschustern konnte. Noch einfacher wurde es mit dem 8088, udn deswegen hat IBM den auch hergenommen für das kurzlebige Produkt 'IBM Personal Computer'.

    Dito für die universellen Register- wobei man da schon eher fündig wird. Aber der 8080 war mit seinem CP/M halt *der* Prozessor...

    ...und die überlappenden Segmente waren für damalige Verhältnisse durchaus genial: Wenig Verschnitt, großer Adreßraum, kurze Operanden. Klar, wenn Speicher nix kostet und man beliebig viel Silizium in eine MMU für lineare Adressen verbraten kann, dann wirkt es holprig. Als Upgrade-Pfad für bestehende Software und Mini-Disketten war es aber der Königsweg. Also IMHO kein Schrott, sondern ziemlich genial, wenn auch zuweilen etwas 'over-engineered'.

    PS: für XLAT verweise ich mal auf die RISC-Diskussion. Natürlich geht das eleganter und orthogonaler- aber wenn genau dieser Befehl von einem Compiler gebraucht wird, mit genau diesen Parametern? Warum nicht?

    KI-Verwendung in diesem Posting: Rechtschreibkontrolle des Browsers.
    Abweichungen aufgrund des technischen Fortschritts oder individueller Vorlieben vorbehalten.

  • Nimm einfach keinen 6502 sondern den 6809 ist aehnlich alt hat aber viel mehr (und bessere) addressierungs arten! (setzte mich z.Z. mit dem auseinander wegen des Vectrex).

    Ich finde es total schade dass in den Apple I nicht wie geplant ein 6809 sondern ein 6502 eingebaut wurde (und damit dann die commodore rechner nicht den auch haben, denn commodore hat viel vom Apple uebernommen)


  • Der 6809 war nunmal brutal teuer und auch früher war der Geiz Geil...


    Laut Wikipedia kam der Apple 1 im Jahr 1976 raus, der 6809 aber erst 1978. Wäre also schwierig gewesen, den im Apple I einzusetzen...