101 lines
3.5 KiB
Plaintext
101 lines
3.5 KiB
Plaintext
|
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.
|
|||
|
|
|||
|
|
|||
|
|