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.