Why interpret Spin?
Stan671
Posts: 103
Don't get me wrong, I am not complaining - I am just curious.· The Propeller is a excellent example of design and implementation for a new microcontroller.· I am just asking in the hope of getting the developers to share some insight into the millions of decisions they had to make during the development process.
Since Spin is customized for the Propeller's processors and has a very efficient conversion to machine language, it would seem to make sense to compile Spin code only once (on the much more powerful PC) and download machine code into the Propeller than it would be to just tokenize it and have to interpret every instruction over and over again as the programs are running.
Also, it would seem to simplify the processors and the boot process if there was no need for the Spin interpreter.· The Propeller could be much simplier if it only had to deal with machine code and not with Spin·inside the chip.· And, of course, all programs would run at full machine code speed.
So, there has to be a very good reason for the dual mode (interpreted, tokenized high level language and machine code) inside the Propeller.· My guess is that it has to do with conserving memory and with the speed of accessing the shared memory by the cogs via the hub.
If a Spin instruction requires 100-500 machine code instructions to execute it, Spin programs compiled into machine code would probably be 100-500 times bigger than a tokenized Spin program.· It would seem that the 32K of RAM would probably fill up rather fast.· So, one reason to tokenize & interpret would be to save memory at the cost of execution speed.· But, considering that the Propeller can do·something like 80,000 Spin instructions per second, I really don't see that as too much of a down side.
The other thing probably has to do with the cog running the interpreter within it's own memory map and not needing to go to the shared RAM until it needs another Spin token or data.· If it had to wait for it's turn at the·hub for every machine code instruction it had to operate, machine code would not run nearly as fast as it does entirely inside the cog.· So, by having machine code only run inside the cog, it runs much faster than it could from main memory.
I am just opening up a discussion here - the same one I would have if I was at the training class.· Hopefully, the developers of the Propeller will chime in and let me know how close or far off the mark I am.· I find these kinds of dicsussions fascinating.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Stan Dobrowski
Since Spin is customized for the Propeller's processors and has a very efficient conversion to machine language, it would seem to make sense to compile Spin code only once (on the much more powerful PC) and download machine code into the Propeller than it would be to just tokenize it and have to interpret every instruction over and over again as the programs are running.
Also, it would seem to simplify the processors and the boot process if there was no need for the Spin interpreter.· The Propeller could be much simplier if it only had to deal with machine code and not with Spin·inside the chip.· And, of course, all programs would run at full machine code speed.
So, there has to be a very good reason for the dual mode (interpreted, tokenized high level language and machine code) inside the Propeller.· My guess is that it has to do with conserving memory and with the speed of accessing the shared memory by the cogs via the hub.
If a Spin instruction requires 100-500 machine code instructions to execute it, Spin programs compiled into machine code would probably be 100-500 times bigger than a tokenized Spin program.· It would seem that the 32K of RAM would probably fill up rather fast.· So, one reason to tokenize & interpret would be to save memory at the cost of execution speed.· But, considering that the Propeller can do·something like 80,000 Spin instructions per second, I really don't see that as too much of a down side.
The other thing probably has to do with the cog running the interpreter within it's own memory map and not needing to go to the shared RAM until it needs another Spin token or data.· If it had to wait for it's turn at the·hub for every machine code instruction it had to operate, machine code would not run nearly as fast as it does entirely inside the cog.· So, by having machine code only run inside the cog, it runs much faster than it could from main memory.
I am just opening up a discussion here - the same one I would have if I was at the training class.· Hopefully, the developers of the Propeller will chime in and let me know how close or far off the mark I am.· I find these kinds of dicsussions fascinating.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Stan Dobrowski
Comments
In any learning curve situation you have more beginner's than experts.· So why release a product to merely a few people that have the expertise to make it work, when you can release it to nearly everyone with a desire to learn?
From what I understand, the IDE will allow you to purely use Assembler if you are one of those that can.· Jump in and enjoy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
-Parsko
Right now, I really have no idea of what parallel processing means to me either. It is a big exciting puzzle.
But, having an opportunity to use something is the usual way I learn things.
It certainly doesn't hurt that I can nearly immediately create a video terminal with keyboard and mouse from this one chip.
I would probably never have gotten very far into Assembler without Parallax, the SX chips, and Guenther's text. But, I stay involved because there is support and fun.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
With all that said, if one thought in Machine code (which is the same as assembly?), then one could write some wicked fast parallel processing control systems.
-Parsko
Yes, they are the same.
'Assembly' generally means the 'readable' code in your source files
(Those cryptic LD/MOV/INC/DEC/MUL instructions) while 'Machine Code' is used about the resulting binary files.
As there's a 'one-to-one' translation, people(myself included) often doesn't bother with the difference, which can of course cause a bit of confusion for those not trained in the dark arts of the Assembler...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
1+1=10
I am not advocating getting rid of Spin and just have Assembly.· A compiled Spin would be just as user friendly as an interpreted Spin, so that is not the issue with my discussion.· I am putting forth the·question·of whether the Propeller chip could be architecturally simplier and perform better if it only ran machine code and Spin was compiled rather than interpreted in the chip.· Therefore, there has to be a good reason why the developers took this route.
A theoretical Spin compiler would not need to understand the complex task of parallel processing because it would only have to think in terms of the program running in a single cob - just as we think now when we write a Spin program.· Sure we can launch different programs into different cogs, but each of those programs is a single processor thread.· It is the synergy of the 8 processors and the hub working together that makes the entire computer multi-processing.· That is the beauty of this thing - the user does not need to be a genius in parallel programming to use it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Stan Dobrowski
Post Edited (Stan671) : 4/30/2006 7:29:26 PM GMT
There is no stack in Assembly language, only in Spin.
No PUSH or POP instructions, and the CALL equivalent stores the return address in the RET instruction...
Performance-wise, the Propeller has all the Ooomph it needs. it does 80K tokens/s with a single COG.
Given that the fastest of the BS2 series odes 12K or so...
Simpler?
But it IS simple.
It's so simple that it passes over to the other side...
And I think Chip thought VERY HARD and VERY LONG about Spin.
(I can't wait to take a peek at the innards of the interpreter... )
The problem with a COMPILED Spin is that you end up with machine-code, and that has to fit into 512 Longs, with room to spare for variables.
If the module is to be bigger than that, the compiler needs to break it up into smaller chunks that can be loaded into the COG on demand, which can be even more inefficient than interpreted Spin.
And THAT is the final beauty of Spin, the objects can be as large as they need to be.
(Less variable and Stack space, of course)
That was one of the shortcomings of the BS1 and BS2, that you had a very limited space.
In the Propeller you have 32KB for Spin, or if you use either Assembler, or Spin and assembler, you could have extra machine-code modules stored on an I2C EEPROM, and load them into COGs on demand.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...