Programming in Tachyon
David Betz
Posts: 14,516
I'm trying to understand how programming normally gets done in Tachyon for small to medium sized projects. I'm asking this because I used an interactive environment with a Javascript-like language a while ago and we typically did most code editing on a PC with a standard code editor. We would then download it to the target and use the interactive nature of the language more like a programmable debugger than a development environment. Is that how Tacyhon is typically used or do most Tachyon users work entirely on the target board using a Propeller-based editor and storing programs on an SD card? I've used Tachyon a little myself but I've always just typed small programs interactively to play with the language. I suspect if I wrote something of any significant size I'd want to use a PC-based editor for the initial code entry and maintain my sources on a PC.
Comments
I made a Forth system once that had twin 3" (not 3.5') floppies and I would edit the code in "blocks", workable but not nice at all. Most Forth code is written in a proper editor and then I copy and paste into minicom. In fact I do a lot of my code in Google docs as I like to format the text and insert images and tables etc. When I copy and paste then only the text ends up being passed by minicom. Mind you all the code is still in text form on my PC/Dropbox and I use "medit" a lot too.
Although it's possible to make a completely stand-alone system I don't think it's practical as the Prop only has 32 I/O, 32K RAM, and no bus although a Prop configured for this could be used to edit code and talk to a target Prop without a PC. But this is the age of the tablet/smartphone and I have DroidEdit amongst many other editors and terminals to boot so it is easy to just use Bluetooth in the field.
When you're in interactive mode, I assume the dictionary/symbol table has to remain resident in the Prop and that it can consume quite a bit of RAM. But when loading code from an external editor, is there any way to ditch the ASCII symbols themselves, in order to save memory, since they're no longer needed for code execution?
-Phil
Well it's true they take room and if some are not required after compilation then they can be reclaimed as normally these ones are marked "pri" instead of "pub" but still in a fully loaded system they could take 8K. But on the other hand the bytecode is very compact and it packs a lot of punch in a small footprint. The dictionary for the kernel consumes 2.5K alone and I have thought of ways to put the dictionary into upper EEPROM or SD at least and maintain a dictionary cache in RAM of around 2K. But this would also slow down compilation which via serial is only timed although through the SDFS it can load as fast as is possible. So at the moment I get by using upper EEPROM to store all those wordy PRINT strings which is easy enough and saves around 2K. As we all know in P2 we won't be so constrained with memory (we hope!). I'm trying not to make the P1 version overly complicated with all these schemes