I don't want to start a flame war, but why are people wanting to port Spin2 to other devices? surely Spin is one of the many things that make programming on the Prop great! why should you be thinking of giving away chips arsenal to other chip providers? surely we should keep it with parallax devices.
I for one want to see parallax grow from strength to strength, as they are an amazing company who care an awful lot about their customers, and who are, to my knowledge, the only company who would even think of letting everyone this close to the inner workings of their products.
Yes, I do appreciate the yield issue. At least up to some layman level.
But why should Parallax care where the failures are on a wafer? Isn't that the concern of the FAB?
If I understand correctly the actual design of a chip can affect yield. For example simple, regular structures may result in higher yields than complex, irregular, dense structures. Still I don't see how knowing yield vs wafer position helps Parallax.
Have times changed? I seem to remember that chip manufacture went like this:
1) Print hundreds/thousands of chips onto a wafer.
2) Test each chip whilst still on the wafer, stepping the test probes from chip to chip and marking all the "dead" ones.
3) Chop the wafer up into individual chips discarding the marked failures.
In this way the FAB knows its yield vs wafer position from step 2.
One of the many reasons I love the Propeller and Spin is how fast I can build complex prototype projects. Having used many other devices in my work I hate it when I have to go back to the others (not by choice). Both Spin and PASM are a delight to use. Leave Spin where it belongs.
The world became a better place when the Propeller and Spin arrived.
The Universe will be a better place with Prop2 and Spin2!!
...but why are people wanting to port Spin2 to other devices? surely Spin is one of the many things that make programming on the Prop great! why should you be thinking of giving away chips arsenal to other chip providers? surely we should keep it with parallax devices.
I'm not sure anyone is seriously considering targeting Spin at other devices yet but:
1) It seems you did not get the memo. We are living in an open source world now. Parallax has embraced open source with the recent developments of a Propeller target for GCC, the open source tools for the Propeller and so on.
2) I might posit that Parallax is now building on the free and open source GCC and other software, Qt used in Simple IDE for example. There is some kind of moral impreritive to not be greedy and try to keep things like Spin closed and proprietary.
3) I very much doubt that any other chip manufacturers would bother with Spin for their MCU's. It it not so compelling.
4) If Spin were to spread around that may have a beneficial effect of raising awareness of Parallax and the Propeller. That's not bad is it?
5) Users, tend to want to do weird stuff. Creating Z80 emulators for Propellers for example. It's not really possible to prevent anyone cloning Spin for whatever purpose. Making it hard or putting roadblocks up would send out very bad "vibes" from Parallax.
6) Why on earth invest all that time in an open source Spin compiler if it's not supposed to be, well, "open".
7) Expanding on 4) If you could run Spin on a PC and show people how easy it is to start up 8 threads in 8 cores and how interrupts are not required to get things done and .... would that not be beneficial to selling them on the Propeller idea?
You are right that knowing yield against position is to help the fab, not Parallax. This needs a wafer test where each die is probed and (functionally) tested. Packing can be coupled then to process only good dies. The E-test mentioned earlier is probably an elementary check of the PCB's (Process Control Blocks) added on the wafer to globally verify the different process steps.
If a structure is more or less regular (compare SDRAM chip vs random logic) does not influence yield. Size does. If a dust particle of 1mum settles on power transistor of 100mum2 is does no harm, while it may easily destroy a smaller transistor.
Except Andreas Olofsson point's out that yields vary from design to design even on the same process technology made in the same FABs and by a large amount. That there is a link between the design you give to the FAB and the yield you will get. He argues you have to design the logic with yield issues in mind not just rely on the FAB to sort it out.
I get the impression there is a lot more to this yield issue than just random bit's of dust on the wafer.
Perhaps this is not such an issue at the process scale the Prop II is using.
Here is a great video by Andreas Olofsson about "many core computer architectures" and the problems in the future of chip design. https://www.youtube.com/watch?v=DX9OMgmedbQ
He talks about the design related yield issues at about 30 mins 10 seconds.
Earlier in this thread (and during Chip's Skype talk), it was discussed that wafer level testing was not being done mostly due to cost. Chip told us that the testing would be done by a Propeller (perhaps Prop2) test rig that Parallax would develop from a handful of parts. Add a appropriate ZIF socket to it for $200-$300 and you are ready to test chips!
Since Chip has actually done this before with the Propeller, I will trust in Chip and wait for the results of the testing....who knows, there may even be some fun surprises in store for the Propeller community!!
I'm not sure anyone is seriously considering targeting Spin at other devices yet but:
I don't know if this has come up yet in this discussion but it is probably already possible to write Spin programs that will run on other processors. You can use Eric's spin2cpp and then compile the resulting C++ code on your target processor of choice. I suppose this won't work if there are Propeller dependencies in the generated code but I suspect those could be handled if someone were really to want to do this.
SPIN can be made a widely accepted language with more environments.
SPIN syntax is basically Object Pascal without those BEGIN/END delimiters (more painful than curlys LOL).
Challenges to me are:
* Allow just using the language.
* Connect useful PC things.
There are at least 3 simulators that already run Spin code on the PC (Gear, pPropellerSim, and Spinsim). Each have their own strengths.
Spinsim is the only one that can hide itself from the user (i.e. no built-in GUI), but it needs "PC thing" connections. I'd like to add TK for example. There seems to be some file support already.
I recognize that this is OT. If there is further interest, we can start another thread.
...it is probably already possible to write Spin programs that will run on other processors.
Oh shucks, I forgot the memo. Start to think something Prop related is "impossible" or far away and it's done already.
But: If I translate a Spin program to C++ with spin2cpp and try to run the resulting code on my PC what happens with cognew and such. Seems it needs some library support to start a new threads and such.
Oh shucks, I forgot the memo. Start to think something Prop related is "impossible" or far away and it's done already.
But: If I translate a Spin program to C++ with spin2cpp and try to run the resulting code on my PC what happens with cognew and such. Seems it needs some library support to start a new threads and such.
Well, things like cognew will always be Propeller specific unless you want to emulate them using threads on a PC. However, you're correct that there would need to be library support under Windows/Mac/Linux. It would actually be cool to play with Eric's parser to extend Spin a little for more complete object support. If only I had a little more time .... :-)
Only if you squint really, really hard. Even then the sematics is very different.
@David,
...things like cognew will always be Propeller specific unless you want to emulate them using threads on a PC..
Yep, never mind the multiple cores. Logically cognew starts a new parallel thread of execution. Of course a PC can have 4 or 8 cores to handle that as well.
Getting the timing exactly the same as an actuall propeller may be an issue but that is not part of the Spin language definition anyway.
Only if you squint really, really hard. Even then the sematics is very different.
@David,
Yep, never mind the multiple cores. Logically cognew starts a new parallel thread of execution. Of course a PC can have 4 or 8 cores to handle that as well.
Getting the timing exactly the same as an actuall propeller may be an issue but that is not part of the Spin language definition anyway.
You might argue that cognew is also not part of the Spin language but rather part of the Propeller runtime. Chip might disagree though! :-)
Personally, I agree. I would much rather live in a world that asks "fine architecture, but can I use Spin to program it?" than in the world we presently inhabit... which has suffered an avalanche of languages, forcing our choices, which are inevitably wrong.
In reality, C#++! is the common retort to the torrent of new languages that befuddle and entice us all with handsome cross-platform user experiences.
I would be happy if Spin were the controller language of choice... damn the PC's and all of the waste and intrusion. There will be other multi-processing controllers... let them succeed in their own right or adapt spin as the best defined and most functional parallel language... and it is open sourced!!!
Spin is in no way a parallel language.
Spin is hardly defined at all, there is no formal rigorous syntax definition in BNF for example.
Spin is otherwise about as functional as a cut down C.
Otherwise it's great.
P.S. That is not "functional" as in "functional programming" which is a whole other ball game.
If the cogs run in parallel and they are programmed with Spin... in what way is Spin not a parallel language?
Rich
Writing a hundred lines of BASIC and running that on one hundred PCs still does not make BASIC a parallel language. So too with running Spin on multiple cogs, no different really, the different processes are performed concurrently but the individual processes still run as single threads and the Spin compiler cannot take your cool algorithm and figure out how to run this on multiple cogs etc nor does it have any support in the language itself to define this operation. All that said in a tiny nutshell I have to say that compared to the make processes required with the C compilers that writing in Spin for the Prop is a pleasant walk in the park.
If the cogs run in parallel and they are programmed with Spin... in what way is Spin not a parallel language?
Well, as usual it rather depends on your definition of "parallel language".
If you look at the syntax of Spin you see it has constructs for such concepts as objects, methods, variables, constants, decisions (if), loop (repeat), and so on. There are no syntactical constructs for any kind of parallel operations.
If you look at the semantics, of Spin there is no statement about what may or may not happen in parallel. Statements are expected to execute sequentially from top to bottom as you read it.
"What about COGINT and friends.." you say "...they do parallel stuff?"
For sure they do. But from a language point of view they look like functions that take parameters and by some magic get the run time system to run chunks of your sequential code on another core. One could provide such functions in C or other normal "sequential" language. These things are not looking like part of a language specification.
So what is normally meant by a "parallel language"?
Well there are many varieties of parallel languages. For example OCCAM. In OCCAM you can write something like the following:
SEQ
doSomething1()
doSomething2()
PAR
doSomething3()
doSomething4()
doSomething5()
doSomething6()
That may not be exactly correct syntax but the idea is that doSomething1 and 2 will be run sequentially like normal code, each function has to complete before the next one is started. But as you might guess doSomething3 and 4 can be run in parallel perhaps on different CPUs. Both doSomething3 and 4 must complete before executing doSomething5().
Notice that the SEQ is compulsory. Statements can be executed sequentially or in parallel you have to specify which.
There have also been parallel extensions to C that have such constructs for example XC from Xmos.
Then there is the new Go language from Google where you can write:
package main
import "fmt"
func sum(a []int, c chan int) {
sum := 0
for _, v := range a {
sum += v
}
c <- sum // send sum to c
}
func main() {
a := []int{7, 2, 8, -9, 4, 0}
c := make(chan int)
go sum(a[:len(a)/2], c)
go sum(a[len(a)/2:], c)
x, y := <-c, <-c // receive from c
fmt.Println(x, y, x+y)
}
That's a bit complex for a first read but notice the "go" keyword that is used to run the function "sum" twice in parallel.
Then there is the issue of sharing memory between parallel threads. Languages like OCCAM and XC do not allow you to share memory between threads rather they provide language features to allow thread to thread communication channels. This means you can think of parallel threads as totally independent even running on different CPU's where it is not even possible to share memory directly.
Other approaches to "parallel languages" take a different tack and allow you to write normal sequential looking code but with the understanding they will run bits of it in parallel if they can figure out it is possible.
Sorry that's all a bit long but basically it prompt's my statement that Spin is not a "parallel language" in any way that phrase is used normally.
Of course with a little slight of hand we could turn Spin into a real "parallel language".
For example:
1) Change the current COGNEW function into a actual language keyword. "COGNEW" is horribly hardware specific and ugly so let's take a tip from Google's Go language and call it "spin". Now we can write:
spin someMethod (paramList, stackPointer)
There that's much better, nice clean syntax.
2) Notice that now starting a parallel thread is not a function so we have no cog id returned and we don't now if it fails. That's OK, Spin already has the concept of ABORT so if the thread cannot be started the calling method just aborts.
3) Of course we no longer know which cog got started and cannot stop it with anything like COGSTOP. I'm not sure that is a worry in a lot of cases.
4) We can no longer start a cog by ID. This is generally not used and advised against anyway.
5) Why not allow the "spin" statement to start methods in other objects? We could write:
and the compiler could figure out what to do. (I think you cannot do this with COGNEW because at run time whatever is starting the cog cannot distinguish between a method reference and an object.method reference.
Now Spin is a grown up parallel language:)
Actually one would just add the "spin" keyword to Spin and keep the old COG functions.
Of course with a little slight of hand we could turn Spin into a real "parallel language".
For example:
1) Change the current COGNEW function into a actual language keyword. "COGNEW" is horribly hardware specific and ugly so let's take a tip from Google's Go language and call it "spin". Now we can write:
spin someMethod (paramList, stackPointer)
There that's much better, nice clean syntax.
2) Notice that now starting a parallel thread is not a function so we have no cog id returned and we don't now if it fails. That's OK, Spin already has the concept of ABORT so if the thread cannot be started the calling method just aborts.
3) Of course we no longer know which cog got started and cannot stop it with anything like COGSTOP. I'm not sure that is a worry in a lot of cases.
4) We can no longer start a cog by ID. This is generally not used and advised against anyway.
5) Why not allow the "spin" statement to start methods in other objects? We could write:
and the compiler could figure out what to do. (I think you cannot do this with COGNEW because at run time whatever is starting the cog cannot distinguish between a method reference and an object.method reference.
Now Spin is a grown up parallel language:)
Actually one would just add the "spin" keyword to Spin and keep the old COG functions.
While it may be literally true that this turns Spin into a "parallel language" by virtue of the fact that it makes starting a parallel thread part of the language syntax, this change does not add anything to the power of Spin. It just adds a bit of syntactic sugar to what Spin can already do anyway.
One could argue that this "function vs syntax" is just quibbling and that properly defining COGNEW and friends as keywords in the language is good enough to make Spin a "real parallel" language.
Unless those syntactic tweaks actually carry some semantics above what we have now that make the language more expressive and easier to use I might be almost tempted to agree.
In this case the suggested "spin" keyword does in fact carry new meaning. The idea of starting a method in a different object. Something we cannot do just now. I have seen posts on the forum over the years that show this has caught people out as they would expect it to "just work".
One could argue that this "function vs syntax" is just quibbling and that properly defining COGNEW and friends as keywords in the language is good enough to make Spin a "real parallel" language.
Unless those syntactic tweaks actually carry some semantics above what we have now that make the language more expressive and easier to use I might be almost tempted to agree.
In this case the suggested "spin" keyword does in fact carry new meaning. The idea of starting a method in a different object. Something we cannot do just now. I have seen posts on the forum over the years that show this has caught people out as they would expect it to "just work".
Sorry, I've never tried starting a Spin method in another COG. I've always used COGNEW and COGINIT to start PASM code.
Actually, what I like most about Spin is the fact that it is almost without syntax, which is what I (personally) find to be the hardest part of programming... different brains work differently.
Heater... With Spin (as it now exists) it is possible to start a method in another object, but not in the sense that you mean. And it is possible to create all kinds of semantic references and structures that you build yourself. If you want to pass a paramList, you can do it now, and if you want to pass a stackPointer... that should be in your paramList:)
Chip pays close attention to discussions like this. If you look at the P2... many of its features came from discussions on the forums.
Taking your example
spin someMethod (paramList, stackPointer),
which then aborts because I was too greedy with my assets...When do I get notified of an abort? At compile time or at run-time? I personally don't want a system that compiles just fine, but then aborts at run-time. Just how deep would the compiler have to be to catch an abort that came from nested structures? What kinds of nests do you want? Wouldn't that kind of compiler structure also give the programmer the infinite joy of hanging up the compiler with a programming error, which right now doesn't happen.
I would rather have a deterministic machine, programmed with a simple language, but that is just me.
HOWEVER
If you were to propose to me that IF these kinds of changes were made to Spin, then the Spin language would be accepted across many other controller architectures, I'd seriously consider hoisting your flag:)
Just think about all those Arduino's hooked together with telephone wire:)
I personally don't want a system that compiles just fine, but then aborts at run-time.
I don't have time to think about this just now but of course you can easily get yourself into a total failure situation in Spin as it is, Your program needs to many COGs, it fails. Need to many locks, it fails. Run off the given stack space, it fails.
A compiler can never stop you from being stupid at run time.
Just how deep would the compiler have to be to catch an abort that came from nested structures? What kinds of nests do you want? Wouldn't that kind of compiler structure also give the programmer the infinite joy of hanging up the compiler with a programming error, which right now doesn't happen.
And there you have asked a very deep question.
In order to be sure that your program works a compiler would actually have to compile the program and then run it against all possible inputs. In a continuously running program, as we expect in an embedded system, that means all possible sequences of all possible inputs over all time.
Clearly this is impossible.
So, I assert that a function returning an error is often the same as an operation that just aborts your entire program. Whatever it is has failed. What can you do? That's OK at test and debug time. When running in the field your system is dead whatever.
With Spin (as it now exists) it is possible to start a method in another object, but not in the sense that you mean
Please give me an example of how to do that.
'same object
'Ser
methode1
methode2
'Par
cognew(methode1)
cognew(methode2)
'other object
'Ser
obj.methode1
obj.methode2
'Par
obj.spin_methode1
obj.spin_methode2
in obj:
PUB spin_methode1
cognew(methode1)
PUB spin_methode2
cognew(methode2)
PRI methode1
...
PRI methode2
...
for sure the object must allow to run a methode in parallel, but that makes perfect sense. Spin objects are like Classes in other languages and you define there what is possible and what not.
Comments
I for one want to see parallax grow from strength to strength, as they are an amazing company who care an awful lot about their customers, and who are, to my knowledge, the only company who would even think of letting everyone this close to the inner workings of their products.
Yes, I do appreciate the yield issue. At least up to some layman level.
But why should Parallax care where the failures are on a wafer? Isn't that the concern of the FAB?
If I understand correctly the actual design of a chip can affect yield. For example simple, regular structures may result in higher yields than complex, irregular, dense structures. Still I don't see how knowing yield vs wafer position helps Parallax.
Have times changed? I seem to remember that chip manufacture went like this:
1) Print hundreds/thousands of chips onto a wafer.
2) Test each chip whilst still on the wafer, stepping the test probes from chip to chip and marking all the "dead" ones.
3) Chop the wafer up into individual chips discarding the marked failures.
In this way the FAB knows its yield vs wafer position from step 2.
The world became a better place when the Propeller and Spin arrived.
The Universe will be a better place with Prop2 and Spin2!!
I'm not sure anyone is seriously considering targeting Spin at other devices yet but:
1) It seems you did not get the memo. We are living in an open source world now. Parallax has embraced open source with the recent developments of a Propeller target for GCC, the open source tools for the Propeller and so on.
2) I might posit that Parallax is now building on the free and open source GCC and other software, Qt used in Simple IDE for example. There is some kind of moral impreritive to not be greedy and try to keep things like Spin closed and proprietary.
3) I very much doubt that any other chip manufacturers would bother with Spin for their MCU's. It it not so compelling.
4) If Spin were to spread around that may have a beneficial effect of raising awareness of Parallax and the Propeller. That's not bad is it?
5) Users, tend to want to do weird stuff. Creating Z80 emulators for Propellers for example. It's not really possible to prevent anyone cloning Spin for whatever purpose. Making it hard or putting roadblocks up would send out very bad "vibes" from Parallax.
6) Why on earth invest all that time in an open source Spin compiler if it's not supposed to be, well, "open".
7) Expanding on 4) If you could run Spin on a PC and show people how easy it is to start up 8 threads in 8 cores and how interrupts are not required to get things done and .... would that not be beneficial to selling them on the Propeller idea?
You are right that knowing yield against position is to help the fab, not Parallax. This needs a wafer test where each die is probed and (functionally) tested. Packing can be coupled then to process only good dies. The E-test mentioned earlier is probably an elementary check of the PCB's (Process Control Blocks) added on the wafer to globally verify the different process steps.
If a structure is more or less regular (compare SDRAM chip vs random logic) does not influence yield. Size does. If a dust particle of 1mum settles on power transistor of 100mum2 is does no harm, while it may easily destroy a smaller transistor.
Except Andreas Olofsson point's out that yields vary from design to design even on the same process technology made in the same FABs and by a large amount. That there is a link between the design you give to the FAB and the yield you will get. He argues you have to design the logic with yield issues in mind not just rely on the FAB to sort it out.
I get the impression there is a lot more to this yield issue than just random bit's of dust on the wafer.
Perhaps this is not such an issue at the process scale the Prop II is using.
Here is a great video by Andreas Olofsson about "many core computer architectures" and the problems in the future of chip design.
https://www.youtube.com/watch?v=DX9OMgmedbQ
He talks about the design related yield issues at about 30 mins 10 seconds.
I recommend everyone watch this whole thing.
Since Chip has actually done this before with the Propeller, I will trust in Chip and wait for the results of the testing....who knows, there may even be some fun surprises in store for the Propeller community!!
SPIN syntax is basically Object Pascal without those BEGIN/END delimiters (more painful than curlys LOL).
Challenges to me are:
* Allow just using the language.
* Connect useful PC things.
There are at least 3 simulators that already run Spin code on the PC (Gear, pPropellerSim, and Spinsim). Each have their own strengths.
Spinsim is the only one that can hide itself from the user (i.e. no built-in GUI), but it needs "PC thing" connections. I'd like to add TK for example. There seems to be some file support already.
I recognize that this is OT. If there is further interest, we can start another thread.
But: If I translate a Spin program to C++ with spin2cpp and try to run the resulting code on my PC what happens with cognew and such. Seems it needs some library support to start a new threads and such.
Well, things like cognew will always be Propeller specific unless you want to emulate them using threads on a PC. However, you're correct that there would need to be library support under Windows/Mac/Linux. It would actually be cool to play with Eric's parser to extend Spin a little for more complete object support. If only I had a little more time .... :-)
@David, Yep, never mind the multiple cores. Logically cognew starts a new parallel thread of execution. Of course a PC can have 4 or 8 cores to handle that as well.
Getting the timing exactly the same as an actuall propeller may be an issue but that is not part of the Spin language definition anyway.
In reality, C#++! is the common retort to the torrent of new languages that befuddle and entice us all with handsome cross-platform user experiences.
I would be happy if Spin were the controller language of choice... damn the PC's and all of the waste and intrusion. There will be other multi-processing controllers... let them succeed in their own right or adapt spin as the best defined and most functional parallel language... and it is open sourced!!!
Spin is in no way a parallel language.
Spin is hardly defined at all, there is no formal rigorous syntax definition in BNF for example.
Spin is otherwise about as functional as a cut down C.
Otherwise it's great.
P.S. That is not "functional" as in "functional programming" which is a whole other ball game.
I don't understand.
If the cogs run in parallel and they are programmed with Spin... in what way is Spin not a parallel language?
Rich
Writing a hundred lines of BASIC and running that on one hundred PCs still does not make BASIC a parallel language. So too with running Spin on multiple cogs, no different really, the different processes are performed concurrently but the individual processes still run as single threads and the Spin compiler cannot take your cool algorithm and figure out how to run this on multiple cogs etc nor does it have any support in the language itself to define this operation. All that said in a tiny nutshell I have to say that compared to the make processes required with the C compilers that writing in Spin for the Prop is a pleasant walk in the park.
If you look at the syntax of Spin you see it has constructs for such concepts as objects, methods, variables, constants, decisions (if), loop (repeat), and so on. There are no syntactical constructs for any kind of parallel operations.
If you look at the semantics, of Spin there is no statement about what may or may not happen in parallel. Statements are expected to execute sequentially from top to bottom as you read it.
"What about COGINT and friends.." you say "...they do parallel stuff?"
For sure they do. But from a language point of view they look like functions that take parameters and by some magic get the run time system to run chunks of your sequential code on another core. One could provide such functions in C or other normal "sequential" language. These things are not looking like part of a language specification.
So what is normally meant by a "parallel language"?
Well there are many varieties of parallel languages. For example OCCAM. In OCCAM you can write something like the following:
SEQ doSomething1() doSomething2() PAR doSomething3() doSomething4() doSomething5() doSomething6()That may not be exactly correct syntax but the idea is that doSomething1 and 2 will be run sequentially like normal code, each function has to complete before the next one is started. But as you might guess doSomething3 and 4 can be run in parallel perhaps on different CPUs. Both doSomething3 and 4 must complete before executing doSomething5().Notice that the SEQ is compulsory. Statements can be executed sequentially or in parallel you have to specify which.
There have also been parallel extensions to C that have such constructs for example XC from Xmos.
Then there is the new Go language from Google where you can write:
package main import "fmt" func sum(a []int, c chan int) { sum := 0 for _, v := range a { sum += v } c <- sum // send sum to c } func main() { a := []int{7, 2, 8, -9, 4, 0} c := make(chan int) go sum(a[:len(a)/2], c) go sum(a[len(a)/2:], c) x, y := <-c, <-c // receive from c fmt.Println(x, y, x+y) }That's a bit complex for a first read but notice the "go" keyword that is used to run the function "sum" twice in parallel.Then there is the issue of sharing memory between parallel threads. Languages like OCCAM and XC do not allow you to share memory between threads rather they provide language features to allow thread to thread communication channels. This means you can think of parallel threads as totally independent even running on different CPU's where it is not even possible to share memory directly.
Other approaches to "parallel languages" take a different tack and allow you to write normal sequential looking code but with the understanding they will run bits of it in parallel if they can figure out it is possible.
Sorry that's all a bit long but basically it prompt's my statement that Spin is not a "parallel language" in any way that phrase is used normally.
Heater.. "a bit long" but very much appreciated.
For example:
1) Change the current COGNEW function into a actual language keyword. "COGNEW" is horribly hardware specific and ugly so let's take a tip from Google's Go language and call it "spin". Now we can write: There that's much better, nice clean syntax.
2) Notice that now starting a parallel thread is not a function so we have no cog id returned and we don't now if it fails. That's OK, Spin already has the concept of ABORT so if the thread cannot be started the calling method just aborts.
3) Of course we no longer know which cog got started and cannot stop it with anything like COGSTOP. I'm not sure that is a worry in a lot of cases.
4) We can no longer start a cog by ID. This is generally not used and advised against anyway.
5) Why not allow the "spin" statement to start methods in other objects? We could write: and the compiler could figure out what to do. (I think you cannot do this with COGNEW because at run time whatever is starting the cog cannot distinguish between a method reference and an object.method reference.
Now Spin is a grown up parallel language:)
Actually one would just add the "spin" keyword to Spin and keep the old COG functions.
We know the Prop2 can run 4 threads per cog, so with a bit of compiler magic you could in theory run up to 32 threads!
Yep, I did say "slight of hand".
One could argue that this "function vs syntax" is just quibbling and that properly defining COGNEW and friends as keywords in the language is good enough to make Spin a "real parallel" language.
Unless those syntactic tweaks actually carry some semantics above what we have now that make the language more expressive and easier to use I might be almost tempted to agree.
In this case the suggested "spin" keyword does in fact carry new meaning. The idea of starting a method in a different object. Something we cannot do just now. I have seen posts on the forum over the years that show this has caught people out as they would expect it to "just work".
Heater... With Spin (as it now exists) it is possible to start a method in another object, but not in the sense that you mean. And it is possible to create all kinds of semantic references and structures that you build yourself. If you want to pass a paramList, you can do it now, and if you want to pass a stackPointer... that should be in your paramList:)
Chip pays close attention to discussions like this. If you look at the P2... many of its features came from discussions on the forums.
Taking your example which then aborts because I was too greedy with my assets...When do I get notified of an abort? At compile time or at run-time? I personally don't want a system that compiles just fine, but then aborts at run-time. Just how deep would the compiler have to be to catch an abort that came from nested structures? What kinds of nests do you want? Wouldn't that kind of compiler structure also give the programmer the infinite joy of hanging up the compiler with a programming error, which right now doesn't happen.
I would rather have a deterministic machine, programmed with a simple language, but that is just me.
HOWEVER
If you were to propose to me that IF these kinds of changes were made to Spin, then the Spin language would be accepted across many other controller architectures, I'd seriously consider hoisting your flag:)
Just think about all those Arduino's hooked together with telephone wire:)
Rich
A compiler can never stop you from being stupid at run time.
Please give me an example of how to do that.
In order to be sure that your program works a compiler would actually have to compile the program and then run it against all possible inputs. In a continuously running program, as we expect in an embedded system, that means all possible sequences of all possible inputs over all time.
Clearly this is impossible.
So, I assert that a function returning an error is often the same as an operation that just aborts your entire program. Whatever it is has failed. What can you do? That's OK at test and debug time. When running in the field your system is dead whatever.
Andy