Why use SPIN?
davidsaunders
Posts: 1,559
I am fairly new to the propeller.
What is the advantage of SPIN? I do not see one, though there must be one, beings that so much code is written in SPIN.
Having looked at spin I can not see any good reason to use it. Propeller asm is much simpler, and quicker to develop in, as well as creating much faster code. Even if you have to load in code from hub RAM from time to time, due to the limited cog mem, the execution time just goes up to 32 to 48 clocks per instruction, in the worst case while loading instructions from hub RAM.
It may just be me, though I do not think I could get used to spin, when Propeller asm is so much simpler to work with.
Also why does not Parallax release a variant of the propeller that does not start up with the spin interpreter, so that we do not have to kick it out at the beginning of every program? This would not require any change to the hardware, just a small mod to the firmware.
What is the advantage of SPIN? I do not see one, though there must be one, beings that so much code is written in SPIN.
Having looked at spin I can not see any good reason to use it. Propeller asm is much simpler, and quicker to develop in, as well as creating much faster code. Even if you have to load in code from hub RAM from time to time, due to the limited cog mem, the execution time just goes up to 32 to 48 clocks per instruction, in the worst case while loading instructions from hub RAM.
It may just be me, though I do not think I could get used to spin, when Propeller asm is so much simpler to work with.
Also why does not Parallax release a variant of the propeller that does not start up with the spin interpreter, so that we do not have to kick it out at the beginning of every program? This would not require any change to the hardware, just a small mod to the firmware.
Comments
If assembly is adequate for your needs, by all means use it.
The Propeller uses masked ROM where the bits are designed into the wiring on the chip. It would be expensive to produce a 2nd mask without the Spin interpreter and there would also be the costs of stocking two separate variations of the Propeller. It's hard enough to predict and balance the stocks of the various packages.
To start up an assembly program requires about 16 bytes at the beginning of the program and maybe 120us of additional initialization time to load a copy of the Spin interpreter into a cog that isn't really needed. That's not much overhead to have a programming tool like the Spin interpreter available when needed.
First off, this port belongs somewhere else like Suggests to Parallax or General.
Secondly, I’m very tired of posts that stir up the language debate.
SPIN is a tool that a programmer can use to program the Propeller. It has syntax, excellent documentation, and many examples. If you prefer to use PASM to SPIN then use PASM. There is also Catalina if you want to program in C.
In my career, I’ve had program in all kinds of languages. I’d prefer to use one language forever and ever… but that’s not going to happen.
Ok I understand that many use and prefer spin. I have no objection to spin. As to the cog mem limit see the initial post.
As to your statement about two separate variants, That is not at all what I was saying; I just think that it would be better to load an asm program by default and use a 4 or 5 instruction propeller asm prog to load the spin interpreter, as the overhead is not as significant for spin.
The intent of my post was to try to understand the pros and cons of Spin as I do not get a clear picture from the documentation and examples, as well as some understanding as to why the spin interpreter is loaded by default rather than visa versa. I am not recommending a modification to the current Propeller, though I would like it if this were considered in the prop II.
I use byte code interpreters for some things, for some things they are the best way to go. I just do not yet understand the utility of spin and am trying to learn.
Mike G: I hope this helps also with your concern. My goal here is to learn, NOT to stir up some arbitrary language flame war. I have seen to many of these (I have always believed a well designed BASIC Compiler can produce better optimized code than most other langs, due to the closer similarity of BASIC to the various Machine langs).
1. It's supplied in the ROM, so it can be memory lean.
2. Big programs. The alternative here is LMM, or C, or PBASIC that build LMM for you.
3. It's well matched to the hardware. SPIN has lots of operators and the booleans mentioned on the other thread that all align well with the Prop.
4. For me, it's simple and fun most of the time!
5. For me, it's plenty fast. On many things, SPIN runs about as fast as a 6502 does in native assembly.
6. It's lean. I really like this compared to something like, say C. I can write in C, but I'm not all that good, and C is "thicker", not "lean" like SPIN is. For quick things, or just to code up some idea, SPIN is really easy. Lean in terms of the amount of input required to build instructions.
7. Because it's lean, and because of how the prop works, using multiple SPIN objects to get something done is also lean, and that helps to leverage the OBEX. I find it striking how simple it often is to grab a few things, and then write the smaller bits of code to make them do what it is that needs done. I think binary coded objects will help extend this to other languages.
8. If using Prop Tool, or BST, SPIN + PASM is robust, and rather clean and flexible. Rather complex things can be made, and done in one file, if a person wants to. One file is kind of nice for a lot of reasons.
Given how the chip operates, it makes the most sense to have some interpreted language available to the programmer. Now that we've gone and boot strapped up a bunch of stuff, PBASIC, C, for example, can replace SPIN for most of the above, depending on the programmers perception of the overall benefits.
I'm about to leave SPIN for a while, after I complete the projects on my plate. Catalina and Dracblade are a compelling combination, where bigger programs are possible and IMHO, beginning to get practical. IMHO, SPIN keeps the prop behind in some ways that C does not. If one is to use the prop more like a little mini-computer, I think SPIN falls short, unless the scope of functionality fits within the Prop native resources.
*Need to get comfy with C again, as I think I will be doing some iOS stuff here in the near future. Why not get a lot of that done on the Prop? (I know iOS deviates from the C we have here, but the basics are the basics, and that's what I need to get up and into "running memory" for me personally again!)
The SPIN interpreter is loaded by default so that the Prop starts in a environment that makes the most sense for SPIN + PASM. The intent wasn't to have the chip be all PASM. SPIN was there to provide the control structure, while PASM does the heavy lifting. We've gone and pushed it all way past that, which makes the default load seem goofy, but it wasn't at the time. I asked the same exact question, as did many others. We've got it answered now, where SPIN is not needed at all, but to get the chip to boot and hand control over to whatever program is running.
That applies more to C than BASIC, many processors (not the Propeller) are designed to execute C as efficiently as possible.
You might have to explain that statement a little. The 68k and x86 were for sure designed with high level languages lile C in mind. While BASIC was traditionally interpreted and did not much care what was underneath.
A person who thinks and dreams in hex and binary.
Some people just get overwhelmed with that and prefers a Basic type of language.
For a very long time, I struggled with the COG program limit, thinking the chip was hobbled. Now, particularly after Bill realized LMM, it's a different story.
We are here now, but there was a lot of real boot strapping to get here. Somebody should go back and put the first coupla years of the forum into a book! It would make a very interesting read. Educational too, IMHO. Many of the regulars here did some real comp-sci. The prop is interesting to me on that level, because it's quite rare to see a really new CPU, and one designed by a single person is unheard of! That Chip got it right too is nothing short of amazing. I have enjoyed watching the boot strapping happen immensely. It's like being back in that late 70's, early 80's time again! Too much fun!
By my recollection, the big door opener was getting close enough to the SPIN code in ROM that Chip decided to give it to us. That more or less documented the language, making all sorts of tricks possible. Another big one was LMM, where a small PASM kernel fetches and executes PASM from the HUB. That's literally a virtual, or supervisor mode on a MCU, and opened the door for a whole lot of things to follow. Big, and fast programs became possible at that point, and SPIN could be replaced, and was! Honestly, that also brought us the pin shortage as the chip could easily make full use of 64 or even 96 pins! Throughput on these things is nothing short of amazing, IMHO.
External memory interfaces, and the structure needed to make use of them in a general purpose way was kind of the last frontier for big programs, and we are right there now, with various interfaces created, and the boot strapping done so they can be used in a sane way, not custom bit banging. C makes a lot of sense now because of that, IMHO. Prior to that innovation, the 32K memory was tight enough to really pay attention to how much bigger LMM was, compared to SPIN.
It's actually pretty amazing to see where we are right now, looking back to the beginning time. For me, it's been a fun and very educational ride along the way. For people just arriving, I can totally see where it all looks somewhat goofy. It is actually! But that's not a bad thing, IMHO. It's just a different thing. Truth is, Props offer a LOT of choices. Everything costs something, but nearly everything is possible too, so the developer can realize multiple approaches to solving the problem. I like that about the Prop the most. It's clean, simple, but at the same time, very complex, because of how the multi-processing and COG memory space / HUB memory space really work.
One could, if they chose, run SPIN in one COG, have another few COGs running PASM to provide services and peripherals, yet another COG executing compiled LMM, and another COG running a very large program out of external memory XMM, and all of that can run concurrently! Dr_A, Ross, Jazzed, Heater, et al. have basically got us there, and I'm quite curious to see how that all ends up playing out. Or, one can go to the other extreme, and have a small SPIN program directing all the COGs hard at work doing computations, or something too. Somebody here wrote a simple fractal program. It was trivial in SPIN to simply clone that computation, and put 4 COGs all to work, each writing to the screen buffer as they got done, with a 5th COG drawing the screen to see. That kind of stuff is just goofy simple on a Prop, and it's powerful too. I would not even think of attempting it on more complex designs, and for me my bias is hobby / consultant kind of work, not production engineering..Just to put all those comments in perspective.
All of that said, you should look hard at PBASIC too. It compiles down to LMM, and it's fast because of that. The general consensus is that SPIN is too slow for a lot of things that it would otherwise be useful for. Guess that's a matter of expectations, and the kinds of stuff people try to do with it. PBASIC was rapidly adopted and used by several here with good success, because it has a significant speed advantage.
I think that's the hardest thing about the Prop. It's a fast chip, but one has to do some planning to put the real speed and throughput it has to work in the right places and at the right times. How that's done is not always a straightforward exercise.
OBC
GOSUB = CALL or JSR or BSR
GOTO = JMP or BRA
RETURN = RET or RETURN
ASSIGN = MOV, MOVE (advantage of not have multiple assigns in an expresion)
expressions are much simpler to translate (and usually can keep up with C) as most ANSI BASICs only support 2 level expression embedding.
ETC....
Ok some high level stuf has a bit more over head, though since they are builtins PRINT, INKEY$, INPUT, etc.. can be implemented more efficiently than using function calls (Witch the ANSI C standard requires). I do not think that the ANSI BASIC standard requires any specific method of string handling so using static length BYTE arrays should conform. I may be wrong though I do not think that the standard prevents type declaration (and most BASICs do allow type declaration) so this is not an issue.
The one area that structured basic falls short is in Function/sub/procedure calling, witch is an area in witch most high level languages fall short (including C). This is because of the number of stack ops required to pass parameters.
I think you and Chip would get along famously. His Spin compiler is written in x86 assembly!
-Phil
Both have their place and both should be used together to
get both fast execution and fast development.
Using PASM to do something very simple that could be easily
done in SPIN is like using a rocket sled to get to the mailbox.
Agreed. But then again, they will get network stuff down, won't they?