IoTBASIC bzw. TinyBASIC (Stefans's BASIC) auf div. Plattformen

Hi all, just wanted to mention that the Basic 2 version is work in progress. I started to separate the device driver layer from the interpreter and will rewrite the entire string code. Features I plan is a compatibility set for MS strings. So RIGHT$, LEFT$ etc. will be available soon.

Question to everyone here: which features should I prioritize?

Vielleicht wäre es ja gut, das Ganze mehr modular zu machen. Also so, daß man bestimmte Sachen einfach einkompilieren kann, wenn man die haben will.(?) Also zumindest, wenn Du es eh schon so grundlegend umbaust.

Was sind denn die Features, die im Angebot sind ? Und priorisiert werden können.

Bei String Kommandos wäre es schön, wenn Du mal schaust, ob nicht evtl. zu jedem String eine Längenvariable existieren könnte, die einfach immer parallel mitgeführt wird. Also vielleicht sowas wie A$ und dazu A# ( was A# = LEN (A$) ist ) und immer dann automatisch aktualisiert wird, wenn A$ sich ändert. Das würde nämlich viele solche Stringkonstrukte immens vereinfachen.

Zitat von ThoralfAsmussen

Vielleicht wäre es ja gut, das Ganze mehr modular zu machen. Also so, daß man bestimmte Sachen einfach einkompilieren kann, wenn man die haben will.(?) Also zumindest, wenn Du es eh schon so grundlegend umbaust.

Was sind denn die Features, die im Angebot sind ? Und priorisiert werden können.

Bei String Kommandos wäre es schön, wenn Du mal schaust, ob nicht evtl. zu jedem String eine Längenvariable existieren könnte, die einfach immer parallel mitgeführt wird. Also vielleicht sowas wie A$ und dazu A# ( was A# = LEN (A$) ist ) und immer dann automatisch aktualisiert wird, wenn A$ sich ändert. Das würde nämlich viele solche Stringkonstrukte immens vereinfachen.

Die Längenvariable existiert ja schon intern und wird normalerweise mit LEN(A$) abgerufen. Bei fast allen BASICS ist ein String ja intern repräsentiert durch

<Stringlänge> n* <Characters>.

Momentan denke ich über den String Code nach. Der Original Stringcode ist ja Apple 1 kompatibel und nicht MS kompatibel. Es werden die Strings als Substrings angesprochen. Cromecon BASIC hatte das später auch. Alle anderen hatten MS Strings. Die baue ich eben ein.

Wegen modular: das BASIC hat jetzt 6 Files statt bisher nur 2. Ein File ist der komplette Interpreter und ein anderes ist die komplette Runtime Umgebung. Es wird also Hardware von Interpreter strikt getrennt. Nur so kann ich weiterarbeiten, weil sich zu viel Device Driver Code in den Interpreter eingeschlichen hat.

Features:

- Mehr Grafik Kommandos, insbesondere Grafik die Text kann.

- Integration von mehr Sensoren beim Arduino Code

- SET und USR Kommando logischer machen.

- Editor und Hilfskommandos wie RENUM und AUTO.

- Lokale Variablen

- Prozeduren und Funktionen mit mehreren Zeilen und Parameters.

Die letzten beiden sind schwierig, weil das ganze Konzept von BASIC auf klein und schlank angelegt ist.

Die wichtigsten technischen Schulden im Code sind

- String Code sehr umständlich. (Aber ziemlich schnell) -> Apple 1 Legacy

- Heap kann keine lokalen Variablen, weil zu einfach.

- Lexer kennt die Grammatik nicht.

Dann noch

- Netzwerkcode verbessern, statt nur MQTT auch andere Protokolle

- Telnet Zugang auf Microcontroller

- Robotik Kommandos einbauen (Servo und Motoren).

Letzteres macht mir gerade am meisten Spass.

Zitat von guidol

Zitat von slenz

Dann noch

- Telnet Zugang auf Microcontroller

Auch direkt auf anderen Plattformen ausser ESP32?
Weil bis jetzt habe ich nur eine Telnet-Version von RunCPM fuer den ESP32 im Angebot
(beim ESP8266 geht da zu schnell der Speicher aus - so kein ESP8266-RunCPM)

Ich hab einen super einfachen Telnet Code und will es generisch machen.

Klingt doch gut. Bei den Mikrocontrollern kann sicher der guidol sehr gut sagen, was man da wirklich haben will und was unnötiger Zusatz ist.

Was ich mit dem Modular-Machen sagen wollte, war u.a. auch sowas wie, daß man das Ganze am Ende auch (also so Leute wie guidol) selbst mit den Sachen bauen kann, die man da drin haben will. Und das Ganze ohne, daß man den Code selbst irgendwie anfassen muß. Oder lediglich irgenwelche #includes ausmarkiert.

Die Idee wäre z.B., daß man etwa die Telnet Fähigkeit komplett und definiert abschalten kann, weil man sie komplett weggelassen hat. Das ist ja schließlich je nachdem auch ein Sicherheitsproblem, aber vor der eigentlich Anwendung / Benutzung / Verkauf mit Produkt extrem sinnvoll und ein echtes haben-will Feature.

Gleiches gilt dann auch für z.B. das String-Modul. Möglicherweise braucht man das ja auch überhaupt nicht, dann sind es, wenn es einfach gar nicht dabei ist, ein paar hundert Bytes mehr, die man zur Verfügung hat. Und das tolle am Tiny ist ja, daß es möglichst klein sein soll.

Noch krasser wird das wahrscheinlich bei Grafikfunktionen.

Außerdem ergibt sich damit - wenns überlegt gemacht ist - auch die Option einfach das alte Apple-1 Stringmodul zu benutzen, wenn das besser paßt.

Zitat von slenz

Dann noch

- Netzwerkcode verbessern, statt nur MQTT auch andere Protokolle

- Telnet Zugang auf Microcontroller

- Robotik Kommandos einbauen (Servo und Motoren).

Letzteres macht mir gerade am meisten Spass.

Ich würde ja sagen , daß dann klar ist, was Vorrang haben sollte. Natürlich das, was Dir am meisten Freude daran macht.

Und gerade Ansteuersachen / Robotik / RPi / 3399 Steuer-Geschichten holen ja potentiell viele Leute neu mit auf die Sprache. Ein Bar-Bone BASIC mit Robotik Eigenschaften auf Minirechnern könnte sogar was sein, was richtig "steil" geht.

Außerdem hat eine komplett neue Funktion durchaus auch den Charme, daß Du erstmal im Hinblick auf mögliche neue Grundstruktur mal schön Probieren kannst, was da sinnvoll geht und was nicht. Zum Beispiel wird wahrscheinlich dynamisches Modul-Laden völlig unnötig sein, für die Anwendung.

SYNTAX:

Gut wäre evtl. eine Art Datentyp, den man in der Form Schildkröte.X oder Schildkröte.Winkel benutzen kann. Also so eine Art verkapptes struct (C) bzw. record . Einfach schon deshalb, weil viele Leute, das heutzutage einfach genau so schreiben können wollen.

zu den Varianten

Zitat von slenz

Features:

- Mehr Grafik Kommandos, insbesondere Grafik die Text kann.

- Integration von mehr Sensoren beim Arduino Code

- SET und USR Kommando logischer machen.

- Editor und Hilfskommandos wie RENUM und AUTO.

- Lokale Variablen

- Prozeduren und Funktionen mit mehreren Zeilen und Parameters.

Alles anzeigen

Grafik ist immer nett ... aber es macht ein Riesen-Thema auf. Und wird auch dann mit der Geräteunterstützung schwieriger, weil ja wohl jeder grafikfähige Kleinrechner das irgendwie komplett anders abhandelt. Außerdem zieht es dann realtiv schnell Sachen nach sich, in die man sich schnell verrennen kann (Viewports, Fenster, GUI, 3D Funktionen etc.). Allerdings macht das natürlich darum auch relativ viel Freude, weil man schnell was sieht und weil es auch schön optimierbar ist. Außerdem darf man natürlich den Vorführeffekt (nicht den, wo die Geräte abstürzen, sondern den, wo die Leute sagen, daß das gut aussieht) nicht vernachlässigen.

Evtl. magst Du ja hier im Forum mal nach Apple ][ und @golombeck suchen. Der hat eine 3D Grafik gebaut, die performant scheint. Vielleicht kann man sowas ja auch einfach mal langfristig übernehmen.

Editorkommandos sind auch sowas, was bestimmt nicht alle Leute benutzen. Auf einem echten Mikrocontroller wird ja vmtl niemand das direkt auf dem Gerät tippen. Schön wenns trotzdem geht, aber evtl. auch was, was man bei Nichtbedarf ausmappen können will.

Persönlich finde ich ja Labels viel charmanter als Zeilennummern.

Und das führt dann schnell zu Prozeduren. Das ist wirklich was, was man haben will. Und v.a. natürlich in Kombination mit lokalen Variablen.

Bei einem BASIC dieser Art hier ist es aber sicherlich komplett OK, wenn die nicht rekursiv funktionieren. D.h. nur eine "Tiefe" erlaubt ist. Dann lassen sich auch die Variablen ganz am Anfang direkt unterhalb des eigentlich Variablenspeichers fix anlegen und bleiben halt dann einfach die ganze Laufzeit erhalten. Erfordert halt einen einmaligen Suchdruchlauf ganz am Anfang (den man evtl ja auch ansagen muß, dann startet es ohne prozeduren ganz normal flott).

Wichtig ist aber, m.E., daß man wählen kann, ob man pointer oder echte Datenübergabe haben will, also der Unterschied zw. call-by-value und call-by-reference. Das macht gerade bei BASIC manchmal einen RIESEN Unterschied, zumal Du ja evtl. in späteren Versionen auch mal zu sowas kommen kannst, wie, daß Prozessorregister als Zwischenspeicher genutzt werden (bei 32 verfügbaren bleiben ja wahrscheinlich schon ein paar übrig).

_{Und wo gerade Speed Thema ist - und dann hör ich mal auf damit - fällt mir ein, daß es auch sehr schön wäre, wenn es sowas wie eine Struktur gäbe, die per se eine verpointerte Liste darstellt. Also irgendwie so, daß man auf irgendwelche Arrays eine Integerliste anlegt, die halt einfach nur die Nummern der Arrayplätze enthält. Dann lassen sich nämlich die Sachen in der Liste schön unabhängig vom Array umsortieren und das geht schön schnell. Echter Datenzugriff ist dann aber wieder bißchen langsamer, über alles macht das aber bei vielen Sachen viel Sinn.}

_{( DIM A$ 1024 ; DIM A% 1024 ; FOR i = 0 TO 1023 : A% = i : NEXT ; B$ = A$( A%(768) ) ) wird zu}

_{( DIM A$ 1024 ; DIM A% LINK A$ ; B$ = A$ ( A%(768 ) ) )}