uxn

Forth auf Propeller, 8080, Z80, 6502, ATmega, ESPchen, FPGA, ...
Antworten
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

uxn

Beitrag von yeti »

uxn?

Die Definition dieser forth-nahen CPU schaut kompakt aus.
Ein forth for uxn virtual machine, gibt es auch.

Wegen obiger Funde erwähne ich dies in der Forth-Rubrik.

Als kompakte VM leicht zu implementieren.
In-Browser-Uxn-System fürs schnelle Antesten.
Vermutlich ein gutes Ziel im FPGA-Lernen-Kontext⁽¹⁾.
Ich bin noch unschlüssig, ob ich da Zeit reinstecken will. Schaunwermal...

Eine Liste mit mehr Links dazu: Awesome Uxn Awesome – Curated list of awesome Uxn projects from the community.

——————————
1: In der Dimension FPGA bin ich noch immer nicht weiter als bis Lauflicht und UART gekommen.
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: uxn

Beitrag von yeti »

Perspektiven

Nach ein paar Tagen mit UXN, Varvara, diversen Seiten im Netz und dem Chat hierzu ergibt sich ein gemischtes Bild.

Es wird davon geredet, ein System zu haben, das man verstehen⁽¹⁾ kann.

Die CPU (UXN) ist zu verstehen. Keine Frage! Die Peripherie des fiktiven Computers (Varvara) wird durch den Emulator implementiert. Dieser sieht ebenfalls einfach aus, solange man die Komplexität der benutzten Bibliotheken, des darunter liegenden Betriebssystemes und der Hardware des Gastgebersystemes nicht hinterfragt.

In Varvara ein Pixel oder ein ganzes Sprite auf den Bildschirm bringen ist mit wenigen UXN-Opcodes möglich. Die Arbeit macht dann z.B. SDL auf dem Gastgebersystem. Es wird also unterhalb des Emulators aufgehört zu fragen, was woher kommt oder wer was macht. Uhrzeit, Files, Filesystem, Maus, Text-/Graphik-/Audio-Ein-/Ausgabe, alles wird vom Emulator an das unterliegende System delegiert.

Vielleicht muß einfach deutlicher zwischen UXN und Varvara unterschieden werden. Ich finde UXN sehr interessant, aber möchte diese CPU in anderem Kontext als ausschließlich in Varvara sehen.

UXN zu verstehen⁽¹⁾ ist möglich.

Die CPU sieht nett aus und sollte mal in Ruhe alleine betrachtet werden. Die wenigen Opcodes arbeiten durch ein zusätzliches Bit gesteuert auf Bytes oder Words und durch ein weiteres Bit umgeschaltet auf dem Daten- oder Return-Stack. Der Befehlssatz ist bis auf minimalste Ausnahmen sehr logisch strukturiert. 32 Opcodes mal 3 Modus-Bits (das dritte dieser Bits erlaubt nicht-destruktive Stack Operationen) ergeben eine 8/16-Bit-Architektur, für die man vermutlich sogar selber Assembler spielen könnte ohne dabei an den Rand des Wahnes getrieben zu werden.

Ich kann mir vorstellen, daß UXN (z.B. in FPGA gegossen) als Microprozessor eingesetzt werden kann.

Ein Z80 mit einem Betriebssystem unter 4kBytes Größe und ein paar Peripheriechips (CTC, UART, FDC, …) ergab schon ein nettes CP/M-System. Tabellenkalkulation, Textverarbeitung, Datenbank, all das war machbar. Dies Potential kann auch in UXN stecken, wobei ich denke, daß große Teile der Peripherie von UXN selber bedient werden sollte, notfalls durch UXN in für Peripherie zuständigen Subsystemen. Also ein Schwarm aus UXN-Knoten, von denen nicht alle direkt für den Benutzer an den Tasten arbeiten, sondern viele nur indirekt.

Ein solches System könnte autark sein.

ASMA, ein auf Varvara laufender in UXNs Assembler geschiebener UXN-Assembler, ist ein greifbarer Beweis, daß eine Selbstständigkeit eines reinen UXN-Digitopes möglich ist.

