Wahrscheinlich ist FORTH ein ziemlich exotisches Thema hier, aber ich probiere es trotzdem mal:
Für graphische Anwendungen wäre ein objektorientiertes Forth nicht schlecht.
Einen Grundlagenartikel zu einer Form der Objektorientierung gibt es hier: https://vfxforth.com/flag/jfar/vol3/no3/article3.pdf
Und deine Frage ist jetzt?
Es scheint so zu sein, dass es keinen Standard für ein objekorientiertes Forth gibt. Der Syntax im geposteten Artikel-Link oben und im Link zur Uni-Wien ist unterschiedlich.
Ich will ein einfache Möglichkeit, Objekte schnell zu definieren und darzustellen, wie z.B.
Diese Stack-Orientierung mit UPN muß man aber wirklich mögen und wollen...
Ich hielt Forth immer für ein Relikt aus den Anfängen der Computerei, aus der Not der Ressourcenknappheit auf den damaligen Systemen heraus geboren.
Hätte nicht gedacht, daß sich heute noch Jemand damit beschäftigt.
Das war damals (1983) schon sehr progressiv, denk auch an Smalltalk (die beruehmte Implementierung Smalltalk-80) oder auch Lisp (Emacs, auch ca. 1980). Die RPN (reverse polish notation) fand ich schon damals antiquiert, aber viele Ingenieure schworen darauf (der Uebergang vom Rechenschieber zum Taschenrechner war wohl traumatisch fuer sie).
Heute ist es natuerlich schoen, dass Du fuer sehr wenig Geld (und elektrische Leistung) Rechenleistung und Speicherplatz bekommst von denen man damals noch nicht einmal Traeumen konnte.
Weisst Du ob es ein Entwicklungssystem fuer Forth gibt?
Müsste schon irgendwann in den Siebzigern gewesen sein. Ich habe hier noch ein deutsches Forth Handbuch von 1982 liegen (E.Floegel).
Auch damals lagen wir schon ein Jahrzehnt mit solchen Dingen zurück.
Im Übrigen würde ich sagen, Forth ist das Entwicklungssystem.
Und so kann man's bekommen:
Und deine Frage ist jetzt?
Es scheint so zu sein, dass es keinen Standard für ein objekorientiertes
Forth gibt. Der Syntax im geposteten Artikel-Link oben und im Link zur
Uni-Wien ist unterschiedlich.
Es gibt kein Forth Standard. Es gibt ein paar Standard-Token, aber schon die Ausgabe ist implementierungsabhaengig. Und dann kannst Du eigene Dictionaries definieren. It's the beauty of it.
Wahrscheinlich ist FORTH ein ziemlich exotisches Thema hier, aber ich
probiere es trotzdem mal:
Mein erster Computer* wurde in Forth programmiert. Ein graphikorientiertes Forth hab' ich dann auch noch auf einem anderen Computer ausprobiert ... und das hat mir als Begegnung mit dieser Write-Only-Sprache völlig gereicht.
Wenn man mit einem HP-Taschenrechner sozialisiert wird, also die Gehirnwindungen früh genug entsprechend verbogen werden, kommt man mit stackorientierten Programmiersprachen sicherlich bestens zurecht und kann beispielsweise auch in PostScript tolle Dinge anstellen.
Wenn aber nicht ...
<Pedanterie> Syntax ist weiblich. </Pedanterie>
*) Jupiter ACE. Z80, 3 kB RAM, davon grob 900 Byte für Programme und Daten nutzbar. Forth-Interpreter in 8 kB ROM, der Quelltext gleich in Tokens übersetzte (und damit mit 900 Byte doch etwas mehr möglich machte als ein simples "hello world").
Ich habe ja nun wirklich keine Ahnung von Forth, aber das, was die da
schreiben, klingt ziemlich sinnvoll:
Now we can create a circle on the heap (i.e., allocated memory) with:
Ah, jetzt ist es klarer.
Ich hätte gerne so einen Syntax:
1
20 10 "mytext" textoutput
2
"hallo" mytext
3
10 delay
4
"nix" mytext
Das soll ein Text-Output Object an der Position 20,10 kreieren und dann erst "hallo" und danach "nix" dahin schreiben. Was haltet ihr von diesem Syntax?
Deine Entscheidung. Wenn die Forth Syntax und Semantik deines Forth es her geben bau es dir genau so. Du bist dein eigener König in deinem eigenen Forth-Königreich.
Das war in Forth schon immer so. Zuerst baut man sich eine DSL, mit der DSL löst man sein Problem.
Das war in Forth schon immer so. Zuerst baut man sich eine DSL, mit der
DSL löst man sein Problem.
Das ist für viele, die in Forth reinschnuppern anfangs recht verstörend, ebenso wie die UPN.
Einer meiner Ausbilder sagte mal recht salopp:
In anderen Sprachen (er meinte in Hauptsache C und Pascal) muss man das "Problem" solange modifizieren und beschneiden, bis man es in der Sprache abfassen kann.
In Forth verändert man die Sprache solange, bis sie die Problemstellung vollständig widerspiegelt.
In anderen Sprachen fügt man einfach eine neue Funktion hinzu, zum Beispiel zum Zeichen eines Kreises. Wenn das in Forth bereits als Spracherweiterung gilt, dann sieht man daran die "Höhe" dieser Hochsprache.
Deine Entscheidung. Wenn die Forth Syntax und Semantik deines Forth es
her geben bau es dir genau so. Du bist dein eigener König in deinem
eigenen Forth-Königreich.
Ich denke, du liegst falsch. Schau dir den Syntax meines Beispiels noch mal genau an.
Deine Entscheidung. Wenn die Forth Syntax und Semantik deines Forth es
her geben bau es dir genau so. Du bist dein eigener König in deinem
eigenen Forth-Königreich.
Ich denke, du liegst falsch. Schau dir den Syntax meines Beispiels noch
mal genau an.
Wie? Ich liege falsch dass das deine Entscheidung ist? Na dann, wessen Entscheidung soll es denn sein? Ach egal, wenn du nicht machen willst was du selber willst dann lass es halt.
In anderen Sprachen fügt man einfach eine neue Funktion hinzu, zum
Beispiel zum Zeichen eines Kreises.
In den anderen Sprachen ist exakt definiert, wie eine Funktion aufgebaut wird, wie Anweisungen auszusehen haben.
C hat irgendwas um Hundert Schlüsselworte.
Rigide Syntaxregeln.
Forth hat nichts davon.
Forth kennt nur Worte.
Diese Worte werden (meist) durch Whitespaces voneinander getrennt.
Das war es schon an Syntaxregeln.
Jedes Wort ist jederzeit redefinierbar, also auch mitten im laufendem Betrieb.
Also, ja, es wird die Sprache selber verändert. Das ist das normale Vorgehen wenn man mit einem Forth System arbeitet. z.B. das hinzufügen von spezialisierten Compilern und Interpretern.
Der Streit ob Forth nun eine Hochsprache ist, wird seit Jahrzehnten geführt.
Ich sage:
Der Punkt ist falsch, die Frage ist falsch, der Gedanke ist falsch, die Annahme ist falsch.
Forth ist eher eine Philosophie, als eine Sprache.
Forth ist eher ein System, als eine Sprache.
Ja!
Das ist ein Projekt.
Glaube auch nicht, dass das es jeder bis in die Komfortzone schafft.
Vorbildung in anderen Sprachen dürfte da eher hinderlich, als hilfreich, sein
Glaube auch nicht, dass das es jeder bis in die Komfortzone schafft.
Nachdem die Sprache im Pleistozän der Programmiersprachen ersonnen wurde, und seit dem ein scheintotes Dasein fristet, wirds wohl überhaupt niemand überhaupt versuchen.
Da standen 2 Fragen!
Auf eine kann ich eine positive Antwort liefern.
Übrigens:
Meine Antwort schließt auch das Pico2_LCD_096 ein, wenn es mal in meine Hände kommt.
Aber das hast du ja nicht gefragt und offensichtlich nicht verstanden
Um noch einmal zum Thread-Thema zurück zu kommen, ich halte eine Objekt-orientierte Erweiterung dieser Sprache im besten Falle für einen akademischen /Brainfart/.
Forth ist niemals für so etwas konzipiert worden. Manchmal sollte man die Dinge einfach so belassen (und benutzen) wie sie erdacht worden sind und sie nicht in maximal unpassende Gewänder zwängen.
Mir jedenfalls graust es bei dem Gedanken, ein ++ an den Namen gehängt zu sehen. Welch hässlichen Dinge so etwas nach sich zieht, kann man ja seit vielen Jahren sehen.
Um noch einmal zum Thread-Thema zurück zu kommen, ich halte eine
Objekt-orientierte Erweiterung dieser Sprache im besten Falle für einen
akademischen Brainfart.
Mir geht es nur indirekt um FORTH. Ich hätte nur gerne die Bequemlichkeit von FORTH schnell eigene Definitionen zu erzeugen, wie oben schon beschrieben:
1
20 10 "mytext" textoutput
2
"hallo" mytext
3
10 delay
4
"nix" mytext
Ich überlege gerade, einen kleinen Interpreter in Micropython (bzw. Circuitpython, das gibt es für das Board https://circuitpython.org/board/waveshare_rp2350_lcd_0_96/
der das Script oben versteht )
Vielleicht sollte man einen Micropython/Circuitpython Thread für das Board aufmachen.
Um noch einmal zum Thread-Thema zurück zu kommen, ich halte eine
Objekt-orientierte Erweiterung dieser Sprache im besten Falle für einen
akademischen Brainfart.
Der Zweck, womit sich manche Forschenden beschäftigen, ist auch manchmal etwas zweifelhaft.
Ein Prof von mir (über 20 Jahre her) hat auch noch in einer Sprache programmiert, die damals schon nicht mehr geschult wurde.
Mir geht es nur indirekt um FORTH. Ich hätte nur gerne die
Bequemlichkeit von FORTH schnell eigene Definitionen zu erzeugen, wie
oben schon beschrieben:
1
20 10 "mytext" textoutput
2
> "hallo" mytext
3
> 10 delay
4
> "nix" mytext
Du möchtest Postscript.
Gibt's das eigentlich für irgendeinen uC?
Ich habe präzise einmal Zirkuspython ausprobiert und es für noch nicht einmal halbwegs sinnvoll einsetzbar befunden. Selbst das Attribut Kinderspielzeug wäre noch ein Euphemismus.
Manchmal ist es in der Tat besser, wenn man nicht versuchte tausend Dinge besonders schlecht zu machen, sondern lieber nur hundert Dinge, dafür gut.
Normales MicroPython und ein Hand-gedengeltes module wäre meine Wahl. Hab' vor Jahren mal eines für ein ST7735 1,8" TFT geschrieben. Hat einen Tag gedauert. Inklusive Optimierung.
Normales MicroPython und ein Hand-gedengeltes module wäre meine Wahl.
Hab' vor Jahren mal eines für ein ST7735 1,8" TFT geschrieben. Hat einen
Tag gedauert. Inklusive Optimierung.
Ich wollte jetzt eigentlich kein Forschungsprojekt zu diesem Display-Board starten. Das ist eine kleine Nebenspielerei und der Plan war, einen Text in unterschiedlichen Größen an unterschiedliche Positionen anhand eines Beispiels zu schreiben.
Normales MicroPython und ein Hand-gedengeltes module wäre meine Wahl.
Hab' vor Jahren mal eines für ein ST7735 1,8" TFT geschrieben. Hat einen
Tag gedauert. Inklusive Optimierung.
Ich wollte jetzt eigentlich kein Forschungsprojekt zu diesem
Display-Board starten. Das ist eine kleine Nebenspielerei und der Plan
war, einen Text in unterschiedlichen Größen an unterschiedliche
Positionen anhand eines Beispiels zu schreiben.
Abhängig vom verwendeten Controller hat ja vielleicht schon jemand einen zumindest rudimentären Treiber gedengelt.
Schau mal bei:https://awesome-micropython.com/
Die Liste würde sehr lang werden!
Hauptsächlich programmiere ich in Assembler verschiedene Architekturen. Vom Z80, Z8 über 8086 und 8051 sowie PIC, AVR.
Hochsprachen - je nach Anwendung vom BASIC in verschiedenen Ausführungen über TurboPascal, DBase, Foxbase-Foxpro-Visual Foxpro, C, und natürlich Forth mit Z8, Z80, 8051, PC.
Ich habe bestimmt noch Etliches vergessen?
P.S. Focal
Ich frage mich was immer neue Sprachen bringen sollen. Lernen muss man doch jede neu und egal wie einfach sie zu sein scheint. Assembler ist sicher nicht das, was ich heute empfehlen würde, aber C ganz sicher. Und mit C++ ist man auch gut dabei.
Ich mache das Wenige mit Arduino, weil ich auch bei diesen Controllern bleibe. Und wenn, dann mache ich auch nichts Bewegendes mehr.
Soll ja jeder gerne alles lernen, aber ich persönlich würde dann z.B. lieber so gut wie nur irgendwie möglich C lernen. Das ist die Hochsprache, die auf so ziemlich jeden Mikrocontroller funktionieren wird.
Ich frage mich was immer neue Sprachen bringen sollen.
Forth ist ja nun nicht besonders neu.
Bei C muss man sich um viele Dinge selber kümmern, und es hat teilweise gewöhnungsbedürftige Syntax (Pointer- und Stringoperationen).
python erzeiht wenigstens dazu, Quellcode strukturiert zu formatieren.
Welchen Vorteil Ajax gegenüber JS bietet, weiß ich auch noch nicht.
Assembler ist
sicher nicht das, was ich heute empfehlen würde, aber C ganz sicher.
Und mit C++ ist man auch gut dabei.
Assembler funktioniert nicht plattformübergreifend. Hochsprachen schon eher.
Ich mache das Wenige mit Arduino, weil ich auch bei diesen Controllern
bleibe. Und wenn, dann mache ich auch nichts Bewegendes mehr.
Arduino ist nur eine Entwicklungsumgebung mit der Zielsetzung eine Programmiersprache für viele Controller zu haben.
Man kann mit dem Code für einen 8-Bit AVR genauso programmieren, wie einen ESP32. (unter Beachtung gewisser Abweichungen). Z.B. wird mit "Serial.begin()" bei beiden die Standard-UART-Schnittstelle initialisiert).
Soll ja jeder gerne alles lernen, aber ich persönlich würde dann z.B.
lieber so gut wie nur irgendwie möglich C lernen. Das ist die
Hochsprache, die auf so ziemlich jeden Mikrocontroller funktionieren
wird.
Mir ist kein halbwegs verbreiteter Prozessor bekannt, für den es keinen
C-Compiler gibt.
Das ist ja schön.
Mir fällt auch keiner ein. Das liegt aber wohl eher daran, dass mein Controller-Spektrum relativ begrenzt ist.
Wenn ich in der Vergangenheit wühle, konnte vor 30 Jahren gewisse (verbreitete) PICs nur in Assembler programmieren.
Wäre es nicht sinnvoller zuerst ein TextOutput Object zu erzeugen (wenn man es objectorientiert machen will).
Dann das Objekt zu positionieren,ggf. sichtbar zumachen, und erst zum Schluß Text anzuzeigen?
Wenn Du nämlich viele TextOutput Objekte anlegen musst, dann haben die ja u.U. noch gar keine festgelegte Position.
Wäre es nicht sinnvoller zuerst ein TextOutput Object zu erzeugen (wenn
man es objectorientiert machen will).
Vielleicht ist der Code doch etwas missverständlich, den ich hingeschrieben habe.
Ich versuche es mal genauer am "use case" zu erklären: Oft hat man auf dem Bildschirm analoge Werte, die man anzeigen will. Am besten schreibt man einen Namen davor, dass man weiß, was der Wert bedeutet und im besten Fall noch eine Einheit dahinter. Man muss eigentlich am Anfang nur das Objekt mit Namen, Position und eventuell Einheit auf dem Bildschirm erzeugen. Später braucht man an das Objekt eigentlich nur noch periodisch den neuen analogen Wert zu schicken.
So ähnlich wie in dem Bild: https://www.mikrocontroller.net/attachment/681824/PiPicoLcd96_Voltmeter.png
Nunja, man kann sicher auch eine Klobürste zum Zähneputzen verwenden. Aber die Handhabung ist doch etwas haklig und der Erfolg bezüglich der Aufgabe doch eher suboptimal.
Man könnte auch Postscript nehmen, dann hat man ne
forth-ähnliche Sprache zur Grafikprogrammierung zur
Verfügung.
Gibt es da ein Interpreter oder Compiler im
Mikrocontroller-Bereich?
Gibt es da ein Interpreter oder Compiler im
Mikrocontroller-Bereich?
Du könntest versuchen, Ghostscript zu portieren. Das stammt aus Zeiten, zu denen PCs so viel Rechenleistung hatten wie ein mittlerer ARM-Cortex; außerdem steckt ein Postscript-Interpreter seit Jahrzehnten in jedem etwas besseren Drucker drin - und auch da ist da, was da als Prozessor werkelt, nicht irrwitzig leistungsfähig.
Ein 8-Bit-AVR oder ähnliches dürfte allerdings unter der Latte durchgesprungen sein, ein paar hundert kByte RAM dürften schon nötig sein.
Ghostscript gab es auch für DOS, d.h. ein 16-Bit-System mit -genau- ein paar hundert kByte RAM.
Du könntest Dir aber auch ein CYD besorgen und darauf z.B. "Display PostScript" portieren.
Das ist sicherlich mühsam, aber ... wer Forth(ähnlich) programmieren will, der scheut keine Mühen, oder?
Gibt es da ein Interpreter oder Compiler im
Mikrocontroller-Bereich?
Du könntest versuchen, Ghostscript zu portieren. Das stammt aus Zeiten,
zu denen PCs so viel Rechenleistung hatten wie ein mittlerer ARM-Cortex;
außerdem steckt ein Postscript-Interpreter seit Jahrzehnten in jedem
etwas besseren Drucker drin - und auch da ist da, was da als Prozessor
werkelt, nicht irrwitzig leistungsfähig.
Jep. Man sehe sich z.B. das anhängende Postscript "Programm" an. Das erzeugt ein IFS-Fraktal[1], den Barnsley Farn. So genannt weil es von Michael F. Barnsley als Beispiel für ein natürliches Objekt mit näherungsweise fraktaler Struktur benannt wurde.
Auf einem PC mit Ghostscript rendert das in Sekunden, während ein Drucker mit eingebautem Postscript-Interpreter für ein paar Minuten in Tiefschlaf versinkt.
Auf einem PC mit Ghostscript rendert das in Sekunden, während ein
Drucker mit eingebautem Postscript-Interpreter für ein paar Minuten in
Tiefschlaf versinkt.
Naja, kommt a) auf den Drucker und b) dessen Auflösung an - ein typischer 600-DPI-Drucker hat eine ganz erheblich größere zu bearbeitende "Bildschirmfläche" als die, mit der GS für den PC-Monitor rendert.
Eine A4-Seite (abgerundet auf 8x11") mit 600 Dpi hat eine Auflösung von 4800 x 6600 Pixeln ... da ist natürlich ein Drucker 'ne Weile lang mit beschäftigt.
Wenn man aber die Ausgabeauflösung z.B. auf die des CYD beschränkt (320x200 oder so), dann dürfte die Wartezeit nicht mehr ganz so elendiglich lange sein.
Die RPN (reverse polish notation) fand ich schon damals
antiquiert, aber viele Ingenieure schworen darauf (der Uebergang vom
Rechenschieber zum Taschenrechner war wohl traumatisch fuer sie).
Wow, ich bin erstaunt, dass es jetzt doch eine ganze Reihe nützlicher, kompetenter Beiträge gab. Ich wollte den Thread ja schon aufgeben.
Danke :-)
Lotta schrieb
Man könnte auch Postscript nehmen,
Axel S. (a-za-z0-9)
farn.ps (1,22 KB)
Das Postscript Forth-artig ist, wusste ich nicht, ist aber sehr interessant. Es scheint also so zu sein, dass der ursprünglicher Gedanke, FORTH für graphische Elemente zu verwenden, schon sehr lange gemacht wurde.
1
Design:
2
The original PostScript was written for printing, with the model being that only one document could be printed at one time, and that the document was broken into logical sections approximating a page. For this reason, the underlying model of PS was based on a stack machine similar to the Forth programming language, which reduced the complexity of the code on the printer and the amount of memory needed to store individual graphics.
Ich meine gehört zu haben, dass die Nextion-Display auch mit einem speziellen Forth-Prozessor ( J1 ) laufen.
Es ist interessant, was Perplexity zur Objektorientierung von Postscript meint
1
PostScript is not natively an object-oriented programming language, but it is a stack-based, interpreted language with many high-level features. It supports procedures and modular programming but does not inherently provide built-in object-oriented constructs like classes and inheritance. However, PostScript’s flexible dictionary structures and procedures allow programmers to simulate object-oriented principles, such as encapsulation and dynamic dispatch, through custom coding techniques. Notably, extensions and environments like Sun's NeWS demonstrated how PostScript dictionaries could be used to create a dynamically-bound object-oriented runtime environment inspired by Smalltalk concepts.
Das hört sich für mich so ähnlich an, wie Strukturen in C die man dort manchmal auch für Objekte verwendet.
Und warum muss es unbedingt objektorientiert sein?
Die meisten gängigen Grafikbibliotheken (nicht zu verwechseln mit
GUI-Framwworks) sind es höchstens ansatzweise. Oft sind zwar das
Drawable und der Graphics-Context Objekte im Sinne der OOP, nicht aber
die Grafikprimitive (Linie, Polygon, Kreis usw.).
Zum Thema PostScript:
Während das klassische PostScript für Drucker nach wie vor eine gewisse
Bedeutung als herstellerübergreifende Grafiksprache für Drucker hat, ist
Display PostScript längst gestorben. Die meisten der Gründe, warum es
damals eingeführt wurde, sind heute nicht mehr relevant, dafür treten
seine Nachteile (vor allem die geringe Ausführungsgeschwindigkeit wegen
des Interpreters) mehr und mehr in den Vordergrund.
Geht es dir bei der Kombination von Forth mit Objektorientierung nur um
den Erkenntnisgewinn, oder versprichst du dir konkrete Vorteile davon?
Sagen wir mal, es ist reines spielerisches Interesse.
Für den RP2{04,35}0 ist ja eine ganze Reihe von Programmiersprachen
verfügbar:
Für den PiPico2 (also RP2350), der auf diesem Display-Board verbaut ist, habe ich kein uf2-File gefunden.
Der nächste Aufwand wäre dann, einen Display-Treiber für das Board zu schreiben. Da bin ich mir nicht sicher, ob sicher der Aufwand lohnt.
Harte Kost, aber sehr interessant. Das Konzept der Befehle auf dem Stack hat mich an Python erinnert. Und tatsächlich: Python wird auf einer Byte-Code Stackmaschine ausgeführt. Die scheint ihre Ursprünge in Forth zu haben, allerdings mit der starken Erweiterung das die Daten Objekte sind.
Was die OOP betrifft, ist das m.E. ja nur eine andere Schreibweise für
den Quellcode. Ist halt dafür gedacht, zusammengehörige Dinge zu kapseln,
um die Lesbarkeit und Wartbarkeit zu erhöhen. Anders, wie bei Strukturen
können da dann auch Prozeduren/Funktionen (Methoden) zu den Variablen
(Eigenschaften) dazu geschrieben werden. Also :
Damit macht es dann erst richtig Sinn.
Was da zum Schluß als eine vom Compiler erzeugte Binary rauskommt,
egal ob bei prozeduraler oder OOP - Programmierung, dürfte es da
kaum Unterschiede geben. Der Compiler muß das ja auch wieder in Adressen
und Sprünge zurück verwurschteln. Ein Prozessor, egal ob Mikro oder
normaler PC, kennt kein OOP. Da wird es wohl eher kein Geschwindigkeits-
gewinn geben, eher das Gegenteil. Kommt dann darauf an, wie gut der
Compiler das zurück übersetzt.
Also, bei großen Projekten, wo Teams zusammenarbeiten und auf gemeinsame
Klassen zugreifen müssen, ist es halt interessant. Bei kleineren Sachen
sehe ich da kein großer Vorteil.
So mal meine Ansicht darüber.
Gibt es da ein Interpreter oder Compiler im
Mikrocontroller-Bereich?
Nimm halt irgendein (ur)aelteres ghostscript (als src) und einen c-compiler fuer den Mikrocontroller und bau's dir selber...
Vor 1000 Jahren habbich das mal mittels turbo-c fuer einen sehr speziellen Siemens-PC mit 80186 Prozessor gemacht.
Geht es dir bei der Kombination von Forth mit Objektorientierung nur um
den Erkenntnisgewinn, oder versprichst du dir konkrete Vorteile davon?
Er will gar nichts machen außer hier rum jammern. In der Woche in der er hier rum jammert hätte er mehrere existierende OO-Erweiterungen ausprobieren und sogar anfangen können seine angeblich gesuchte sehr spezielle OO-Erweiterung selber zu implementieren. Wie man das in Forth halt so macht.
Aber er ist schon patzig geworden als ihm gesagt wurde das es seine Entscheidung ist was er wie macht. Das hat er so gar nicht verarbeiten können. Er? Was machen? Um Himmelswillen.
Harte Kost, aber sehr interessant. Das Konzept der Befehle auf dem Stack
hat mich an Python erinnert. Und tatsächlich: Python wird auf einer
Byte-Code Stackmaschine ausgeführt. Die scheint ihre Ursprünge in Forth
zu haben, allerdings mit der starken Erweiterung das die Daten Objekte
sind.
Falsche Baustelle. Die OO macht der Compiler und nicht die Bytecode Ausführungsebene. Ein Prozessor ist ja am Ende auch nichts anderes. Nur daß man den "Bytecode" dann eben "Maschinensprache" nennt. Trotzdem kann er Programme ausführen, die in einer OO-Sprache geschrieben sind. Der Prozessor muß dazu nichts von Kapselung und Methoden wissen. Eine Methode ist am Ende des Tages auch nur eine Subroutine.
Das Konzept der Befehle auf dem Stack
hat mich an Python erinnert
Axel S. (a-za-z0-9)
Falsche Baustelle.
Nein, das ist schon die richtige Baustelle. Es ging mir darum aufzuzeigen, dass auf der unteren Ebene der modernen Programmiersprache Python ein VM arbeitet, welche die Konzepte von Forth übernommen und stark erweitert hat.
Nein, das ist schon die richtige Baustelle. Es ging mir darum
aufzuzeigen, dass auf der unteren Ebene der modernen Programmiersprache
Python ein VM arbeitet, welche die Konzepte von Forth übernommen und
stark erweitert hat.
Es gibt auch hier im Hause ein Custom-Design, was Python-Bytecode direkt in Maschinensprache eine harten Stack-Maschine umsetzt - mit Einschraenkungen bei den Datentypen. Ist alles nicht sooo neu, das einzig 'heisse' daran ist, dass es auf dem FPGA wahlweise auf einer CPU oder als eigenstaendiger Hardware-Sequenzer ablaeuft und die Grenzen zwischen HW und SW komplett verschwimmen. Da liegt wohl die Zukunft.
Wenn es um akademischen Spass geht, wuerde ich vernuenftige OO nicht auf dem Level von Forth miteinander kombinieren wollen. Aber eine super-kompakte Implementierung von Display-Postscript in Forth-Bytecode haette durchaus Nerd-Faktor.
Für graphische Anwendungen wäre ein objektorientiertes Forth nicht
schlecht.
Ich wette in der Hölle programmiert man grafische Anwendungen mit
objektorientiertem Forth.
Dazu haben die gar keine Zeit.
Die werden dort festgebunden und mit hochgeklebten Augenliedern dazu gezwungen, in einer Endlosschleife deine Posts zu lesen.
Dazu haben die gar keine Zeit.
Die werden dort festgebunden und mit hochgeklebten Augenliedern dazu
gezwungen, in einer Endlosschleife deine Posts zu lesen.
Ich komme mit Komplimenten ja sowieso schon schlecht klar aber DAS ist wirklich das netteste was mir seit langem gesagt wurde. Mir wird ganz anders...
Ich wette in der Hölle programmiert man grafische Anwendungen mit
objektorientiertem Forth.
Ich erkläre es dir mal, wie man es einem kleinen Kind erklären müsste:
Menschen haben Gehirn.
Manche Hirne können die Forth Denke.
Manche können die OO Denke.
Soweit alles gut und schön!
Jetzt zur "Hölle":
Es gibt Leute, welche zwar, dank hinreichend Hirn, programmieren können, aber nicht mit 2 und 3 klar kommen (wollen?).
Für diese, muss OO-Forth die Hölle sein.
Andere, die 2 und 3 haben, können damit durchaus glücklich werden.
Auch wenn dir das nicht schmeckt.
Falsche Baustelle. Die OO macht der Compiler und nicht die Bytecode
Ausführungsebene.
Bei genauerer Betrachtung ist das für die Python-Bytecodemaschine falsch: Dort sind alle Daten Objekte und die Operatoren sind polymorph, wie man mit Hilfe des Python-Byte-Code-Disassemblers sehen kann.
Du weist schon, dass die genannte Hölle nur eine Projektion ist, oder?
Was wäre bei "oder" der Fall?
Ich sage auch, dass es am Karma eines Fußballfans liegt, wenn er im Stadion war und seine Mannschaft mal wieder verloren hat - wenn er mal nicht da war, hat sie gewonnen.
Das ist aber einfach nur ein blöder Spruch (eine meiner besonders ausgeprägten Fähigkeiten).
Bei genauerer Betrachtung ist das für die Python-Bytecodemaschine
falsch: Dort sind alle Daten Objekte und die Operatoren sind polymorph,
wie man mit Hilfe des Python-Byte-Code-Disassemblers sehen kann.
Super, dann hast du jetzt ja dein Ziel erreicht:
Python-Bytecode erlaubt OOP.
Python-Bytecode erzeugt Forth-Feeling.
Das Ganze läuft auf dem von dir anvisierten Waveshare-RP2350-Board.
Alle deine Wünsche sind damit erfüllt, aber damit nicht genug:
Das GUI-Framework LVGL inkl. dem Treiber für das 0,96"-Display ist
ready-to-use verfügbar.
Du hast Zugriff auf eine Vielzahl weiterer Python-Module.
Du musst nur noch beachten, das der MicroPython-Bytecode etwas anders
aussieht als der gewöhnliche Python-Bytecode.
Bis heute Abend zeigst du uns sicher ein in MicroPython-Bytecode
programmiertes "Hello World" auf dem Display.
Nächste Woche kommt dann die Killer-Applikation, die selbst den letzten
Zweifler davon überzeugt, dass stackorientierte Programmierung in
Verbindung mit OOP alles in den Schatten stellt, was es bisher an
Programmiertechniken gab.
Ich wette in der Hölle programmiert man grafische Anwendungen mit
objektorientiertem Forth.
Kommt ein Programmierer in die Hölle, dort gibt es Sektempfang und jede Menge Partys. Fragt er erstaunt ist das wirklich die Hölle ? Aber klar doch und alles kostenlos. Nach ein paar Tagen bemerkt er das einige manchmal durch ein Loch am Ende der Hölle starren. Durch das Loch sieht er schreiende brennende Menschen die dort auf glühenden Kohlen herumspringen. Fragt er wieder jemand was dort los ist. Antwort: Das sind die Forth Programmierer, die brauchen das ;-)
Du hast dich also innerhalb weniger Stunden in den MicroPython-Bytecode
eingearbeitet und darin ein Programm geschrieben, das einen Text auf dem
LCD ausgibt?
Nein, natürlich nicht.
Du hast basierend auf den Modulen LCD_0inch96, framebuf, writer,
freesans20 usw. ein Python-Programm namens helloYalu.py geschrieben,
dieses dieses durch den Compiler geschickt und von dessen Output einen
Hexdump erstellt.
Die von dir propagierte Forth- bzw. Forth-ähnliche Programmierung, die
ja prinzipiell mit MicroPython-Bytecode möglich ist, scheint wohl doch
nicht so der große Bringer zu sein. Stattdessen lässt du dir den
stackorientierten Code lieber automatisch generieren, nämlich vom
Python-Compiler.
Das haben viele Leute vor dir auch schon erkannt, deswegen verwenden sie
gleich Python und freuen sich, nicht mit der UPN-Programmierung auf
Bytecode-Ebene in Berührung zu kommen :)
Du hast basierend auf den Modulen LCD_0inch96, framebuf, writer,
freesans20 usw. ein Python-Programm namens helloYalu.py geschrieben,
dieses dieses durch den Compiler geschickt und von dessen Output einen
Hexdump erstellt.
Gratulation ;-)
Bleibt die spannende Frage, wie habe ich es erzeugt und kann man es de-compilieren und den Quellcode wieder herstellen.
Danke für den Link.
In den Anfängen der J1 gab es ein Paper und ein Forth-System dazu. Weil das Konzept aus einem minimalen Befehlssatz mit minimalen Hardwareresourcen ein ganzes System aufzubauen so elegant ist, hatte ich mir dieses als Vorlage für eine eigen VM genommen und den passenden Forth Compiler dazu gebaut, um ein wenig mit optimierten Befehlssätzen zu spielen.
Es gab damals den Hinweis, dass die J1 im Nextion-Display eingebaut ist, aber so richtig glauben konnte ich das nicht, da ja Forth doch eine bestimmte spezialisierte Expertise erfordert.
Mit dem Hinweis von Lotta zu Postscript wird der Zusammenhang aber klarer: Traditionell war Forth über Postscript wohl immer schon mit graphischen Anwendungen verknüpft. Da lag der Gedanke bei Nextion wohl nahe, eine Forth-CPU für ihre Displays zu verwenden.
Die Entwicklung eines eigenen Silizium im Consumer-Markt lohnt sich eigentlich nur, wenn man Absatzzahlen im Millionenstückbereich erwartet. Die J1 bietet hier minimale Chipfläche und maximale Codedichte und keine Lizenzkosten. Heutzutage würde man vielleicht Richtung RISC-V tendieren, allerdings dürfte es schwierig werden, mit einem vom C-Compiler erzeugten RISC-V Code die selbe Dichte zu erreichen.
Die Entwicklung eines eigenen Silizium im Consumer-Markt lohnt sich
eigentlich nur, wenn man Absatzzahlen im Millionenstückbereich erwartet.
Die J1 bietet hier minimale Chipfläche und maximale Codedichte und keine
Lizenzkosten. Heutzutage würde man vielleicht Richtung RISC-V tendieren,
allerdings dürfte es schwierig werden, mit einem vom C-Compiler
erzeugten RISC-V Code die selbe Dichte zu erreichen.
Man muss das Silizium ja nicht direkt entwickeln. Auch in Handies fanden sich schon FPGAs... (Stichwort Consumer).
Die Code-Dichte von RISC-V 32c ist eigentlich nicht so uebel, aber grundsaetzlich krankt die Architektur daran, dass man nicht so richtig von der MIPS-Schule weggekommen ist.
Bei der Siliziumdichte sieht's dann verglichen mit Stackmaschinen mies aus.
Der Punkt ist halt schlussendlich in der klassischen embedded Entwicklung der: GCC oder nicht GCC (oder dito LLVM). GCC ist aber klar auf Registermaschinen ausgelegt und 'kennt' die Forth-Denke nicht. Also bleibt praktisch gesehen Forth nur noch allenfalls fuer paralleles Multiprozessing in einer gewissen Nische uebrig, wo man mit C sowieso nicht weiterkommt, resp. sich der Standard (Safety) nach minimierter Logik richtet.
Da man aus Python aber so ziemlich alles zwischen Hardware bis Stack-Maschinencode generieren kann, und die OO da eigentlich ziemlich vorbildlich funktioniert, stellt sich schon die Frage fuers Engineering: Warum Forth, wenn es einen gut lesbaren de-fakto Standard gibt.
Da man aus Python aber so ziemlich alles zwischen Hardware bis
Stack-Maschinencode generieren kann,
Apropos: Gibt es eine für Python optimierte FPGA-CPU?
Bei Linux kann man einfach das *.ps File anklicken und es wird automatisch dargestellt. Wenn man es editiert, wird das geöffnete Bild auch jeweils sofort aktualisiert.
Da das Display aber nur 160x80 Zeichen hat und die Seite aber eher so was wie ein DIN-A4 Format hat, wird das Bild nur im unteren linken Eck dargestellt ( siehe Anhang ). Besser wäre es, wenn die Postscriptseite das gleiche Format wie das Display hätte. Kann man das einstellen?
1
%!PS
2
3
000setrgbcolor% Set color to black
4
0016080rectfill% Draw a filled rectangle covering the page
5
6
111setrgbcolor
7
newpath% Start a new path
8
00moveto% Move to the start point (x=100, y=100)
9
10080lineto% Draw a line to the end point (x=200, y=200)
Die Code-Dichte von RISC-V 32c ist eigentlich nicht so uebel, aber
grundsaetzlich krankt die Architektur daran, dass man nicht so richtig
von der MIPS-Schule weggekommen ist.
Da man aus Python aber so ziemlich alles zwischen Hardware bis
Stack-Maschinencode generieren kann, und die OO da eigentlich ziemlich
vorbildlich funktioniert, stellt sich schon die Frage fuers Engineering:
Warum Forth, wenn es einen gut lesbaren de-fakto Standard gibt.
"Da man aus Scala(*) aber so ziemlich alles zwischen Hardware bis
Stack-Maschinencode generieren kann, und die OO da eigentlich ziemlich vorbildlich funktioniert, stellt sich schon die Frage fuers Engineering:
Warum Python, wenn es einen gut lesbaren de-fakto Standard gibt."
Oder mit anderen Worten: Man kann sowas mit praktisch jeder aktuellen Sprache bauen. Aber immer mit den jeweiligen Vor- und Nachteilen. Es ist also eine überflüssige Trivialdiskussion, oder?
/regards
(*) Siehe z.B. Chisel & Spinal-HDL als Scala DSLs für HW Entwicklung.
Unter Linux nutzt man ja üblicherweise ghostscript, und da kann man für den X11-Treiber problemlos Auflösung (PS rechnet per default mit 72dpi) und Größe des Ausgabegeräts (das X11 window) einstellen:
Oder mit anderen Worten: Man kann sowas mit praktisch jeder aktuellen
Sprache bauen. Aber immer mit den jeweiligen Vor- und Nachteilen. Es ist
also eine überflüssige Trivialdiskussion, oder?
Nicht ganz, wenn man sich mit der Semantik und Transpilationsdetails naeher beschaeftigt. Da gibt es ein paar Aspekte, die bisher nur mit Python sauber/effizient funktionieren, insbesondere wenn es in die Co-Verifikation (gegen bestehende Algorithmen) geht.
Aber das ist eine andere Geschichte.
Apropos: Gibt es eine für Python optimierte FPGA-CPU?
Ja. Aber liegt hier eher als Proof of Concept. Im Endeffekt wird die zugrundeliegende Stackmaschine dann doch in C programmiert, oder gleich ein Hardware-Sequencer in HDL generiert.
Es ist auf jeden Fall ein nettes Display und da ja bald Weihnachten ist, hast du wahrscheinlich Glück und es kommt noch vor dem Post-Geschenke-Stau durch.
In welcher Programmiersprache willst du es programmieren? Micropython scheint mir mittlerweile ziemlich geeignet.
Wenn sich mehr Leute dafür interessieren, könnte man einen Micropython Thread speziell für dieses Display aufmachen.
Hier noch ein wichtiger Hinweis zum LCD, falls man einen anderen Treiber suchen muss oder einen selber schreiben will:
*The built-in controller used in this LCD is ST7735S, which is an LCD controller with 162 × RGB × 132 pixels, while the pixels of this LCD are 160(H) RGB × 80(V).
Wenn Du Dir da an den LVGL Demos gefallen findest (nice Toolkit btw.) dann wundere Dich nicht wenn Du da Probleme beim experimentieren kriegst.
Aktuell hat das LVGL Image bereits die Version 9.4 eingebaut. Der Link zur Doku ist aber immer noch für Version 8. Und von 8 --> 9 hat sich einiges geämdert. Insbesondere sind einige Set-fct jetzt nicht mehr für die einzelnen Widgets direkt verfügbar, sondern werden über Styles gesetzt.
Das ist ein sehr interessanter Link. Ich wusste nicht, dass es Micropython mit LVGL Integration gibt.
Bis jetzt habe ich nur die Nano-Gui gefunden, die einige ziemlich einfach aussehende Anzeigeelemente bietet: https://github.com/peterhinch/micropython-nano-gui
Die scheinen aber hauptsächlich für monchrome E-Paper-Displays gut geeignet, wo LVGL eher schwierig sein dürfte.
Wie hast Du LVGL installiert? Was waren die Schwierigkeiten?
War mehr als trivial. Für das Display auf dem 0.96 LCD Pico 2 bietet Waveshare ja direkt eine LVGL Demo an (findest Du auf der Website). In diesem ZIP sind bereits vorkonfigurierte .uf2's für c/C++ & MicroPython enthalten.
So wie es aktuell aussieht sind die Driver für die anderen WaveShare Displays (und da gibt es ja einige) auch enthalten. Da die Anzahl der "üblichen" Displaycontroller ja überschaubar ist ist es wahrscheinlich, dass Dein Display da schon verfügbar ist.
Ansonsten findest Du auch sehr leicht wie man neue Controller ansteuert. Die "normale" Methode (wie meist): Du pinselst in einen Framebuffer (je nach Controller intern oder im Pico) und "blittest" es dann in das sichtbare Displayarea.
Ich kann da evtl demnächst mehr berichten, wenn es Dich interessiert. Dann habe ich da ein paar Displays ausprobiert. Auch mit Touch, was LVGL dann gleich miterledigt.
/regards
P.S: Das Micropython habe ich auch probiert. Es ist weniger ätzend wie ich vermutet hatte ;)
War mehr als trivial. Für das Display auf dem 0.96 LCD Pico 2 bietet
Waveshare ja direkt eine LVGL Demo an (findest Du auf der Website). In
diesem ZIP sind bereits vorkonfigurierte .uf2's für c/C++ & MicroPython
enthalten.
Danke für den Hinweis. Irgendwie muss es da wohl verschiedene geben. In meiner Version war meines Wissens nach kein LVGL im Micropython. Vielleicht könntest du den Download-Link posten und wenn es ein kurzes Microypthon LVGL "hello world" gibt wäre es für mich auch sehr hilfreich.
P.S: Das Micropython habe ich auch probiert. Es ist weniger ätzend wie
ich vermutet hatte ;)
Ja, es wird nach über 10 Jahre vermutlich langsam erwachsen und es wird immer mehr auch professionell verwendet. Ich meine gelesen zu haben, dass es mittlerweile sogar schon in einem Satellit läuft.
Man kann es auch relativ leicht selbst compilieren (die make files laufen recht gut auf Ubuntu) und gleich eigene Python Scripts (mit mpy-cross) mit ins uf2 File packen.
Danke, das hilft weiter. Ich hatte ein anderes Repo, in dem das LVGL uf2 nicht drinn war. Wie man sieht, läuft es, aber es gibt im Foto Punkteffekte, die man mit den Augen nicht sieht.
Das Programm läuft einmal durch und zeigt den Button an, aber beim zweiten Mal stürzt es ab. Ich vermute, man muss das Display vorher schließen.
Das ist Python. Geht es in diesem Thread nicht eigentlich um Forth?
So war es geplant. Aber da es hier ja eher weniger Forth-Liebhaber dafür aber umso mehr Nörgler gibt (siehe der Anfang dieses Threads) bin ich mal auf Micropython umgestiegen.
Für das Beispiel hier Beitrag "Re: Object Oriented Forth"
habe ich mir einen Postscript Interpreter (der auf dem Display läuft gebastelt), was ja Variante von Forth ist.
Vielleicht hat ja jemand Lust, einen echten Forth-Interpreter auf dem Display laufen zu lassen.
Das ist Python. Geht es in diesem Thread nicht eigentlich um Forth?
Mea culpa. Da hast Du völlig recht. Vielleicht mag Christoph M. ja einen eigenen Faden für Pico 2 & Micropython aufmachen. Das Problem mit dem LVGL restart konnte ich inzwischen nachvollziehen.
So war es geplant. Aber da es hier ja eher weniger Forth-Liebhaber dafür
aber umso mehr Nörgler gibt (siehe der Anfang dieses Threads) bin ich
mal auf Micropython umgestiegen.
Dann plane doch vielleicht eine Änderung des Titels ein, damit der irgendwie zum Faden passt.
Und wieso "genantwort" und "zeigantwort" anstatt "antwort" und "zeige"? Steckt da ein tieferer Sinn hinter? "antwort zeige" wäre doch eher FORTH-typisch.
Ein durchaus valider Einwand gegen den ich kaum argumentieren kann.
Bestenfalls dass ich diesbezüglich schon ein wenig eingerostet bin und deshalb die schlichte Eleganz nicht mehr wertzuschätzen weiß.
PiPico2_LCD_0_96.png
(190 KB)
