Compare commits

...

1 Commits

Author SHA1 Message Date
089a6993fb
docs en 2021-12-04 07:55:23 +05:30
2 changed files with 162 additions and 0 deletions

62
docs-en/README-EN.md Normal file
View File

@ -0,0 +1,62 @@
documentation? does not exist.
organization of the infoblock:
1. accesslevel
2. name
3. clearcache
4. cache name
here is the text that i used for the draft. rather outdated:
Fixed program memory
=====================
For the time being, simply on the hard drive in a directory.
Fixed data storage
==================
Not at all, later maybe hard disk, or mysql, or whatever
always.
Data memory
=====================
Doubly linked list, each element can also have a name.
Access either by push / pop or shift / unshift, using a number as with
an array or by its name like a hash.
However, it is also possible to access it directly via a pointer. pointer
however, cannot be created directly by the user, only by
correspondingly privileged programs.
Diese Speicherstruktur nenne ich "vector".
Datentypen:
Nach Außen hin sollen nur wenige verschiedene Datentypen sichtbar sein:
- Wert (integer, string, was auch immer)
- Vector
Wert wird intern in mehrere subtypen unterteilt, die jedoch automatisch
bei Bedarf konvertiert werden:
- int
- float
- string, bzw. pointer auf string
- pointer auf Elemente eines Vektors
Aus technischer Sicht gibt es nach Außen hin eigentlich auch nicht die
Unterscheidung zwischen Wert und vector. Auch hier kann und wird bei Bedarf
eine automatische Konvertierung vorgenommen. Im Normalfall wird jedoch der
Anwender dies nicht tun, und in der Dokumentation wird auch immer ein klarer
Unterschied zwischen normalen Werten und Vektoren gemacht.
Ein Sonderfall ist der Pointer auf Elemente eines Vektors: Weder kann von
einem Wert in diesen Typ konvertiert werden, noch anders herum (bzw. doch,
aber dann käme nur ein String "pointer" oder 0 bei heraus).
Die einzelnen Elemente eines Vektors werden in einem union gespeichert. Der
Union enthält die verschiedenen möglichen Ausprägungen der Werte, also int,
float, und pointer. Zudem gibt es ein Feld, in dem gespeichert wird, welche
Ausprägung gerade "aktiv" ist.
Ein zusätzlicher Typ, den man später noch hinzufügen könnte wäre "array".
Dieser Typ würde sich zum Speichern größerer Datenmengen eignen, da er
gegenüber einem Vektor keinen Overhead pro Element hätte.

100
docs-en/outline.txt Normal file
View File

@ -0,0 +1,100 @@
Fixed program memory
=====================
For the time being, simply on the hard drive in a directory.
Fixed data storage
==================
Not at all, later maybe hard disk, or mysql, or whatever
always.
Data memory
=====================
Doubly linked list, each element can also have a name.
Access either by push / pop or shift / unshift, using a number as with
an array or by name like a hash.
However, it is also possible to access it directly via a pointer. pointer
however, cannot be created directly by the user, only by
correspondingly privileged programs.
In the first draft, you would have items that can be accessed by number or name
accessed by naive search. You can do one later
Put an index or something on it.
I call this memory structure "vector".
Data types:
Only a few different data types should be visible to the outside:
- value (integer, string, whatever)
- Vector
Value is divided internally into several subtypes, but these are automatically
converted if necessary:
- int
- float
- string, or pointer to string
- pointer to elements of a vector
From a technical point of view, there is actually no such thing on the outside
Differentiation between value and vector. Here, too, can and will if necessary
made an automatic conversion. Normally, however, the
Users don't do this, and the documentation is getting clearer too
Difference made between normal values and vectors.
A special case is the pointer to elements of a vector: Neither can from
a value can be converted into this type, the other way around (or
but then only a string "pointer" or 0 would come out).
The individual elements of a vector are saved in a union. Of the
Union contains the various possible expressions of the values, i.e. int,
float, and pointer. There is also a field in which it is saved which
Expression is currently "active".
An additional type that could be added later would be "array".
This type would be suitable for storing larger amounts of data because it
would have no overhead per element compared to a vector.
Program memory
========================
The program memory is nothing more than normal data memory. this
makes it possible to write compiler extensions in botforth yourself.
minibotforth
============
The following commands must be implemented:
- swap
- +
...
minibotforth should be so extremely simple that you might find it later
can even omit to compile directly in machine language.
Compiler from botforth to minibotforth
=========================================
1st step: lexical analysis, i.e. recognizing the individual
keywords etc.
Here it is recognized what a command is, but not yet whether the command
is available internally or externally. Each command is called a node of type
BF_TYPE_C_TEXT saved, with the command name in plain text as a string
is filed.
2nd step: compiler. Here botforth is changed to minibotforth. Even
however, command names are stored here as BF_TYPE_C_TEXT.
3. Execution: Only during the program execution, i.e. when we are already doing it
are no longer in compiler mode, commands of the type
BF_TYPE_C_TEXT, as soon as they are to be executed, in BF_TYPE_C_INT or
BF_TYPE_C_EXT converted.
This serves to keep the compiler expandable by the user. He can do so
easily insert commands without having to play around with pointers etc. Consequently
no security hole is created either. From the perspective of a user who
the compiler by programming compile-time behavior of commands
want to expand, commands are to be handled like strings.