Wenn 8/16-Bit doch zu wenig sind?

Vermutlich könnte man unter Beibehaltung von 8-Bit-Opcodes ein UXN16/32 definieren, indem mit dem Datenbreite-Bit zwischen 16- und 32-Bit Modus (statt 8/16) umgeschaltet wird. Eine direkte Binärcodekompatibilität wäre so nicht gegeben, aber das Umdenken zwischen UXN8/16 und UXN16/32 wäre fast kein Aufwand.

Die Struktur von UXN kann also für größere Systeme angepaßt werden, sowohl durch Einsatz mehrerer 8/16-Bit CPUs, als auch durch eine die Grundidee erhaltene Erweiterung auf eine größere Bitbreite.

Wie weiter?

Ich bin noch nicht fit genug mit Verilog, um UXN als FPGA zu realisieren.

UXN als Chip erstmal durch Microcontroller nachbilden könnte ein praktikabler nächster Schritt sein. In den typischen externen SPI-Flash-Chips mit bis zu 32MBytes wären viele komplette Speicherauszüge speicherbar, dies als einfachste Form eines Dateisystemes wäre schnell implementiert.

Eine Implementation auf einem Microcontroller mit Micropython würde eine Entwicklung ohne dauerndes Neuflashen erlauben. Per RS232, I2C und SPI adressierte Peripherie ist bei einer Entwicklung in diesem Kontext leicht erreichbar und die Kosten der Hardware sind gering.

Ist das nicht lediglich ein weiterer/alternativer Varvara?

Jein.

Ich sehe das Ziel darin, irgendwann ein reines UXN-System zu erreichen. Während die Varvara-Benutzer zusätzliche Fähigkeiten den duch den Emulator bereitgestellten Devices hinzufügen, möchte ich langfristig gesehen die Peripherie direkt durch UXN ansteuern.

[2022-02-07 Mon]

(Fortsetzung folgt?)

——————————

1: Babycastles Academy: Intro to Uxn.
Zuletzt geändert von yeti am Sa 12. Feb 2022, 16:14, insgesamt 1-mal geändert.
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: uxn

Beitrag von yeti »

Hoffentlich hat das Folgende spannende Weiterungen:

uxn-unx
This, however, poses a question yet to solve:
  • do I want an OS inside the [uxn], self-hosted and handling device access;
  • or do I want an OS outside of [varvara], where [uxn] is the only runtime and the microkernel is just juggling devices and merely VMs?
Ich beantworte das mal mit: BEIDES!

Ein kleines OS in einer UXN-CPU ist tauglich für Microcontroller und das Internet der Inge und ein Gastgebersystem für viele Varvaras ist auch interessant, da kompatibel zum aktuellen Entwicklungsstand.
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: uxn

Beitrag von yeti »

𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
thiloa
Beiträge: 37
Registriert: So 6. Okt 2019, 21:06

Re: uxn

Beitrag von thiloa »

Als Freund von Stackmaschinen habe ich mal aus Neugier in die UXN Opcodes reingeschaut. Eine Implementierung im FPGA wird relativ einfach zu bewerkstelligen sein, sofern man keine übermäßige Anforderung an die Performance stellt, d.h. 2-4 Takte pro Instruktion oder alternativ niedrige Taktraten akzeptiert. Den Divisionsbefehl wird man vermutlich per Hardware Trap / Microcode emulieren müssen, bei sehr kleinen FPGAs notfalls auch die Multiplikation/Shiftbefehl.

Das Umschalten von 8 Bit zu 16 Bit Stackoperationen ist m.E. eine Schwachstelle in dem Konzept. Ich erkenne hier keinen wirklichen Nutzen, nur eine Steigerung der Komplexität. Ich habe mir jetzt nicht alles dazu durchgelesen, gibt es dafür irgendwelche Gründe? Viele moderne Stack und Registerarchitekturen verzichten extra auf so etwas und rechnen immer mit maximaler Wortbreite. Ggf. bieten sie dann bei den Load/Store Befehlen reduzierte Wortbreiten an (siehe hierzu z.B. ZPU).

