Beiträge von mc71 im Thema „Assembler 65xx - Vergleich mit heute“

    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?

    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.