Copyright © 2002-2006, Kees Krijnen
SF is an object oriented generic programming language for embedded purposes. The name SF was originally meant as an acronym for Structured Forth, but the SF syntax has no resemblance with the Forth programming language syntax and the name is just SF now without hinting to Forth. The SF programming language will be supported by a development system named Prime offering initially an integrated compiler, editor and syntax checker. For future releases a (target) debugger and code/design browser will be added. The `structure' in the SF former name Structured Forth did not imply that Forth has no structure or does not offer structure but that the SF source code layout is forced (like coding standard rules) to improve readability and more modularity and clarity is offered by data structures, strong typing and object oriented techniques.
A Forth compiler-interpreter is an extensible macro-assembler for an abstract stack processor (virtual machine). Forth's postfix notation and its inner construction allows very compact refactored code providing a terminal, an editor, a compiler and an interpreter within 16KB of code for a general 8-bit processor like the Z80 or 6502. The low memory requirement and the interactive debugging feature were a great advantage in the beginning years of microprocessors. Forth's postfix notation and therefore often hard to read code has (among other things) prevented a widespread acceptation.
SF is intended as a very readable object oriented generic programming language while keeping the unique features from Forth as much as possible. The inner works of SF are still very Forth-like; infix statements and function calls are translated to postfix statements before being processed. The SF cross-compiler generates - depending on target system requirements, speed vs. code size - native, indirect or token threaded code.
The SF cross-compiler is an incremental compiler evaluating all source code (global analysis) used as input for complete - all - target code generation. There are no forward reference declarations required. The SF compiler keeps track of all references by means of a in-memory indexed database (IMDB) also written to disk as a repository for rebuilds, dynamic loading and debugging. Some file extensions are reserved for SF processing:
| .sf | - | source code |
| .sfm | - | the main source code |
| .sfp | - | processed source code, offers interface (public), dependencies (use) and object code (hexadecimal text format) |
| .sfl | - | library of processed source code, contains multiple *.sfp files |
| .sfr | - | repository of the actual build process, also used as input for rebuilds, dynamic loading and debugging |
The interpreter is invoked when the '#'-token is found on the
first position of a line. This is the SF
interpreter on the cross-compiling host system, not on target!
Invoking the host system interpreter allows tailoring of the compilation
process.
The interpreter on target could be used for debugging and is accessed via a target shell command line tool. The target interpreter does not compile but it does provide e.g. execution and dynamic loading of SF modules, classes and functions.
These items are subject to change and are not specified in this document until a working SF cross-compiler becomes available.