Posts by alx

    Nicht direkt.


    Was du machen kannst ist die einzelnen Blöcke einzeln als "mem" zu komprimieren und den Beispiel Entpacker so anpassen dass er deine Blöcke entsprechend auspackt.

    (Das mache ich so in vielen Projekten, sorgt auch dafür dass es deutlich kleiner wird.)

    Das muss man dann abwägen, ob Platz oder Geschwindigkeit der Vorzug zu geben ist. ;)

    Und ob man ein freies index register hat. Und wenn du das nicht >1000 mal pro sekunde durchlauefst wird der geschwindigkeits unterschied (worst/best case loop / fixed) nicht relevant sein. (Und dafür ist auch noch die frage ist auch wie oft die werte gleich seien werden, denn das ist der worst case der loop.)

    Stimmt, wenn dir das ergebnis egal ist dann geht das auch, aber dies is kürzer:

    Code
    1. lda neuer_wert+2
    2. cmp alter_wert+2
    3. lda neuer_wert+1
    4. sbc alter_wert+1
    5. lda neuer_wert+0
    6. sbc alter_wert+0
    7. bcc neu_ge_alt

    1.) Bei Ansicht der Befehle kommt es mir so vor, als wären diese recht breit (oftmals 4 Zeichen pro Befehl). Gäbe es die Möglichkeit, die Befehle im Sinne einer besseren Lesbarkeit ein wenig zu kürzen oder orientierst Du Dich an einer realen Vorlage und möchtest nach Möglichkeit Befehle in der Schreibweise übernehmen? Ansonsten wäre z. B. bei einer Anweisung wie "LDAI #$30" das "I" eigentlich redundant, sofern es "Immediate" bedeuten soll, was schon durch das "#" zum Ausdruck gebracht wird, und bei den Branch-Befehlen ließe sich analog zum 6502 oder 68000 das "R" einsparen, also "BNE" anstelle von "BRNE".

    Das mit dem # ist ein versehen, das sollte nicht angezeigt werden (und eigentlich sollte auch alles als 0x und nicht $ da sein, aber ich hatte aus bequemlichkeit das erstmal einfach übernommen). Ich habe im allgemeinen nicht vor das zu kürzen, aber ob du das R aus allen branches rauswirfst oder nicht soll mir egal sein. Andererseits sollte der Name das kleinste Problem sein. (Die Befehle und Namen sind an 6809 und 8-bit-AVR angelehnt, von denen ich viel übernommen habe.)


    2.) Wie gestaltest Du das Taktverhalten und damit die Ausführungsgeschwindigkeit Deines Prozessors? Folgst Du dem Beispiel des 6502, der (grob gesagt) für einen Speicherzugriff einen Takt (aufgeteilt auf zwei Phi-States) benötigt oder verfolgst Du ein komplizierteres Verhalten wie beispielsweise beim Z80, der die Maschinenzyklen in weitere T-States unterschiedlicher Anzahl unterteilt?

    Das Ziel ist es dass ein Takt pro gelesenem/geschriebenen Byte benötigt wird, und nicht mehr. (also "sta x,20" braucht 3 takte; 1. opcode, 2. offset, 3. speichern) (Aber wie genau das passieren kann/muss weiss ich nicht, ich hab' das nur dem VICE beigebracht.)


    3.) Für wie effizient hinsichtlich Ausführungsgeschwindigkeit und Codedichte würdest Du im Vergleich zum 6502 Dein Design einschätzen?

    Durch den meistens kürzeren code und die schnellere Ausführung sollte er ca. doppelt so schnell sein.


    4.) Möchtest Du langfristig gesehen über die CPU hinaus auch eine Systemumgebung (Video, Sound etc) als eigene Umwelt für Deine CPU definieren?

    Bevor ich die Idee der CPU hatte wollte ich mal den VIC erweitern (so dass man z.B. ein farbenreicheres charset direkt in den VIC lädt; bis auf das "reinladen" und aktivieren wäre der Code identisch und das selbe Spiel kann mit und ohne erweiterten vic laufen, nur halt auf dem einen schöner), was ich geschafft habe ist eine rudimentäre GPU, die aus großen Fonts/Screens ein Multicolor-Bitmap berechnet und diese dem VIC "unterschiebt". (Technisch: ist ein Modul, der VIC muss auf Multicolor-Bitmap gestellt werden, immer wenn der VIC Screen oder Bitmap lädt wird der C64-Bus auf inaktiv geschaltet und das Modul legt die Daten direkt auf den Bus. Hatte das in einer einfachen version auf echter Hardware am laufen. Ist auch in irgendeinem Thread hier erwähnt.) Aber nein, ich habe zumindest z.Z. nicht vor eigene Hardware zu Bauen/Definieren.

    Kleines update: ich habe den Befehlssatz meiner ausgedachten CPU nochmal verändert (und das wird bestimmt noch ein paar mal passieren ;-)
    Und ich habe den x64 (vice) gepatcht: fast alle addressierungs-modi, ein paar befehle und der disassembler funktionieren schon. Ich werden den eingebauten assembler nicht umbauen. Werde euch was zeigen, wenn's wirklich was zu zeigen gibt.
    (P.S.: Is ein übler hack der grosse teil des 6502/6510 Zeugs ersetzt.)

    Entweder man unterscheidet zwischen LEA und den anderen Befehlen (nur bei LEA ist der Wert negativ), oder man benutzt für Operationen am Stapelzeiger bzw. fürs In-/Dekrementieren der Register eigene Befehle, oder man benötigt fürs Subtrahieren halt einen 3-Byte-Befehl.Was mir noch auf-/eingefallen ist:
    In der von Dir verlinkten Befehlsübersicht gibt es noch weiße Stellen (z. B. 05 und 08). Hast Du schon Ideen für Befehle, die man an den freien Stellen einbinden könnte?

    Wie schon gesagt, versuche die die cpu einfach zu halten, also auch das decoding welche operation mit welchem modus ausgeführt werden soll die Anzahl an Operation und so weiter - darum will ich nicht alles bis zum letzten belegen.



    Welche Flaggen gibt es bei dem Prozessor und wann werden sie gesetzt?

    Wie die 8 bit avr, ohne dem H flag. Wie carry genutzt wird auch wie die. Gesetzt eher wie beim 6502.



    Hattest Du schon mal den Befehlssatz ausgetestet bzw. hast Du vor, Programme mit Hilfe eines Emulators zum Laufen zu bringen? (Leider habe ich wegen anderer Projekte keine Zeit, sonst würde ich mal sowas wie einen kleinen Emulator schreiben.)

    Nein, es ist bis jetzt nur ein Gedankenspiel. Und wenn dann würde ich versuchen den vice oder einen anderen C64 emulator auf die cpu umzubauen.


    Wie sollen sich 16 Bit-Operationen unterscheiden von 8 Bit-Operationen?

    Es gibt keine 16 Bit-Operationen ausser lea (und incx = leax x,1).


    Ich habe die cpu geändert, nun sind alle (16bit register , 8bit register) operationen in einem opcode versteckt, denn ja, es braucht nicht so viele. Zudem gibt es ein neues Register U, welches aber nur eingeschränkt genutzt werden kann.


    Neue Beschreibung

    Es ging um negative Adress-Offsets, nicht um negative Konstanten.

    Das ist z.T. das selbe: wenn du nicht "leas s, -5" schreiben kannst weil es keine negativen offsets gibt, wie willst du dann 5 bytes auf den stack pointer reservieren? (Oder X/Y decrementieren)?

    Grundsätzlich stimme ich diesem Ansatz voll zu :dafuer: , habe jedoch Bedenken bei der Umsetzung im Befehlssatz. Wie bereits erwähnt kommen negative Offsets so gut wie nie vor, wohingegen man positive Offsets (z. B. für lokale Variablen auf dem Stack oder Objektattribute) häufig benötigt.

    Ich hatte auch darüber nachgedacht alle Offsets nur positiv zu machen ausser lea (denn sonst könnte man x,y,s,pc nicht reduzieren)


    Aber eines meiner hauptziele ist es eine CPU zu erdenken die auch damals™ jemand hätte bauen können. Wenn man z.B. einen 6502 baut der die zeropage direkt in der cpu speichert würden all die operationen VIEL schneller gehen, aber niemand hätte so etwas baue können/wollen. Darum halte ich die Befehle und Adressierungs-Modi möglichst einfach und einfach zum dekodieren.


    [...], die häufiger gebraucht werden, z. B. "INX". Ein "LEAX X, 1" dürfte mit seinen 3 Speicherzugriffen für eine Zählschleife zu viele Takte verbrauchen, zumal unklar ist, ob bei diesem Befehl die Flaggen gesetzt werden. Sollte dies (wie beim 68000) nicht der Fall sein, so müßte anschließend noch ein Test auf 0 erfolgen.


    Na leax x,1 sind nur 2 bytes (opcode + 7bit offset) und nicht 3. Aber wenn du was kopierst machst du eh' "lda x+; sta y+", zum zählen kannst du perfekt b nutzen. Und was die flags betrifft würde ich die sehr ähnlich zum 6502 machen: bei rechen- und ladeoperationen. (aber nicht speichern, jmp und so) (der 6809 z.B. setzt die immer wenn ein register ausser PC betroffen ist, also auch beim sta; die AVR's ändern die flags beim laden/speichern nicht)

    Erst einmal: Hut ab vor der detaillierten Ausarbeitung!


    Danke, das oben war die nette Beschreibung, hier die Auflistung aller opcodes - obwohl sich da noch viel ändern kann: https://pste.eu/p/LPrr.html (Farbe = Opcode-Größe)



    Auf der anderen Seite: Geht man damit nicht zu weit in die Tiefe? Wenn man für eine Fantasie-CPU sich neu in die (nur dort verwendbare) Maschinensprache einarbeiten soll, verlangt man dem Nutzer nicht zuviel ab?

    Wenn du dir die 6809 CPU anschaust, siehst du dass die fast alles dieses und viel mehr kann - ich hab's aber absichtlich einfach gehalten.