Spätestens wenn man versucht, die Architektur im FPGA auf hohe Instruktionen pro Taktzyklus zu optimieren (was wohl bei Stackarchitekturen grundsätzlich eh schon schwieriger zu sein scheint), fliegt einem das um die Ohren. Auch Intel hatte wohl mit seinen halben Registern (ax, al, ah) bei den späteren Performance Optimierungen ihrer Architektur damals heftig zu kämpfen (u.A. Partial Register Stall).

Was das Forth Konzept mit den zwei Stacks angeht, mir ist schon die Idee dahinter (und auch Vorteile) klar, aber ich konnte mich nie so recht damit anfreunden...

Was Varvara angeht: Die ganze Platform scheint sich ja auch ein wenig an Künstler oder Spielentwickler zu richten. Wenn da erst massenweise Maus, Tastatur und Dateisystem Treiber entwickelt werden müssten, dann ist die "Einfachheit" des Systems schnell dahin :)
Benutzeravatar
yeti
Beiträge: 2300
Registriert: Fr 27. Aug 2010, 14:48
Wohnort: Wrong Planet
Kontaktdaten:

Re: uxn

Beitrag von yeti »

Ich kriesele gerade etwas mit UXN. Wenn die UXNerds neue Features brauchen, steckense die in die durch den den Emulator simulierte Hardware. Beispielsweise habense grad die Art "Sprites" auf den Bildschirm zu stempeln in der im Emulator verstekten Graphikkarte verändert, das RTC-Device verschoben und ein 2tes Filedevice angelegt. Nachwievor leider ohne Möglichkeit zu Seeken. Eine Möglichkeit beide Stacks in den Haupspeicher einzublenden wird wohl auch gerade angegangen. Letzteres halte ich für dauerhaft sinnvoll, um Variablen auf dem Stack liegend adressieren zu können. Das würde lokale Variablen auf dem Stack vereinfachen, anstatt immer alles durch das TOS-Nadelöhr zu jonglieren, aber mit dieser Meinung bin ich wohl Singularität. Die Zeropage stört mich mehr als daß ich sie sinnvoll finde und auch der IO-Bereich (DEI/DEO) könnte gern 16bittig adressiert sein. Die Assembler sind nachwievor nicht der Stacksymmetrie der Opcodes gewachsen, was eine unnötige Einschränkung bedeutet und manch nette Idee/Nutzung blockiert. Auch das scheint ausschließlich mich zu stören. Ich hatte angefangen einen Assembler in AWK zu schustern, aber irgendwie ist grad die Luft raus aus dem Spatz an UXN. Alles in 16bit Breite und das freiwerdende Bit in den Opcodes für 2 weitere Stacks nutzen oder mal schauen, was man mit 64 Opcodes besser machen könnte?

Auf einer reinen Register-/Speicher-CPU würde man ganz schnell mindestens ein Register für einen Stack abstellen und die reine Stack-CPU ist mir ohne "Seiteneinblick" in den Stack auch zu eng. Indizierter Zugriff in Speicher und Stack ohne zu aufwendige Befehlsfolgen wären schon deutlich nützlicher als die Zeropage.

Vielleicht ist das gesehen zu haben schon genug Nutzen.

Jetzt erstmal etwas Abstand schaffen und dann mal schauen, ob danach ein modifiziertes UXN oder ein ganz anderer Entwurf mehr Spatz verspricht.
𝖂𝖎𝖗 𝖐𝖔̈𝖓𝖓𝖊𝖓 𝖆𝖑𝖑𝖊𝖘 𝖆𝖚𝖘𝖘𝖊𝖗 𝖎𝖓 𝕱𝖗𝖚̈𝖍𝖑𝖎𝖓𝖌, 𝕾𝖔𝖒𝖒𝖊𝖗, 𝕳𝖊𝖗𝖇𝖘𝖙 𝖚𝖓𝖉 𝖂𝖎𝖓𝖙𝖊𝖗! – 𝕯𝖊𝖚𝖙𝖘𝖈𝖍𝖑𝖆𝖓𝖉.
"Du willst hier nicht klicken. Dies interessiert Dich nicht." — Yeti.
"DNA is a four letter word!" — Yeti.
thiloa
Beiträge: 37
Registriert: So 6. Okt 2019, 21:06

