ESP8266 Community Forum

There has been two previous posts[5] about the Forth language on the ESP8266, as well as the YAFFA (Yet Another Forth For Arduino), which was easy to get running on the ESP8266.

However, implementing Forth in C is very inefficient and if one understands the power of forth in its native form, one shouldn't consider that as the optimal choice. Forth in assembler is incredibly resource efficient, minimal use of stack, no dynamic allocation, tight data structures and rather small footprint which includes both the compiler itself , a REPL and the decompiler(!). Few languages can even get close to incredibly small footprint of its runtime, yet offers less features in that runtime than Forth does. What is more, Forth allows user code to modify compiler behavior, quite unlike anything out there.

Forth is a language that has largely gone out of style, because people say that they find it obscure and had to read. And yes, at the lowest/primitive level, Forth can be rather intimidating and nowadays few people have the RPN (such as HP-10, HP-12, HP41C,... calculators) background that helps in the initial few steps. So when

3 4 5 + * .

outputs 27, it is confusing. ( push 3 to stack, push 4 to stack, push 5 to stack, addition of two elements on stack=>9, multiply two elements on stack => 27, and finally the dot to print the top of stack and remove it.

And when we see low level examples, such as the fibbonacci series printout

: fib
cr 0 1 rot 0 ?do over + dup . swap loop drop ;

I also agree that it looks very weird if you are not used to it. But studies shows that programming language syntax is mostly a function of previous exprience, hence Java looks easier because we learned C first.

But typical Forth programs looks very different at the higher level;

: game-loop ( -- )
begin
draw-snake
draw-apple
100 sleep
check-input
move-snake-tail
move-snake-head
check-apple
check-collision
until
." Game Over" ;
(Courtesy of Nick Morgan[4])

and I don't think any argue that the above is hard to read, even though the "100 sleep" uses this postfix notation.

If you have managed to get through the basics of Forth, I recommend the YouTube video[6] by Andreas Wagner, where he shows how to extend the language to do text processing and use Forth inside the text stream. Eye-opener on how simple things could be...

If you haven't learned Forth, you should! If not for any other reason than to learn how a language can work differently and how you can actually understand all of its internal bits (unlike gcc, jvm, clr and such beasts). When I was ~17 years old (1983), I ported Forth first time to both the Z80 and the 6502 processors. That experience later resulted in implementing a programming language for industrial automation at a company called Exomatic (now part of Regin AB).

But I am getting off track here.

Richard W. M. Jones created a a wonderful implementation of Forth[2] for i386 CPU (backed by Linux for terminal in/out), where an entire "Internals of Forth"-like lecture is included as source code comments. Great Stuff!
Cheng Chang Wu started an effort to make JonesForth into ANS Forth compatible[3], but unsure how complete that is.

Cheng Chang Wu's GitHub repository was the starting point for my porting effort of JonesForth to ESP8266, and I call it forthright.[1]
The approx 1000 lines of i386 assembler has been ported to ESP8266 assembler, but has not yet been TESTED. It compiles, but I have not managed to link it into anything and the Makefile lacks entry for the linking phase. I have also very few ideas on debugging the runtime, no tools or hardware to debug on the target and can't find any simulation tools for my desktop.

The purpose of this post is both trying to ignite some new enthusiasm for the language, which is extremely well suited for tight environments (ESO8266 is not even considered small by Forth standards) as well as hoping to get some help on this effort.

1. I am sure I have made mistakes in the translation, which was manual and took approx 30 hours up until now. I would like to get additional eyes on the translation, especially the INTERPRET section in the assembler part, but also its primary dependencies.

2. I am also struggling to linking this into an image that I can upload to an ESP module. At the current stage, I try to link it into the ESP8266/Arduino environment, but get a lot of



linker errors in that case. Ideally it should be linking with the Espressif SDK toolchain and libraries instead.

3. At the moment, I don't see any alternative to "additional eyes and very tedious manual single-stepping on paper" approach of debugging this. But if someone has a setup with JTAG target debugger or an ESP8266 simulator, then I would like to hear about that.

I am not overly optimistic that there is an interest, and I will continue to work on this on my own, as I intend to eventually use this for real projects.

Preferably, any replies should be right here, for everyone to enjoy, but if you need private correspondence you can reach me at niclas at hedhman dot org

Cheers All.

Links;
[1] https://github.com/niclash/forthright

[2] http://git.annexia.org/?p=jonesforth.git;a=summary

[3] https://github.com/chengchangwu/jonesforth

[4] https://skilldrick.github.io/easyforth

[5] Forth posts
viewtopic.php?f=6&t=7058&p=36101&hilit=forth#p36101
viewtopic.php?f=6&t=1737&p=10434&hilit=forth#p10434

[6] https://www.youtube.com/watch?v=mvrE2ZGe-rs

Status Update;

Done/completed since last time;
* FORTH assembler part is done and seems to work.
* A slightly modified JonesForth is parsed on startup and works.
* A TCP shell has been added, but lacks any kind of security at the moment.

Work continues on
* Testing framework.
* GPIO and other peripherals.

Hello!
I'll be very thankful if you could please let me know how did you solve the error?
I am using ESP32 and arduino ide, and as far as I have observed its caused by a header file.
I have C code of a trained svm model in a header file that i generated using scikit and micromlgen (Python). The size of header file is 900KB. With smaller models (smaller header files) the code runs smoothly and classifies given data, however with 900kb file it gives me following error:



sketch/model.h:986:(.text._ZN8Eloquent2ML4Port3SVM7predictEPf[Eloquent::ML::Port::SVM::predict(float*)]+0x3ee13): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.literal._ZN8Eloquent2ML4Port3SVM7predictEPf+0x4b68)

4 years later, I don't recall the problem at hand. But I assume it was simply a matter of getting all the code inside the available flash image.
IIRC, I think I went from dual program partitions to a single one, but after ESP32 came out, I haven't touch ESP8266 nor this particular project.