Spin2
rjo__
Posts: 2,114
I'm starting this thread as a place where suggestions, questions, answers and concerns about SPIN2 can be posted.
My personal opinion is that the multitasking capabilities in PASM2 is the single most important new feature. The reason is obvious: you don't have to stop doing everything else just because you using a wait function. This isn't really as critical with 16 Cogs as it was with 8, but it sure is nice.
I am hoping that SPIN2 has at least limited multitasking capabilities. I raise the issue now, because I have no idea if this feature would require anything in the hardware design.
Thanks
Rich
My personal opinion is that the multitasking capabilities in PASM2 is the single most important new feature. The reason is obvious: you don't have to stop doing everything else just because you using a wait function. This isn't really as critical with 16 Cogs as it was with 8, but it sure is nice.
I am hoping that SPIN2 has at least limited multitasking capabilities. I raise the issue now, because I have no idea if this feature would require anything in the hardware design.
Thanks
Rich
Comments
I am also anxiously awaiting an news of new capabilities of SPIN2, especially any implementation of Tasks within a single Object.
In my minds eye, Tasks should be as simple as have multiple Program Execution Pointer, it would be up to the programmer to keep them coordinated and common resources locked.
See: http://forums.parallax.com/showthread.php/141706-Propeller-II?p=1122712#post1122712
Your memory is better than mine… I NOW remember seeing that thread. FWIW IMHO SPIN2 multitasking would be an essential upgrade for people that primarily code in SPIN2(new users).
For the people that use SPIN to tie all of their PASM code together, I wouldn't imagine it would be quite as important
Yes. I actually posted it because I know that Chip is up all night working on the hardware. So if there is anything there that he needs to massage to make SPIN2
multitasking a reality in the future, now might be the time to do it. Chip has already made changes to how SPIN2 will be implemented, I suspect this is probably a no-brainer.
He doesn't need to respond!!!
Rich
Is this thread directed toward Spin2 to run on the P2, which is on hold or is it for Spin1+ for the P16x64 (P1+) chip which is the current next chip? If it is really for the P2, then there are already two threads I started about features and implementation ideas a few weeka back. There is a bit of Spin discussion in the P2 BLOG that I haven't edited out yet.
If it is about Spin+, then I think it is a bit premature since there are still a few hardware details that need to be firmed up that could impact Spin features.
Chip will probably read it, so it could be a distraction too.
I meant it for the chip currently under production, which I understand(and could be easily wrong) will have some multitasking at the hardware level. As it is right now, if a new user wants to use a wait instruction… that instruction stalls the code until it is satisfied. If there are other things going on in the loop, then those things have to wait. The way to get around this
at the level of Spin is simply to start a cog and do what you want to do in an uninterrupted fashion there… I don't know what kind of multitasking Chip is thinking about at the
machine level, but his previous version was really elegant from the user perspective.
I don't care whether multi-tasking is in SPIN2 for personal reasons… I will be able to do everything I want to do without it. But for people who get stuck at the level of SPIN and haven't yet made it to PASM and objects, I think it might be very helpful… if it is simple and doesn't impact performance when it is not in use.
It isn't worth slowing the current effort … just a matter of deciding if it belongs on the back burner.
As far as I know Spin does not run in a COG.
The Spin interpreter is run by a COG.
So the question is can a Spin interpreter running in a COG run two or more threads of Spin code?
Or do we have two or more instances of the Spin interpreter running as threads in a COG each running a chunk of Spin?
What happens when one of those Spin threads want's to do a WAITPE or such? That stalls everything no matter which way you do the threading.
I don't know, just thinking....about all the worms in that can...:)
Far more more worms than I thought. I don't regret asking the question, but the answer seems pretty clear to me:)
This was the BIG worm I wasn't sure about last night.
Multi-tasking Spin will be a fun feature to have for the P2!
The current P2 design has hubexec and threads. As far as I understand it's better to have only one thread doing HUB exec as there is no caching and things would get horrible slow.
What does a Spin interpreter do: It fetches byte codes from HUB and runs some PASM to do whatever that byte code says to do. To do that it needs a pointer to the next byte code, the Spin program counter, and it needs a Spin stack pointer. Perhaps a few temporary registers in COG.
This might leave a lot of free space in the COG. This free space could be used to run some user PASM code as a COG thread (or threads).
We could therefore imagine a Spin interpreter that allows the loading of some PASM into that free space to be run as a thread in parallel with the interpreter itself.
BINGO we have effectively got a COGSTART that loads PASM and runs it all in a single COG!
My basic error in starting this thread is that I thought that the multitasking already dealt with this issue and so, to get the biggest bang for the buck (since I thought it was already there... but it isn't) would be to give it to the newbie in SPIN. Everything you say is true but does it address the wait stalls? hmmmm
In my mind, with the facts as they are I think multitasking could be far later in a new person's experience.
Not sure I said it right but the idea is in there somewhere.
Darn you!!! How am I supposed to get work done for my REAL job, when I have to think about things like this??
We do like worms, don't we!!
@RICH, could you re-title this thread "SPIN+" or "SPIN 16x32" or some such.....since it will be different than Spin2?
I'm not sure it will be easier than starting a new COG (core, code execution engine, whatever), just point to some code and start the COG. Using the hardware multi-tasking from inside Spin will probably be more of a challenge (or at least more things to be aware of as far as what you should and shouldn't do).
What seems tricky for a new user about starting a COG? (I'm curious for future tutorial purposes)
I see Spin as a language for those who are new to programming and as such it should be as simple as possible.
Threads and parallel processing are perhaps not topics to start beginners off with.
But Spin does have threads, not just threads but parallel execution by virtue of it's COGs.
That's OK though because the way Spin does it is about the simplest cleanest I have ever seen.
Trying to get a COG to run multiple Spin threads may well not be so simple and have odd limitations, like the WAITPE thing, that just make Spin to confusing for beginners.
From reading hundreds of questions here over the years there are few things that have come up many, many, times:
1) Setting up the stack. What's that about? No body has to worry about a stack for the main line Spin. What is stack anyway? And why do I need one for starting up a COG? And how the hell do I know how big it should be?
2) DIRA. So many issues boil down to setting DIRA and then starting a COG and then wondering why OUTA does not work there.
3) There have been many questions indicating that the poster correlates objects, one to one, with COGs. Not realizing that an object may never start another COG but just provide methods the run in the callers COG when called. Or that an object could in fact start up many COGS.
4) Sharing data between COGs. How? Spin has no specific language features to do that. You have to kludge around with pointers.
5) DAT and VAR, The idea that DAT is shared between objects, and hence running COGs in different objects, but VAR is private to an object instance.
And so on..
Put all that together and you have quite an advanced topic for a beginner who may only recently learned how to read/write a pin, write an expression, and what a conditional or loop is.
Nicely summarized.
In other words sometimes I think you guys forget just how talented you really are. But if Parallax tried to make money by only catering to that kind of talent uhhhm.
It seems like you should be the Editor-in-Chief of the Propeller2 Manual with the additional possibility of authoring the first Propeller2 tutorial. You make a lot of excellent points.
The majority of your issues on the Propeller that you mention didn't make much sense to me until I got into Forth on the Propeller (Yes, it took a stack language to make the reason for stacks obvious -- Spin has some Forth like qualities to it.)
Also Forth cleared up just exactly what that pesky PAR register did and why it was so important. I guess I was just a late-bloomer with the Propeller1.
Maybe we should disguise a version of Forth and call it the P2-Explorer. New users might understand a bit faster and sooner.
What's in a name?
That which we call Forth by any other name would smell as <?>
It is left as an exercise to the reader to fill in the <?> as needed based on their arguably incorrect opinion of Forth...
C.W.
In DIDN'T do it!
I do agree with this. It should be experienced even to the point that you try and write a small application that is well suited for F
.
So are you espousing exposing malleable future programmers to Forth, sort of like taking a little kid to a Chicken Pox party? ;-)
C.W.