Hi guys, I took a look at fifth, but only found one relevant hit and that was an reference only to an article...
This thread however inspired me to spend (spoil?) some time on this concept again. I mentioned the huge footprint of the forth interpreter. I now build a small forth interpreter with some basic words and without the option to add words from scratch. It is running now and is (with serial and i2c routines) about 13k in size. Not in Jal but in C for Atmel, but this is mainly for practical reasons (test code on pc first, a larger atmel board at hand). My idea is to add a finit state machine engine. All basic functions (interrupts, serial comms, i2c comms with slave processors) is done in C. At the top level, the FSM runs. The FSM consists of states, where each state has multibple actions (onentry, onexit, dostate) and multiple conditions (with a new state when true and oncondition action). The forth engine is used for the condition evaluation and actions. The fsm (fsm structure, forth code and some logical names) is defined in an editor and converted by a perl script into data. This data is loaded into an i2c eeprom. And why forth? Since it is simple to build (got it up and running from scratch within one day!) and can hande complex conditions and actions. And it can be easily extended if required. Let me know what you think of this! Joep 2009/5/7 [email protected] <[email protected]>: > > Hi Seb & Joep, > I have more or less the same feeling as Joep, interperters are nice > for flexibility and to test (hardware) without the need of a > development environment. > At Philips (where I work) , we mainly use a forth like language > (called Fifth) to test new hardware (FPGAs, ASICS) > In one point in time I've tried to port it to a PIC, but I ran in too > much issue to make it usable (mainly footprint), so I switched to JAL, > In my opinion the PICs 12/16/18 series are too small (both computation > time and memory/storage space) to make it really usable > for an interperter language to build serious applications. Therefore I > think the focus should be on a good set of easy to use well documented > libraries with lots of samples, improving the compiler/libraries for > speed and footprint, and have an easy to use development enviroment. > Albert > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jallib?hl=en -~----------~----~----~----~------~----~------~--~---
