Forth as extension language with C embedded system

Question

Forth as extension language with C embedded system

hth313 opened this issue 6 years ago · 12 comments

I consider adding a Forth as an extension language to a C based embedded system. It will get called from the C side, perhaps also making calls back to C as needed.

The main targets here are MSP430 and Cortex-M. I want something that has a permissive open source license (BSD or similar).

Given that I know how to deal with going back and forth between C and Forth, what is a good foundation for a Forth?

I do not want to implement a Forth, but if the assembly parts are reasonable small I am prepared to tweak it if needed. I definitely want to avoid implementing a high level standard Forth library.

I have looked a bit at eForth, which seems simple enough. How serious of a Forth is it? It is based on some old standard? I have to admit that I get very confused by all these modern strange compile/postpone semantics.

Is going with eForth a good idea? It is pretty small and I can probably implement some additional words in assembly if needed. As I want to avoid writing high level Forth libraries, are such libraries available that I can put on top of it?

Håkan

Answer 1 · 2018-03-25T02:58:04.000Z

Why reinvent the wheel? http://ficl.sourceforge.net/ DaR From: Håkan Thörngren Sent: Saturday, March 24, 2018 7:47 PM To: ForthHub/discussion Cc: Subscribed Subject: [ForthHub/discussion] Forth as extension language with C embeddedsystem (#65) I consider adding a Forth as an extension language to a C based embedded system. It will get called from the C side, perhaps also making calls back to C as needed. The main targets here are MSP430 and Cortex-M. I want something that has a permissive open source license (BSD or similar). Given that I know how to deal with going back and forth between C and Forth, what is a good foundation for a Forth? I do not want to implement a Forth, but if the assembly parts are reasonable small I am prepared to tweak it if needed. I definitely want to avoid implementing a high level standard Forth library. I have looked a bit at eForth, which seems simple enough. How serious of a Forth is it? It is based on some old standard? I have to admit that I get very confused by all these modern strange compile/postpone semantics. Is going with eForth a good idea? It is pretty small and I can probably implement some additional words in assembly if needed. As I want to avoid writing high level Forth libraries, are such libraries available that I can put on top of it? Håkan — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

Answer 2 · 2018-03-25T04:52:25.000Z

Another choice is CForth - https://github.com/MitchBradley/cforth

Answer 3 · 2018-03-25T09:19:39.000Z

To add to the above, CForth is used in One Latop Per Child, and FICL is used in FreeBSD.

Answer 4 · 2018-03-25T13:21:28.000Z

Why reinvent the wheel?

I'm sorry, just had to comment that I had myself a little chuckle when I read this... given that likely everyone reading this has written at least one Forth (or Lisp) from scratch and probably more for no other reason than "why not?". ;-)

Answer 5 · 2018-03-25T16:23:22.000Z

While FICL and CForth are TOP DRAWER implementations, if everyone who has scratched this particular itch gets to advertise, then perhaps https://github.com/paraplegic/OneFileForth should also be included ;-) Oh, and the license doesn't get any more permissive than this one ...

Answer 6 · 2018-03-26T18:56:33.000Z

My own extremely modest, and extremely preliminary, contribution: http://camelforth.com/news.php?extend.65.1 http://www.camelforth.com/download.php?view.35

Answer 7 · 2018-03-26T21:40:32.000Z

my VM is in nearly plain C https://github.com/phreda4/r4MV/blob/master/r4wine2/redam.cpp I'm like reinvent the wheel, welcome!! 2018-03-26 15:56 GMT-03:00 Brad-R <notifications@github.com>:

…

My own extremely modest, and extremely preliminary, contribution: http://camelforth.com/news.php?extend.65.1 http://www.camelforth.com/download.php?view.35 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#65 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAZ9nP9NfPK_YnBRWrgFpZ3tQnj8hn-Mks5tiTnmgaJpZM4S5_Pc> .

Answer 8 · 2018-03-28T04:25:39.000Z

Thank you all for the links to C based Forths, I will look into them.

Answer 9 · 2018-03-28T08:30:04.000Z

A few more links :)
https://github.com/mikaelpatel/Arduino-FVM
https://github.com/mikaelpatel/Cosa-Shell
https://github.com/mikaelpatel/vfm
Cheers!

Answer 10 · 2018-03-28T11:15:11.000Z

Check this out Atlast by John Walker

Answer 11 · 2018-04-12T02:38:57.000Z

actually i;d always recommend to use forth to replace the roles of lua
you could compare the two langs. so with lua, we know its not only used in embeding domain, but
also server side domain, like the famous http server nginx and the famous kv store redis go and check it

Answer 12 · 2018-04-12T05:03:56.000Z

The reason I ported CForth to esp8266 is because Lua just was not getting the job done for an application I was working on. esp8266 has a lot of FLASH but not a huge amount of RAM. Lua, as used in the NodeMCU esp8266 modules, consumes RAM at a furious rate, and it is not easy to trade FLASH for RAM. By the time I had added Lua drivers for two I2C devices, the esp8266 RAM was full.
By comparison, CForth uses RAM quite sparingly, and it is quite easy to move code into FLASH to further reduce the RAM footprint. With CForth, my app, which needed drivers for about seven I2C devices, fit easily with lots of room for other code.
By the way, the reason that Lua uses RAM so fast is because, in Lua, everything is an object, requiring a large-ish data structure. Even short code sequences generate a substantial RAM footprint.