Forth as extension language with C embedded system

[hth313]

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

[DRuffer]

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.

[MitchBradley]

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

[larsbrinkhoff]

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

[massung]

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?". ;-)

[paraplegic]

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 ...

[Brad-R]

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

[phreda4]

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 https://github.com/ForthHub/discussion/issues/65#issuecomment-376274317, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZ9nP9NfPK_YnBRWrgFpZ3tQnj8hn-Mks5tiTnmgaJpZM4S5_Pc .

[hth313]

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

[mikaelpatel]

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

[ivand58]

Check this out Atlast by John Walker

[yunfan]

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

[MitchBradley]

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.