Forum: Projekte & Code Noch einer (f8); 8bit-Computing mit FPGA


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Philipp Klaus K. (pkk)


Lesenswert?

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
von Tim  . (cpldcpu)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

>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?

von Wf88 (wf88)


Lesenswert?

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

von Motopick (motopick)


Lesenswert?

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...

von Philipp Klaus K. (pkk)


Lesenswert?

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

von Philipp Klaus K. (pkk)


Lesenswert?

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
von Philipp Klaus K. (pkk)


Lesenswert?

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
von Motopick (motopick)


Lesenswert?

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.

von Jens K. (jensky)


Lesenswert?

Hast du dir das Bo8-Projekt mal angesehen? Warum erweiterst du dies 
nicht?

von Harald K. (kirnbichler)


Lesenswert?

Jens K. schrieb:
> Hast du dir das Bo8-Projekt mal angesehen?

Will man das wirklich?

von Motopick (motopick)


Lesenswert?

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.

von Philipp Klaus K. (pkk)


Lesenswert?

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/

von Tim  . (cpldcpu)


Lesenswert?

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.

von Philipp Klaus K. (pkk)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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
von Motopick (motopick)


Lesenswert?

(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.

von Philipp Klaus K. (pkk)


Lesenswert?

(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
von Tim  . (cpldcpu)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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
von Philipp Klaus K. (pkk)


Lesenswert?

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.

von Tim  . (cpldcpu)


Lesenswert?

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).

Bitte 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
Noch kein Account? Hier anmelden.