Which Language for Prop projects
richaj45
Posts: 179
Hello:
I want to use a language that is faster than Spin and the two i see are: PropForth and Catalina C.
Can any of you answer these question regarding those two languages.
1) Which one has faster code?
2) Which one works with the BST tools on a MAC?
3) Which one integrates PASM the best into its language?
4) Which one has the best support?
5) Which one is easiest to get up and running?
Thanks for your feedback.
rich
I want to use a language that is faster than Spin and the two i see are: PropForth and Catalina C.
Can any of you answer these question regarding those two languages.
1) Which one has faster code?
2) Which one works with the BST tools on a MAC?
3) Which one integrates PASM the best into its language?
4) Which one has the best support?
5) Which one is easiest to get up and running?
Thanks for your feedback.
rich
Comments
If all you have access to is a MAC, I'd suggest PropBasic. To use Catalina on a Mac currently requires you to recompile it from source (I don't distribute binaries for a MAC).
Ross.
I won't admit to knowing anything about C except that its very popular
I can answer some questions about propforth, but my answers are based on limited experience
Depends on what you are doing and how you code it.
- Propforth has call and a return for each function, if you make lots of small functions, you get more of these. If you make one giant function, you can reduce these call/returns but a single big functions is more difficult to maintain. Typically one makes lots of little functions, and combine them as needed after you know whats going on.
- Also, there is an optimizer in the works for propforth; it turns out that proper development coding tends to generate a noticeable amount of null ( "dup drop", noop, etc) sequences which can be factored out in the final applications. Normally these have little impact, until you get very time critical an/or space constrained. The optimizer will be ready by August, we think.
- Finally, the FORTH development rule of thumb is "get it running fast using forth; make it execute fast using assembler". IT turns out that something like 90% of execution time is spent in 10% of the code. If one can determine the areas of code that execute the most and optimize these, you get an giant speed increase. These area are usually optimized in assembler for maximum benefit. The forth disassembler and assembler are handy for this.
I believe one of the primary propforth users, Brian Riley on these forums, uses BST on a MAC for propforth. At least I know he uses a MAC, and I think BST works on that.
Since the propforth kernel is a spin file [PropforthKernel.spin], it works just fine with any tool that works with spin. The difference with FORTH is that after its running, you mostly don't need to use the PC for anything except for terminal and disk service, usually via telnet or Ethernet. So you generally don't even use any spin tools after forth is loaded, you just telnet to the interactive forth prompt and get to work. BST or proptool play a very minor part unless you do something fancy, like 1) alter the kernel or 2) mix spin routines and forth routines and have them call each other. Item 1 is very easy but generally not needed except for kernel development, which is best left to advanced users (e.g. Sal Sanci). Item 2 is possible (Sal says he did it) but the spin objects do not always follow standard interface rules, so it becomes problematic in that respect. We haven't found a case where it is beneficial to mix OBEX spin routines and forth as of yet.
The FORTH Assembler is really nifty in the way that assembler fucntions can be loaded directly into the cog and do not take up space in the dictionary in main memory. The software Logic Analyzer fucntion is a good example of this (LogicAnalyzer.f or la.f depending on which release you download)
In forth, you code the function in forth. You look at the assembly listing for the code. You optimize the assembly code so it ONLY does EXACTLY what you want, and not extra yutz. You put the sequence of byte values into an assembler definition. When the assembler definition is loaded, a HOOK (or is it a STUB?) goes in the main dictionary, and the actual executable only goes into the cog(s) running it, so you must make sure that non-loaded cogs don't try to call it
I don't know enough about how assembler routines are handled in plain spin, C etc. to make any comparisions.
Propforth is only supported by the developer and six other people. The developer, Sal, is pretty sharp; the documentation, mostly from me, is pretty weak, but I try to get questions answered if they are have enough information to pursue.
I haven't tried Catalina support, but I gather that guy is pretty sharp and on the ball too.
Prop forth takes the time to download propforthkernel.spin to the prop (using proptool, etc), and the time to download and install telnet to the PC and set the baud rate to 56700.
Under a minute start to finish for me, usually ten minutes if you follow the instructions first time, maybe a half hour max for somebody that doesn't know how to Google "telnet download" and read instructions.
All that said, spin is pretty clever, and is pretty fast. It has its own set of weird rules, which are different than forth' s set of weird rules, so that part is a wash. If you want an interactive development environment directly on the prop and can handle using the stack instead of passing named parameters, you want forth. If you don't need interactive or can afford an expensive PC and/or a fancy IDE like ViewPort, and you want C, then you want C.
The whole thing is subjective, and depends on what you want. Stated another way: If you don't know what you want the default is spin; if you want to use the most common language across all hardware, you want C; if you want interactive and the shortest development cycles, its usually forth.
Propforth v4.5 is coming out in a couple weeks, this version totally kicks butt all the way down the block and back again. Please consider giving that a try before making a decision.
Spin/PASM are the "native" languages of Propeller. They were designed for Propeller of course which means there are certain advantages to using them. One big advantage is that it is a well known quantity. Spin does not support HUB memory size > 64KB though (32K RAM + 32K ROM). It is possible to load 16KB for COG code separate from HUB for some memory savings.
Spin was optimized for size, and as implemented is a perfectly good product for Propeller with lots of history.
Spin can be made to run faster with a rewrite, but even with work already done with that focus, more needs to be done.
Spin does not support external memory.
Regarding C:
Catalina C and ImageCraft ICC both support the so called "LMM" interpreter execution model. Code running in that model is faster than SPIN but slower than straight PASM. PASM is 4 to 8 times faster than LMM.
There are no C options for MAC as far as I can tell without recompiling the compiler.
In C today, there is only one way to make and run COG code: use another tool like a PASM assembler (BSTC for example) to generate COG code and start the code as part of the program (code can be stored with the program or on separate media such as SD card).
C solutions do support external memory.
Regarding PropBasic:
PropBasic is MAC compatible (part of BST) and can generate PASM for running on individual COGs and also runs with the LMM model. The only problem that PropBasic does not address is using external memory - there is no way to add that as far as I can tell. It may not be important to some, but I find all my projects to be too big to fit in Propeller memory.
Maybe Bean could answer what his position on supporting external memory might be?
Regarding Forth:
I'm not a forther, so i have no opinion of it.
Another possibility which is a" work in progress" is XBASIC.
XBASIC is a VB6-like language (without objects at the moment) that works on any Propeller in HUB mode, and can be run from external memory for platforms like C3 and the DIP32 size SpinSocket. Other platforms can be supported also.
More on this language will be available as development matures. XBASIC performance is comparable to SPIN/PASM where pre-compiled PASM code will run in a COG. XBASIC on the MAC is possible, but not ready just yet.
I'm not really a Basic user, but have done lots of VB6 programming and XBASIC is enough like VB6 for me to enjoy.
OK, I know I already posted, but the original post did ask about propforth specifically.
Propforth, being extensible, permits expanded memory. We have not added support in the kernel as there are many equal hardware alternatives and none has proven superior to the others, and we simply haven't needed it. Any expanded memory hardware support can be easily added and tested at user whim.
A really cool thing in propforth is the use of SD memory. Current default support treats SD as "internal to forth"; since we don't have to worry about FAT support, it is very fast. Also, files can be used as "script". That is, in addition to containing source code definitions that can be interpreted into the dictionary on the fly, and removed when no longer needed; files can aso contain script sequences that are NOT compiled into the forth dictionary, and are simply executed on the fly. My smallest 1 Gig SD card results in 31,000 k of system memory and 994,810 k of application memory. While it does take time to load scripts (script load has not been optimized), as long as the application is organized correctly, once a script is loaded the (32k max) segments run at full speed.
The primary reason we haven't felt the need for extended RAM support is that by adding more prop chips, one adds more cogs and IO ports, with no particular limit. Adding another prop costs three wires, three resistors, and two capacitors (notice no additional crystal or EEPROM are required). One cog each on the master and on the slave are used for communication, and three IO lines are used. The result is you get 5 cogs and 29 IO pins each time you add another prop. As long as you ensure that time critical functions do not cross inter-prop boundries, you're in like Flynn. Together they act more or less like one giant prop. The multi-channel high speed synchronous serial communication is really cool and does the job well. Of course, you still can't string enough props together to run full motion HD without doing something tricky, it is a microcontroller after all.
One more thing about your "faster code" question: Speed of code is always subjective and dependent on the individual developer. My Forth development time is always faster then my C development time. C developers will likely report the opposite. Developers with "equal expertise in both forth and C" -used to- report (in the 80's) that FORTH development time and execution speed to be faster, but again could be attributable to the 80's C compilers, and we don't have good measure of "expertise". The execution speed of unoptimized forth tends to be somewhat slower than assembler and substantially faster than BASIC (but I don't know about PropBasic and XBASIC), the execution speed of C depends greatly on the C compiler. There is no reasonable standard of measure, it all depends on what you are doing and how you are doing it. Bottom line is the code is only a reflection of the engineering that the developer put into it.
My comparisons on of C, SPIN, and PASM (performance and code size) were based on studies done over the last 3 years and the theoretical forecasts. In some cases, the practice matched the theory perfectly (LMM C -vs- PASM) and in others it did not (LMM C size -vs- SPIN size).
Like I said, I'm not a forther, so I don't know about it and refuse to speculate on it ... (golden rule?).
'
Its super fast.
'
It just needs the Docs and support from Parallax.
'
If have have used the SX and SX/B you'll be at home with PropBASIC.