SPIN vs C???
jmbertoncelli@USA
Posts: 48
Hello,
I have a very simple question about the future of the SPIN language vs. the C compiler from ImageCraft.· Does it make sense to go with "C" because of the wide spread "C" usage for embedded systems and more or to use SPIN and learn a new language that is used for the Propeller only???
thanks.
jm.
I have a very simple question about the future of the SPIN language vs. the C compiler from ImageCraft.· Does it make sense to go with "C" because of the wide spread "C" usage for embedded systems and more or to use SPIN and learn a new language that is used for the Propeller only???
thanks.
jm.
Comments
It all depends on your needs. Spin is interpreted. C is compiled. Spin's binary will run about 4 to 8 times slower than the equivalent C application. A C application is about 3.5 times bigger than the same Spin app. Spin and C address different needs; choose what makes sense for your project. A good C programmer should have no problem learning most of spin in a week.
In the future, a follow-on Propeller (PropII) may be available with greater internal memory, cog, and hardware pin resources; this has been spec'd by Parallax in the forum. Such a product would allow a clean interface to practiacally unlimited external memory. Using C at that point will be more meaningful. Using C with today's Propeller is fine, but there are limits.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Graham
There's been previous discussion and comparison of Spin and ImageCraft C and Jazzed sums that up quite well above. The best thing about knowing two or more languages is that you always have choices, which you prefer and what works best for a specific application.
When the Propeller Mk II arrives, ImageCraft C will come into its own and should shine. The current Mk I is more constrained but that doesn't make C unusable and early adoption should put you ahead of the curve.
As languages go, SPIN is easy to get the hang of.· PASM on the other hand, is one of the more difficult assembly languages to learn do to the lack of indexed and indirect addressing and the self-modifying code required as a result.· It's still worthwhile to learn them all in my opinion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The problem I have with spin right now is: while there is an extensive library of objects that can be embedded at compile time, adding libraries "as is" at run-time or starting a .spin binary on top of an existing .spin app does not seem possible.
I've looked at the Femto model, but unless I'm mistaken, that appears to start a new application as a wholesale replacement of the current app, rather than using an executive. Steven's DOL Dynamic Object Linking code allows one to use .dol objects in their definition, but it falls short of what can be done with C static libraries program (although not being done as of now, it's just a matter of time and not design constraint). I have yet to see an app that can start with embedded spin objects with DOL ... again maybe I've missed something.
Why is wanting to load/use binary modules at run-time important? Well, it is not for small programs. The difficulty comes with growth. Download times increase and some say, "that gives me time to reflect/multi-task/get coffee" [noparse]:)[/noparse] If I have to build/download an entire linux embedded system for testing bug fixes (and I've had too), I would lose interest fast (and I did) without kernel loadable modules or lib*.a/lib*.so ability. It will seem like a trivial problem to the un-annointed or the holier than thou crowd (just analogy folks), but this is a monster productivity eater (the bigger the embedded image the bigger the monster).
Thus, I challenge Parallax with the best of intentions to come up with an easy way to dynamically add objects or entire spin binaries in the next (or current) incarnation of spin.
Thanks,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (jazzed) : 7/18/2008 9:03:57 PM GMT
Spin is fine and not too hard to learn as well as the already mentioned object library.
What would be great is a spin source level debugger/simulator with break points, single step, variable watch and memory view.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I've been playing with various spin bits and pieces and having a *close* look at the interpreter code.
Spin appears to be *completely* position independent. It's all about how you set the startup variables for the interpreter.
If you were to take a .bin file. Hack off the 1st 2 longs and alter the next 5 words to tell it where you were going to position it in RAM you should then be able to do a coginit with the spin interpreter and have it start up.
It *should* be as easy as load the entire .binary file. Add your ram offset to word though word[noparse][[/noparse]8] and coginit with par pointed at the address of word. (Starting from word[noparse][[/noparse]0] of course) - that says word<bracket>4<bracket> through word[noparse][[/noparse]8] but something keeps buggering up the formatting!
You of course need to load the binary where the main spin program won't trample all over it somewhere high in ram, and with enough space after it for the variables and stack, but in theory it should "just work".
something like
load_file('blah_spin.binary') at address $4000 ' However you plan on doing that
word[noparse][[/noparse]$4004] += $4000 'pbase - Object Base
word[noparse][[/noparse]$4006] += $4000 'vbase - Object Variables
word[noparse][[/noparse]$4008] += $4000 'dbase - Object Stack
word[noparse][[/noparse]$400A] += $4000 'pcurr - Instruction Pointer
word[noparse][[/noparse]$400C] += $4000 'dcurr - Stack Pointer
cognew ($F004,$4004)
Now, I'm sure as hell not certain as I've not (A) tried it, or (B) needed to try it, but I'm in the middle of writing a spin disassembler and this all kinda
adds up with what I've managed to get thus far. Hippy would probably be the best one to ask.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Post Edited (BradC) : 7/20/2008 12:19:15 PM GMT
word[noparse][[/noparse]$4008] += $4000
and so on.. forgot there are 2 longs at the start of the binary.
Figured out an easy way to test this..
Write the propeller demo or something to eeprom.
Write a spin program using the i2c driver to load the contents of eeprom at $3000 or therabouts..
do the fixups and launch..
Load and run the spin program from ram, and if its going to work it will load the image from eeprom, fixup and launch.
If not then I've made a fundamental logical error (nothing new there!).
If nobody beats me to it I'll try it when I get home from the office tonight.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
CogNew as always takes two parameters to launch PASM, in this case; first the start address of the Spin Interpreter ($F004) then the address of the Parameter Block ($0004). Your CogNew($F004,$4004) should work fine, mine did. Change $F004 and you can run a RAM Spin Interpreter.
I used these techniques with Cluso99 to transparently use a RAM Spin Interpreter, for inserting data into an image and for platform independence pindefs - Copy $0004-$000F elsewhere in the image, fixup $0004-$000F to run some inserted Spin bytecode to do as it needs then restore what was; after a 'virtual re-boot' what's in Ram looks like what was saved before the image got messed with.
On position independence; it's not all 100% 'relative to self' as I'd call truly position independent code. Some code is relative to 'start of code module' so you couldn't just swap two methods around in the image and swap links/pointers to them and have it work or remove an unused method and slide the rest of the methods down to fill the gap.
I'm not sure of all bytecode that is relative to 'start of code module' but part of LookUp and LookDown are. Such code is relocatable with a fixup, just a bit harder to do.
@ Cluso99 : I've got some experience of Spin to bytecode generation so I'll be pleased to help in the other thread.