We're at STM8 eForth 2.2.28 now ... :-)

A project log for eForth for cheap STM8S gadgets

Turn cheap modules from AliExpress into interactive development kits!

ThomasThomas 05/14/2021 at 07:491 Comment

With release STM8 eForth 2.2.28 this "Small Forth" is more "Forth-Standard" leaning. One notable change is the usage of the POSTPONE method instead of COMPILE and [COMPILE]. In fact, the new method for extending the Forth compiler is not only more elegant, it's also more code efficient. The words DEFER ... IS were added - these words facilitate an interactive stile of top-down programming. 

Since this is an embedded Forth for small µCs full standard compliance will be out of reach unless there is a standard for implementations that keep their dictionary in an executable ROM. Where code size or speed is concerned compatibility will always be an option to facilitate porting code. A good example is using 1-Wire code for DS18B20 that Brad Rodriguez wrote for CamelForth.

There is an open issue that collects small Forth-Standard compatibility additions.

So far we're here:

One notable difference will be "pictured number output": Forth Standard compliance requires # ( ud -- ud) instead of # ( u -- u) (double instead of single math). Although this increases the code size only marginally it makes printing numbers in a background process slower. Instead there will be a change in the upcoming release 2.2.29 that speeds up printing numbers (by a factor of 2.5 to 7). Words for dealing with double numbers will be added as an option.

Another notable change is a re-write of CREATE ... DOES> that makes using this key feature both code efficient and fast.


Travis Bemann wrote 3 days ago point

I personally tend to follow ANS Forth when expedient, and do other things when it is not expedient, or I just don't feel like it. For instance, zeptoforth uses the ANS Forth POSTPONE word rather than COMPILE or [COMPILE], but at the same time its treatment of flash versus RAM is unlike anything in ANS Forth (for instance it has a HERE pointer for each task combined with a global HERE pointer for flash, and words such as , automatically choose which HERE pointer to use depending on the global compilation state (i.e. whether it is compiling to flash or to RAM), and also it has NOT instead of INVERT just because stylistically I like NOT much better. Likewise to use DOES> one must use <BUILDS instead of CREATE and [IMMEDIATE] and [COMPILE-ONLY] inside word definitions rather than IMMEDIATE or COMPILE-ONLY following them due to the limitations of compilation to flash.

  Are you sure? yes | no