Calling assembly from spin, why not
ypapelis
Posts: 99
So I have been using the propeller chip for a couple of weeks now and really like the straightforward architecture and ease of use. However, I have this nagging question, to which I know the answer but I do not fully understand the underlying reason for it, so I hope people with far more experience and understanding on the propeller can shed some light for me.
The issue is within calling assembly from spin. In most other environments I have worked with, you can mix assembly and high level pretty easily, either by putting assembly code inline or by simple calling the assembly function as if it were any other function.
My question is, why can't we do the same between Spin and Pasm? I realize that to run code in assembly you have to launch it in a new cog but this has a lot of overhead and sometimes it would be nice to just call a simple assembly routine to do something specific but maintain the ease of using spin for the remainder. Something like the spin interpreter being aware that a function is in assembly so it setups the call frame and switch into 'pasm' mode, then the last pasm piece of code would revert back to interpreter mode allowing it to continue from where it left of.
Thanks --
The issue is within calling assembly from spin. In most other environments I have worked with, you can mix assembly and high level pretty easily, either by putting assembly code inline or by simple calling the assembly function as if it were any other function.
My question is, why can't we do the same between Spin and Pasm? I realize that to run code in assembly you have to launch it in a new cog but this has a lot of overhead and sometimes it would be nice to just call a simple assembly routine to do something specific but maintain the ease of using spin for the remainder. Something like the spin interpreter being aware that a function is in assembly so it setups the call frame and switch into 'pasm' mode, then the last pasm piece of code would revert back to interpreter mode allowing it to continue from where it left of.
Thanks --
Comments
http://forums.parallax.com/showthread.php?103827-Call-Assembly-from-Spin-How&p=728379
It's mostly an issue of space, the interpreter more-or-less takes up most of the cog RAM leaving very little space to add useful assembly and you cannot execute assembly by fetching instructions from main RAM.
I wonder if with the Propeller's 2 increased cog memory, if that would be possible then? I guess we'll have to see.
The cog that runs the spin byte code in real time is using up all the 4k cog ram
So where would you put any inline asm code anyway?,the answer is in another cog.
Each cog has 2KB of cog ram which equates to 512 longs. 16 longs are reserved for special registers, so the normal pasm instructions are limited to 496 instructions including data. There are techniques to get to some of the 16 longs that are shadowed by the special registers.
Prop II does not add any more although the number of registers may be less than 16 so we may get access to a few more instructions than 496. The Prop II does have fifo style memory (IIRC 512B) which may be used for storing data which might otherwise take space in the normal cog ram.
Basically, as said before, the cog actually runs the spin interpreter as a pasm program and all 496 longs are used! However, as Dave has done, there is a mechanism for running pasm inline in spin, but it will be slower running LMM than real pasm because each pasm instruction is fetched from hub before it is executed.
http://obex.parallax.com/objects/635/
http://obex.parallax.com/objects/665/
Massimo