What is advantage of stand-alone forth?
Brought to you by:
oh2aun
Menu
▾
▴
I am playing with FF, but I find myself wondering what the advantage of the in-chip compilation is.
I had imagined the advantage being that the program can be changed and developed "stand-alone" without a development environment and toolchain.
But as I look at it, the source (word definitions) are not in the chip. They must be stored on the PC, and in reality a special tool FF-shell is needed to keep a copy of words as you define them.
The use case I can imagine of coming back to a device in X period of time, and modifying it, is really not possible without the source.
Am I missing something?
In this case, is there an advantage over a hosted forth?
What do you mean by a hosted Forth ?
A normal Forth on a PC would lack the interactivity that the target interpreter/compiler gives you. It would be a cross compiler.
A standalone Forth with full development support would take too many resources from many 8/16 bit microcontrollers.
It would be nice to have one though. Some eeprom or SD card for source code storage and an editor would be needed. Especially the larger PICs and Atmegas could have the file system and the editor code in the flash areas which FF can not address.
An umbilical Forth would provide an interactive target and a compiler on the PC.
In order to be able to use an interpreter, you have to maintain a valid memory map on the host for each target version. That memory map can easily be lost. It is also more tricky to write code using an umbilical Forth.
A on-chip Forth can compile on the target and it can be used just with a simple terminal emulator. And you can have the source files on the PC with its better editing capability.
It also works out of the box without any special software on the PC. FF-shell is optional.
But some terminal emulators work better and some worse. With HW flow control you can use any terminal emulator to send files to the target. With SW flow control you need to use delays and/or end-of-line flow control.
The USB PIC18s always use HW flow control and works with any terminal emulator.
An improvement I would like to have in the ff-shell is directives for include files, a la Amforth-shell. That would support dependencies between source files.
And directives to send only specific parts of a source file to the target.
For me the main use of FlashForth is the control, test, debug various hardware connected to a microcontroller. And to do forth and assembler programming with an interactive interpreter.
All in all I prefer to keep the Forth source code on the PC.
Last edit: Mikael Nordman 2018-04-17
[btw, I understand that ff works for you, I am mostly exploring my own ideas for what I am doing, not asking you to re-engineer what works fine for you]
Umbilical compiled is what I was thinking of.
Do you mean for the user, or the system coder? I would have thought it was the same for the user.
Is this not really the same either way: If you lose the source on the pc, you still can't make changes.
Interactive umbilical compilation looks the same to me as a user: the compiler generates opcodes, and a subroutine writes them into program space and calls them. The only difference is whether both these steps are on the same chip. (btw, I havn't tried one, so maybe I'm wrong)
I do see the theoretical advantage of it working with just a terminal, but if you have to download a special enviroment either way it seems to evaporate.
I remember how horrid line editors were, so an onchip editor doesn't seem like a great plus, although single line word definitions would be much more editable.
I think that on chip source would be a plus. I was thinking about could it be stored in I2C, but just yesterday I was looking at Microchip, and noticed that small PIC18's have gone from the selector, (18F14k22) , and what I was looking at 2xK42 have huge memory available.
Saving source code at the top of memory would be viable. In fact having compiler/interpreter, symbol table (word names), and source at the top of memory, would allow easy deployment of production clones of final firmware onto smaller chips without most of the wasted overhead.
For the simple task of keeping firmware, perhaps you just need a word that can be used to dump the source from the editor to the top of flash, and get it back again. (i.e. not something that the compiler does all the time). This would mean that source could travel with the device, and thus be modified later without PC files.
I imagine a good umbilical system would be really easy and good to use. I have never tried one either. I was thinking if you write an umbilical system on top for example gforth, it will have different modes for the forth words. Words can be executed on the host or on the target.
But a dedicated umbilical system that just talks to the target would be the same to use, or actually better.
Are you planning to build an improved system of some sort ?
Not is a general sense, no. I am considering forth for pic16F for my own purposes.
What I am doing on PIC is coded at low level, but it is gradually growing a set of stack primitives, amongst other things it helps with simple macros. I am aware that what will end up happening is re-evolving forth. So at what point should I just put a forth system in? A token forth may be better for my purposes as it is so easy to use as macros from data memory. Anyway that is in the future, and will be for my needs, so unlikely to be general.
I am also helping the kids with basic embedded stuff at school, which is on a few different platforms. Forth has an appeal here. But the thing that I have found working with kids, on a range of software tools (not just embedded), is just how difficult it is to start. Little (almost none) open source works properly out of the box. Got to stop now, and breathe deeply, I'm starting to foam at the mouth and rave.
Anyway, I would rather work with FF for now, rather than reinventing the wheel, and understand why you are doing what you do.
I am happy to add FF support to Realterm and help that way, if there are any windows users.
At the moment FF is not really usable for my kids compared to PICAXE. This down to the terminal/ide/where-is-the-source side. So unless there is a windows forth shell, I will improve Realterm for my own use, as there are some changes that will be generally useful as well as useful for FF. If I get any replies to my Realterm thread then it might get more effort.
Posting your intentions on the mailing list may give you more audience.
Yeah, not much response so far eh?
BTW looking at the ML, I noticed this:
I think other people would find it good to be keeping the source in upper memory. Given the memory space in 18F2X42's , I don't imagine many users/projects filling even a fraction of 32k, never mind 128k. Why not use it to save the source?
I can see two sorts of use cases:
You can use X! X@ to store and fetch data in the unused areas of the chip.
For storing you need to have a working flow control scheme. The PIC18 CPU will halt during storing into a flash page. Optimally you would store one aligned flash erase block at a time.
The flash block size in all supported chips is 64 bytes. There are some new large chips with 128 byte flash block size, but those are not yet supported by FF.