Nun gibt es hier einen weiteren Versuch, eine neue 8-Bit-Architektur vorzustellen. Alles ist noch vorläufig, vom Namen (f8, nicht zu verwechseln mit dem Fairchild F8 aus den 1970ern), bis zum Instruktionssatz (wo aber nur noch geringe Änderunge zu erwarten sind) und der Opcode-Map. Schon lange hatte ich mit dem Gedanken gespielt, mich an einer eigenen 8-Bit-Architektur zu versuchen. Den Ausschlag gab dann die (inzwischen teils zurückgenommene) Abkündigung der STM8 durch ST, da ich diese als eine der elegantesten bisherigen 8-Bit-Architekturen ansehe. Hauptziel war es, eine effiziente Zielarchitektur für C-Compiler zu entwickeln, insbesondere im Hinblick auf den Speicherbedarf. Aufgrund meines Hintergrunds im Übersetzerbau ist mir dies vermutlich besser gelungen, als die Architektur auf effiziente Implementierbarkeit in Hardware zu optimieren. Es fehlt noch vieles (insbesondere nahezu alle Dokumentation), aber es gibt bereits ein bischen Code (https://sourceforge.net/p/sdcc/code/14908/tree/branches/f8/): * Mein erster Versuch einer Implementierung in Verilog. Single-cycle, benötigt recht aufwendigen Speicher mit mehreren Ports. * Mein zweiter Versuch einer Implementierung in Verilog. Multi-cycle. Kommt mit deutlich einfacherem Speicher aus. * Jeweils ein einfaches SoC dazu (f8-Kern, Speicher, Watchdog, Timer, Interrupt controller, 2xGPIO). * Letzteres habe ich bisher auf zwei FPGA-Boards portiert: iCEBreaker und GateMateA1-EVB. * Einfache Beispielprogramme (LED blinken, "Hello, world!" via Software-emuliertem UART, Dhrystone, etc) laufen.
:
Bearbeitet durch User
Nett! Eine bischen Dokumentation wäre hilfreich, vor allem da die Navigation durch den Source auf sourceforge nicht so einfach ist. (warum nicht Github?) Anscheinend liegen auch die Sources beider CPU-Varianten im gleichen Verzeichnis? Etwas verwirrend.
>Hauptziel war es, eine effiziente Zielarchitektur für C-Compiler zu entwickeln, insbesondere im Hinblick auf den Speicherbedarf. Aufgrund meines Hintergrunds im Übersetzerbau ist mir dies vermutlich besser gelungen, als die Architektur auf effiziente Implementierbarkeit in Hardware zu optimieren. Was genau hast Du denn hier implementiert, was die Codedicht ggü. AVR oder STM8 verbessert?
Philipp Klaus K. schrieb: > (f8, nicht zu > verwechseln mit dem Fairchild F8 aus den 1970ern) Nicht böse gemeint: das ist doch scheisse so, gleich beim Namen schon ein AAAABER
Wf88 schrieb: > Philipp Klaus K. schrieb: >> (f8, nicht zu >> verwechseln mit dem Fairchild F8 aus den 1970ern) > > Nicht böse gemeint: das ist doch scheisse so, gleich beim Namen schon > ein AAAABER +++ Eine Reinkarnation des Fairchild F8 waere immerhin interessant (gewesen). Wer dem STM8 nachgetrauert haette, haette sich ja auch mal (nur als Beispiel) bei den RL78 umsehen koennen. Und da gibt es durchaus noch mehr Familien, die von der "Machart" aehnlich sind...
Tim . schrieb: > Nett! > > Eine bischen Dokumentation wäre hilfreich, vor allem da die Navigation > durch den Source auf sourceforge nicht so einfach ist. (warum nicht > Github?) Ein klein wenig Dokumentation kam inzwischen dazu: https://sourceforge.net/p/sdcc/code/HEAD/tree/branches/f8/f8/hardware/ SourceForge, da SDCC dort ist, und der f8 durch Erfahrungen aus dem Schreiben von SDCC-Backends für andere Architekturen motiviert ist. Wenn der f8 weitere Fortschritte macht, könnte sich das noch ändern (Simulator, Compiler und Assembler würden bei SDCC bleiben). > Anscheinend liegen auch die Sources beider CPU-Varianten im gleichen > Verzeichnis? Etwas verwirrend. Es gibt ein paar Quelldateien, die in beiden Varianten verwendet werden. Philipp
Motopick schrieb: > Wer dem STM8 nachgetrauert haette, haette sich ja auch mal (nur als > Beispiel) bei den RL78 umsehen koennen. Dem RL78 mangelt es im Vergleich zum STM8 am Stackpointer-relativen Adressierungsmodus. Es gibt ihn beim RL78 nur bei wenigen Befehlen. Ein effizienter, bei vielen Befehlen verfügbarer Stackpointer-relativer Adressierungsmodus ist sehr nützlich zum effizienten Zugriff auf lokale Variablen in C-Programmen.
:
Bearbeitet durch User
Tim . schrieb: > Was genau hast Du denn hier implementiert, was die Codedicht ggü. AVR > oder STM8 verbessert? Der STM8 ist bezüglich der Codegröße bereits recht gut, insbesondere durch seinen effizienten Stackpointer-relativen Adressierungsmodus. Insbesondere im Vergleich zum Z80 und Rabbit fällt auf, dass der STM8-Code oft effizienter ist. Die Ausnahme ist Code, bei dem die meisten lokalen Variablen in die Register des Z80 passen, oder bei denen die etwas mächtigeren 16-Bit-Befehle des Rabbit hilfreich sind. Daher war es naheliegend, dem f8 ein paar Register zu geben, die sich (wie beim Z80) als zweiten Operanden neben dem Akkumulator verwenden lassen, und einige 16-Bit-Befehle. Das hat anscheinend funktioniert: obwohl an den stm8, z80 und r3ka-Ports von SDCC viele Jahre gearbeitet wurde, erzeugt der im Vergleich noch etwas einfache f8-Port meist bereits kompakteren Code. P.S.: Natürlich wurde gegenüber dem STM8 auch auf manches verzichtet, z.B. Divisionsbefehle, Zero-Page-Adressierungsmodus und einige komplexere Adressierungsmodi.
:
Bearbeitet durch User
Philipp Klaus K. schrieb: > Motopick schrieb: >> Wer dem STM8 nachgetrauert haette, haette sich ja auch mal (nur als >> Beispiel) bei den RL78 umsehen koennen. > > Dem RL78 mangelt es im Vergleich zum STM8 am Stackpointer-relativen > Adressierungsmodus. Es gibt ihn beim RL78 nur bei wenigen Befehlen. Ein > effizienter, bei vielen Befehlen verfügbarer Stackpointer-relativer > Adressierungsmodus ist sehr nützlich zum effizienten Zugriff auf lokale > Variablen in C-Programmen. Ist mir bei meinem Ausflug in die RL78-Welt gar nicht so aufgefallen. Zum Laden der Parameter von und zum Stack hat es jedenfalls gereicht. Und in einem Assemblerprogramm gab es dann auch, wie ich fand, bessere Alternativen als relativ zum Stack zu adressieren. Ich werde mir interessehalber mal anschauen, wie der von mit benutzte Compiler damit umgeht. Die Geruechte zum vorzeitigen Ableben des STM8 haben sich ja auch nicht bestaetigt. Waere ja auch schade drum.
Hast du dir das Bo8-Projekt mal angesehen? Warum erweiterst du dies nicht?
OT: https://ia600709.us.archive.org/30/items/bitsavers_fairchildfng1977_5888299/F8_Guide_To_Programming_1977.pdf :) An dem Stil koennten sich heutige Autoren eine ganze Scheibe abschneiden.
Philipp Klaus K. schrieb: > Ein klein wenig Dokumentation kam inzwischen dazu: > https://sourceforge.net/p/sdcc/code/HEAD/tree/branches/f8/f8/hardware/ Einen knappen Überblick über den Befehlssatz gibt es nun auch: https://sourceforge.net/p/sdcc/code/HEAD/tree/branches/f8/f8/doc/
Sieht sehr CISCig aus, und schon fast nach einem 16 bit Prozessor. Um das in einem effizienten 8-bit Datenpfad unterzubringen benötigt man viele Taktzyklen pro Befehl. Ich frage mich immer, warum es so weniger 16 bit Prozessoren gibt - eigentlich ja nur den MSP430. Viele 8bit Architekturen kommen aber mit 16 bit Registern, was ja zeigt, dass 8 bit eigentlich nicht genug sind (AVR, STM8, etc.). Warum also nicht gleich 16 bit? In einer Technologie <0.5µm sollte ein 16 bit Datenpfad eigentlich kein Problem sein. Heutzutage mit <100nm, sowieso nicht.
Tim . schrieb: > Sieht sehr CISCig aus, und schon fast nach einem 16 bit Prozessor. Um > das in einem effizienten 8-bit Datenpfad unterzubringen benötigt man > viele Taktzyklen pro Befehl. > > Ich frage mich immer, warum es so weniger 16 bit Prozessoren gibt - > eigentlich ja nur den MSP430. Viele 8bit Architekturen kommen aber mit > 16 bit Registern, was ja zeigt, dass 8 bit eigentlich nicht genug sind > (AVR, STM8, etc.). Warum also nicht gleich 16 bit? In einer Technologie > <0.5µm sollte ein 16 bit Datenpfad eigentlich kein Problem sein. > Heutzutage mit <100nm, sowieso nicht. Tatsächlich haben meine beiden Implementierungen einen 16-Bit-Datenpfad innerhalb der CPU, und ich hätte den f8 wohl oben besser als 8/16-Bit-Architektur bezeichnen sollen. Dennoch wäre eine 8-Bit-Implementierung möglich. Um einen hinreichend großen Speicher zu adressieren, und eine gute Zielarchitektur für C-Compiler zu sein, müssen nunmal 16-Bit Daten (für Zeiger und für int) effizient verarbeitet werden können. Andererseits wollte ich aber auch 8-Bit Daten gut unterstützen, damit, wo diese ausreichen, kein Speicher verschwendet wird. D.h. insbesondere, dass die Opcodes 8-Bit sind (mit Präfixbytes für seltener genutzte), und char 8 Bit hat.
Tim . schrieb: > Ich frage mich immer, warum es so weniger 16 bit Prozessoren gibt - > eigentlich ja nur den MSP430. Du meinst vermutlich Microcontroller, nicht -Prozessoren. 16-Bit-Prozessoren waren z.B. 8088/8086 bzw. 80188/80186. Lange davor gab es den TMS9900: https://en.wikipedia.org/wiki/TMS9900 Pedanten bezeichneten auch den Motorola 68000 als 16-Bit-Prozessor (obwohl der mit 32-Bit-Registern arbeitete, enthielt er nur eine 16-Bit-ALU, und hatte auch nur einen 16-Bit-Datenbus) - aber das ist eine Spitzfindigkeit, das Ding hatte einen 32-Bit-Befehlssatz. 16-Bit-Microcontroller waren Motorola 68HC12 und 68HC16 https://en.wikipedia.org/wiki/Motorola_68HC12 https://en.wikipedia.org/wiki/Motorola_68HC16 Intel MCS-96 https://en.wikipedia.org/wiki/Intel_MCS-96
Tim . schrieb: > Ich frage mich immer, warum es so weniger 16 bit Prozessoren gibt Wenn den 8-Bittern der Adressraum ausgeht, löst man das einfacher durch 32-Bitter, als durch 16-Bitter, die das gleiche Problem haben. Gerade die MSP430 sind ein Beispiel dafür. Jenseits 64 KB gibt es da zwar, aber die Eleganz der rein auf einen einzigen 64 KB Adressraum optimierten Architektur blieb bei diesem Schritt auf der Strecke. Gerade als gute Zielarchitektur für C hat man mit 8/16-Bit jenseits 64 KB seine liebe Not, und mit Pointern unterschiedlicher Länge in unterschiedliche Adressräume zu tun. Mit 32-Bit ist das völlig verschwunden.
:
Bearbeitet durch User
Harald K. schrieb: > 16-Bit-Microcontroller waren Zwei schöne Gründe, weshalb man sich nicht unbedingt mit 16-Bittern beschäftigen will, sind 65816 und MAXQ2000. :)
:
Bearbeitet durch User
(prx) A. K. schrieb: > Harald K. schrieb: >> 16-Bit-Microcontroller waren > > Zwei schöne Gründe, weshalb man sich nicht unbedingt mit 16-Bittern > beschäftigen will, sind 65816 und MAXQ2000. :) Man koennte die Aufzaehlung noch mit den Controllern der eCog1x-Serie fortsetzen. 24 bit Adressraum fuer Code, aber nur 16 bit fuer Daten. Und die MMU kann immer nur genau 2 Bereiche aus dem gesamten Datenraum in dieses 64 k Fensterchen hineinmappen. > Jenseits 64 KB gibt es da zwar, aber > die Eleganz der rein auf einen einzigen 64 KB Adressraum optimierten > Architektur blieb bei diesem Schritt auf der Strecke. Auch sehr schoen beim Zilog Z8002 zu sehen. Die ganze "Einfachheit" und "Eleganz" ist dahin, wenn man mehr als 64 KB braucht. Die aufgebohrten MSP430 folgen da nahtlos.
(prx) A. K. schrieb: > Gerade als gute Zielarchitektur für C hat man mit 8/16-Bit jenseits 64 > KB seine liebe Not, und mit Pointern unterschiedlicher Länge in > unterschiedliche Adressräume zu tun. Mit 32-Bit ist das völlig > verschwunden. Ich habe da eher den Vergleich mit kleinen 8-Bittern (Padauk, MCS-51) im Blick: Mit 8/16 Bit hat man die Möglichkeit, elegant einen einheitlichen 64KB-Adressraum zu verwenden (wie beim STM8, Z80, oder hier beim f8). Die Probleme mit unterschiedlichen Zeigertypen sind verschwunden. Klar, wenn man noch mehr Speicher braucht, wiederholt sich das gleiche Spiel mit 16/8 vs 32 Bit, und dann nochmal mit 32 Bit vs. 64 Bit. Ich sehe den Platz des f8 unterhalb von 32-Bittern wie RISC-V. Wie viel Platz es unterhalb des f8 für diskrete µC noch gibt, weiß ich nicht. Aber irgendwann lohnt es sich nicht mehr, beim Prozessor ein paar Gatter zu sparen, wenn die I/O-Pads schon die Größe des Die vorgeben. Für Softcores in FPGA sieht es da natürlich anders aus, da kann man die beim Prozessor eingesparten LUT ja immer noch anderweitig nutzen. Philipp P.S.: Beim STM8 ist das über-64KB-hinausgehen teils relativ elegant gelöst. Man kann den Code im Flash nach oben legen, und alle Daten in die unteren 64KB des Adressraums. Somit bleiben alle Objektzeiger bei 16 Bit, lediglich Funktionszeiger werden 24 Bit (so z.B. in SDCC wenn man mit -mstm8 --model-large kompiliert).
:
Bearbeitet durch User
Philipp Klaus K. schrieb: > Wie viel > Platz es unterhalb des f8 für diskrete µC noch gibt, weiß ich nicht. So sieht eine moderne MCU aus: https://cpldcpu.wordpress.com/2024/05/01/decapsulating-the-ch32v203-reveals-a-separate-flash-die/ Gerade in China gibt es gerade viele Bestrebungen, low-cost Prozesse für PMIC und MCU zu entwickeln. Dazu werden ältere Logikprozesse vereinfacht, um bei gleichbleibenden Kosten die Logikdichte zu erhöhen.
Motopick schrieb: > Auch sehr schoen beim Zilog Z8002 zu sehen. > Die ganze "Einfachheit" und "Eleganz" ist dahin, wenn man mehr > als 64 KB braucht. Die aufgebohrten MSP430 folgen da nahtlos. Ja, die Probleme starten immer, wenn man den "nativen" Addressraum überschreitet. Trotzdem scheint es immer die Tendenz zu geben, Architekturen zu nutzen, die für die aktuelle Anwendung gerade zu klein sind. z.B. einfache Sensoranwendung benötigt vielleicht 8kb Flash und 1kb Ram. Das sind typische Daten von Low-end MCUs für <0.20€. Der ADC liefert aber nun 10bit -> 8 bit Datenregister reichen nicht aus. Das Programm ist größer als 256 bytes -> 8 bit PC, SP reichen nicht aus Und vielleicht gibt es irgwendwie eine lookup table oder UART string im Flash -> 8 bit pointer reichen nicht aus. Beim AVR hat man das addressiert, in dem man viele Register eingeführt hat (32x8). Allerdings wäre die Architektur mit einer 16x16 Registerbank wahrscheinlich effizienter, da sie sowieso schon 16 bit Befehle (flash hat 16 bit datenbus) und viele 16 bit virtuelle Register nutzt. Der einzige Grund für die 8 bit besteht im geringeren Platzbedarf für den Datenpfad auf dem Chip. Das war aber vermutlich nur bei uralt-Prozessen mit >1µm wirklich ein Vorteil. Nun ja, aber man hat die 16 bit ja jetzt übersprungen und hat dafür 32 bit auch schon im low end, bis auf eine extreme ultra-low-cost Nischenprodukte. Bei denen scheinen PIC-ähnliche Architekturen aber auszureichen.
:
Bearbeitet durch User
Tim . schrieb: > Philipp Klaus K. schrieb: >> Wie viel >> Platz es unterhalb des f8 für diskrete µC noch gibt, weiß ich nicht. > > So sieht eine moderne MCU aus: > > https://cpldcpu.wordpress.com/2024/05/01/decapsulating-the-ch32v203-reveals-a-separate-flash-die/ > > Gerade in China gibt es gerade viele Bestrebungen, low-cost Prozesse für > PMIC und MCU zu entwickeln. Dazu werden ältere Logikprozesse > vereinfacht, um bei gleichbleibenden Kosten die Logikdichte zu erhöhen. Dual-Die (0,5 mm² + 1,8 mm²). Das ist was großes, nicht "unterhalb des f8", und damit auch nicht billig. Bei Padauk hat ein komplettes SoC nur 0,25 mm² bis 1 mm². Dort würde ich eigentlich gern auch mit dem f8 hinkommen.
Philipp Klaus K. schrieb: > Bei Padauk hat ein komplettes SoC nur 0,25 mm² bis 1 mm². Dort würde ich > eigentlich gern auch mit dem f8 hinkommen. Ja, bei den Padauks hat man auch viel am "analogen" Teil optimiert, um den die klein zu bekommen. (LDO, ESD, GPIO etc.) Du kannst Deine MCU ja mal mit dem flow aus TinyTapeout synthetisieren. (https://tinytapeout.com/). Der dort verwendete Prozess (180 nm FE + 130 nm BE, dual voltage) ist dem der Padauks einigermassen ähnlich (vermutlich 180nm FE+BE, single voltage 5V).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.