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
(.text+0x3a2): dangerous relocation: l32r: literal target out of range (try using text-section-literals): (.data+0x8)
esp8266.o: In function `code_SZ':
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