mc71
Du fragst ernsthaft nach, ob Du in einem Diskussions-Forum diskutieren darfst?
Naja, ich bin halt neu hier und möchte gerne vermeiden, unabsichtlich wegen schlecht formulierter Äußerungen jemanden auf die Füße zu treten. Das ist überhaupt nicht mein Ding, denn im Grunde genommen bin ich ein zurückhaltender, langweiliger Typ und mag es daher nicht, irgendwie besserwisserisch oder angeberisch zu klingen. Zumal ich viel mehr sehr froh darüber bin, wenn andere Leute von ihren Erfahrungen und Meinungen berichten. (Soviel weiß ich nämlich gar nicht.)
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?
Ich bin nicht sicher, ob das wirklich so dahinter stand. Es könnte auch an anderen Gründen gelegen haben. Trivial: Für die Befehlscodierung waren nicht genügend freie Bits vorhanden (3 vs. 4 Bits). Auch besteht ein Unterschied zwischen Daten- und Adreßregister darin, daß Operationen auf Adreßregistern bewußt nicht die Flags setzen, um parallele Operationen auf den Datenregistern nicht zu beeinflussen. Und solange man den Speicher auch direkt adressieren kann (ohne dazwischengeschaltetes Adreßregister), läßt sich virtueller Speicher etc auch damit allein nicht realisieren.
Man behauptet immer wieder, der RCA COSMAC habe keienn Call-Befehl
Sehr interessant. Den kannte ich noch gar nicht. War noch vor meiner Zeit. Ich muß gestehen, daß ich ein vom Luxus der 80er verwöhntes und verzogenes Kind bin. Übrigens hat der ARM (weil RISC) eigentlich auch keinen Call-Befehl. BL schreibt ja nur den PC ins Linkregister und ersetzt ihn dann durch einen neuen Wert. Das Pushen auf den Stack muß man selbst übernehmen.
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.
Meiner Erfahrung nach ist das andauernd ein Problem. Bitte melde dich an, um dieses Bild zu sehen. Wenn ich z. B. Graphik programmiere, brauche ich immer mehr Pointer/Zähler als vorhanden. Oftmals sehen dann Programme so aus, daß man X auf 0 setzt, um mehrere Pointer anzusprechen, die dann aber händisch mit 'INC zp' inkrementiert werden müssen.
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.
Naja, denken kann ich mir eine ganze Menge. Bitte melde dich an, um dieses Bild zu sehen. Die Frage war aber, was unterscheidet einen 65xx von heutigen (oder genauer: fortschrittlicheren) Prozessoren, und der 6502 hatte nun einmal weder einen Cache noch ausreichend Befehle, um die Zeropage wie ein Register ansprechen zu können. Der 68000 konnte da bei seiner 'Zeropage' immerhin mit Konstanten vergleichen, subtrahieren, addieren...
Was heißt hier 'auch'? der Z80 ist mein absoluter Lieblingsprozessor, sowohl software- wie hardwaretechnisch.
Ups, tschuldigung, nehme alles zurück. Es ist nur so, daß ich vor paar Jahren einen Z80-Emulator geschrieben habe für die Z80-Karte des AppleII. Dabei mußte ich mich dann auch durch einigen Code von CP/M durchwühlen. Sagen wir es mal so: Ich war nicht beeindruckt.
ich habe eine gewisse Vorliebe für Prozessoren, die irgendwas 'anders' machen als üblich.
Verzeih, aber das klingt sehr interessant. Dürfte ich fragen, woher Du die kennst bzw. ob Du die alle selber programmiert hast?
Zeig mir _irgendeinen_ 8-bitter mit orthogonalem Befehlssatz.
Der 8086 war aber nun mal kein 8-Bitter mehr. Und deswegen hätte man wirklich mehr erwarten können (s. u.).
Diese Quellcode-Beinahe-.Kompatibilität war aber ein wichtiges Verkaufsargument, weil man mit geringem Aufwand ein leistungsfähigeres System zusammenschustern konnte.
Sehr schön zusammengefaßt. Bitte melde dich an, um dieses Bild zu sehen. Ein typischer Intel eben: Profit geht vor Design. (Man merkt, ich bin kein Geschäftsmann. Bitte melde dich an, um dieses Bild zu sehen.) Nach diesem Prinzip arbeiten die bis heute. Mein Verdacht: Wäre AMD nicht mit x64 vorgeprescht, hätten wir heute noch kein 64-Bit Linux/Windows (auf PCs). Ich weiß nicht, wieviel Erfahrung Du mit der Programmierung dieser Kiste hast, aber ich für meinen Teil hätte mehr als einmal in die Tastatur beißen können vor lauter Wut und Frust. Macht einfach keinen Spaß. Der 8086 ist IMHO im Vergleich zum 68000 von der Programmierseite her schlicht nicht durchdacht, sondern eine einzige Katastrophe: "String"-Befehle, die in 99% der Fälle für alles andere als Strings verwendet werden. Register (und schlimmer noch: Befehle), die an Segmente gekoppelt sind und mittels Override-Befehl umgepolt werden müssen usw. usf. Ich bin froh, daß ich das hinter mir habe.
Sinnvoller (wenn vielleicht auch nicht im geschäftlichen Sinne) wäre es gewesen, wenn sich Intel vom alten Design getrennt und etwas neues aufgebaut hätte. Meine Heldin ist hier Sophie Wilson. Die hat genau das gemacht: Sch..ß auf die alten Prozessoren. Hinsetzen und was neues entwerfen. Und heraus kam der ARM. Das nenne ich genial.
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?
XLAT ist der Befehl, den ich nie, nie, nie verwendet habe, weil er völlig überflüssig ist. Ich habe mir zudem schon einige Male einen vom Compiler erzeugten Code angesehen, und nie auch nur ein XLAT darin gefunden. Bitte melde dich an, um dieses Bild zu sehen. Und ehrlich gesagt, kann ich mir auch keinen Compiler vorstellen, der diesen Befehl verwenden möchte. Soviel ich weiß ist es eher so, daß gerade Compilerbauer über solche spezialisierten Befehle gar nicht erfreut sind, weil das die Registerbelegung total durcheinanderbringt. (Gleiches gilt auch für MUL, DIV, STOS etc.) Compiler(bauer) lieben orthogonale Befehlssätze.
Eine Sache hatte ich übrigens vergessen, die den 6502 von neueren Prozessoren unterscheidet: PC-relative Adressierung. Auf dem 68000 kann ich problemlos (ohne einen speziellen Lader) relokatible Programme erzeugen. Auf dem 6502 geht sowas nicht. Die paar Sprungbefehle reichen dafür nicht. Theoretisch könnte man einen Lader entwickeln, der alle Adreßbezüge beim Laden umrechnet. Das ist aber sehr umständlich und wird daher auch bis auf sehr, sehr wenige Ausnahmen (DOS 3.3 Masterdisk) nicht praktiziert. So hat z. B. UCSD-Pascal dies auch nur mit Einschränkungen implementiert, um Bibliotheken wie Turtlegraphics oder Transcend dynamisch nachladen zu können. Aber dabei war es z. B. nicht möglich folgendes zu schreiben:
LDA #<label
STA zp
LDA #>label
STA zp + 1
...
label:
weil Assembler und Lader nicht in der Lage waren, die 8-Bit Konstanten als Label zu identifizieren und anzupassen.