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.
|
||
|
||
|
||
|