Re: uxn

Beitrag von thiloa »

yeti hat geschrieben: So 3. Apr 2022, 05:41 Ich kriesele gerade etwas mit UXN. Wenn die UXNerds neue Features brauchen, steckense die in die durch den den Emulator simulierte Hardware. Beispielsweise habense grad die Art "Sprites" auf den Bildschirm zu stempeln in der im Emulator verstekten Graphikkarte verändert
Naja, wie wollte man das anders machen? Also man könnte natürlich eher so einen P1 Ansatz fahren: Die Grafikausgabe als großes Speicherarray sehen, und den Rest (Zeichen, Sprites usw.) in UXN Software rendern. Dürfte auf einem modernen PC bei den dort gestellten grafischen Ansprüchen auch hinreichend schnell gehen, bei anderen Plattformen wird das aber natürlich schnell sehr langsam, vor allem wenn man nur einen UXN CPU Kern besitzt.

Und bei Tastatur, Maus, Dateisystem und Uhr braucht man irgendeinen Abstraktionslayer, wenn man das plattformunabhängig nutzen möchte.

Was die CPU selbst angeht, hätte ich die Opcodes anders gestaltet (etwas näher am ZPU Design) und vermutlich auf 32 Bit Daten arbeitend.
Selbst die schwächeren Plattformen wie ESP32, STM32 oder Gameboy Advance auf der Varvara teilweise schon läuft unterstützen das ja nativ und ein billiger 8 Bit Atmel/PIC Controller hat de facto eh zu wenig Ram um damit etwas "sinnvolles" aufwändiges zu machen. Für eine reine Demonstration des machbaren gingen aber auch dort 32 Bit).
Eine Stack CPU ist für einfachen Compiler / Assembler aber denke ich schon das Mittel der Wahl.

Und ja die Zeropage, da gebe ich dir vollkommen recht, ist m.E. ein veraltetes Konzept aus der Akkumulator Maschinen Zeit als eine Art Registerersatz. Damit würde ich mich nicht herumschlagen wollen, vor allem wenn ich eigentlich den Komfort einer Stackmaschine habe. Besser wäre hier eine Art lokales Fenster auf dem Stack, welches ich einfach als lokale Variablen nutzen könnte. Dann könnte man mit einem guten Assembler schon fast "hochsprachenähnlich" programmieren.

Die Syntax des UXN Assemblers finde ich nur so lala. Ist aber letztendlich auch immer etwas Geschmackssache.

Insgesamt ist natürlich bei Designentscheidungen auch immer die Frage der Motivation, warum man das ganze überhaupt macht :). Ich würde diese ganzen Projekte (wie auch den HIVE) ja vor allem als eine Art Unterhaltung/Hobby/Lernprojekt sehen. Das solche Projekte auch mal kommerziell oder "praktisch" für Endanwender verwendet werden halte ich für quasi ausgeschlossen.

Ich persönlich schätze dann die Einfachheit und Überschaubarkeit eines Systems (ohne Gigabyte große OSes mit zig Abstraktionslibraries, propr. Treibern und hochkomplexen Compilern mit tausenden Mannjahren Entwicklungszeit). Die anderen Beschränkungen die man damals hatte (8 Bit, Zeropage, geringe Taktzahl, ultra wenig Ram, langsame und vor allem fehleranfällige :lol: Speichermedien) finde ich persönlich weniger reizend.


Der Hauptvorteil der UXN/Varvara Sache ist meines Erachtens vor allem, dass es dort schon ein paar Leute gibt, die daran entwickeln, man hat also schon eine kleine Community und ist nicht als Einzelgänger unterwegs. Das ist bei meinen Projekten die ich privat mache immer so ein kleines Problem :shock:
Antworten