I was being facetious about suggesting new features for Spin. Most of my suggestions have been proposed before, and shot down. So it's kind of pointless to propose them again. Anyhow, at this point I'm hoping that your work on Spin2 is almost done and the chip can go into synthesis soon.
.... Anyhow, at this point I'm hoping that your work on Spin2 is almost done and the chip can go into synthesis soon.
Spin2 does not even really need to be 'almost done', as long as there has been enough coverage of the chip functionality.
Which raises the question of what is enough test coverage ?
Does Chip want to wait for release of Spin2, and thus get more users into the test room ?
Where does that leave the test coverage of things like smart pins, which seem to have stalled with a new mode added, but no clean-up/usability pass completed ?
.... Anyhow, at this point I'm hoping that your work on Spin2 is almost done and the chip can go into synthesis soon.
Spin2 does not even really need to be 'almost done', as long as there has been enough coverage of the chip functionality.
Which raises the question of what is enough test coverage ?
Does Chip want to wait for release of Spin2, and thus get more users into the test room ?
Where does that leave the test coverage of things like smart pins, which seem to have stalled with a new mode added, but no clean-up/usability pass completed ?
Sorry about the delay, Jmg. I will get back to that soon. Just trying to push ahead on Spin.
I was being facetious about suggesting new features for Spin. Most of my suggestions have been proposed before, and shot down. So it's kind of pointless to propose them again. Anyhow, at this point I'm hoping that your work on Spin2 is almost done and the chip can go into synthesis soon.
Spin2 still needs more work. I hope to have it breathing soon.
I realize a lot of people think it is worthless, but it's a path that lets me prove a lot of the chip, so that I'll have the confidence needed to make those expenditures, which are huge. I'm just not knowledgable enough about C++ to go down that road, at first.
I was being facetious about suggesting new features for Spin. Most of my suggestions have been proposed before, and shot down. So it's kind of pointless to propose them again. Anyhow, at this point I'm hoping that your work on Spin2 is almost done and the chip can go into synthesis soon.
Spin2 still needs more work. I hope to have it breathing soon.
I realize a lot of people think it is worthless, but it's a path that lets me prove a lot of the chip, so that I'll have the confidence needed to make those expenditures, which are huge. I'm just not knowledgable enough about C++ to go down that road, at first.
I agree Chip. It will give us something exciting to test.
Spin2 will be much faster, and will provide a good test harness for P2 testing.
While I have always liked the elegance of indentation, I know some do not. IMHO switching between the two could just be a switch to change the source using an extension to the editor. PropTool already knows the indentation structure.
But I also see that other frontends, such as Basic, could compile down to a spin executable.
Personally, I think that a Spin1-like language could be used to prove out the chip design, and then a full blown Spin2 language could be developed after the chip goes into synthesis. This has two advantages. The first one is that the P2 would support the Spin1 language, which would allow existing Spin1 programs to be easily ported to the P2. For the most part PASM1 is a subset of PASM2 so even basic P1 PASM code could be ported to the P2 without major changes.
The second advantage is that this approach would get the P2 out earlier rather than later. The thing that is soooooooooo frustrating to me is to see all this work happening on Spin2 while the latest FPGA image is just sitting there without any testing going on. I know, it's been 11 years, so what's another 6 months added to the chip "schedule". For most companies this would be a disastrous approach, but it's different for Parallax. Parallax is run more as a hobby than a company. Time-to-market and software tool support isn't really a priority with Parallax. Maybe Parallax's approach is good for the user community because it allows more involvement from the community in chip development and tool support. But it is so frustrating to wait 11 years, and now it's looking more like 12 or 13 years for the P2.
I wish that the effort that's being expended for Spin2 would have an equal amount of effort spent on getting PropGCC for the P2. Whether anyone accepts the fact or not, C is the thing that will drive the P2 and not Spin2. With 512K of memory we will no longer have the memory limitations that the P1 has. 32K is just barely enough memory for C. If the P1 just had 64K of memory, or maybe even 48K, C would have worked on the P1. If we're going to take another 6 months or a year to get Spin2 implemented I'd suggest that Parallax might as well take another year to get PropGCC going as well. I'm 100% certain that if Parallax doesn't do that they're going to find things that should have gone into the silicon, but didn't make it because C was completely untested before the chip was built.
Personally, I think that a Spin1-like language could be used to prove out the chip design, and then a full blown Spin2 language could be developed after the chip goes into synthesis. This has two advantages. The first one is that the P2 would support the Spin1 language, which would allow existing Spin1 programs to be easily ported to the P2. For the most part PASM1 is a subset of PASM2 so even basic P1 PASM code could be ported to the P2 without major changes.
The second advantage is that this approach would get the P2 out earlier rather than later. The thing that is soooooooooo frustrating to me is to see all this work happening on Spin2 while the latest FPGA image is just sitting there without any testing going on. I know, it's been 11 years, so what's another 6 months added to the chip "schedule". For most companies this would be a disastrous approach, but it's different for Parallax. Parallax is run more as a hobby than a company. Time-to-market and software tool support isn't really a priority with Parallax. Maybe Parallax's approach is good for the user community because it allows more involvement from the community in chip development and tool support. But it is so frustrating to wait 11 years, and now it's looking more like 12 or 13 years for the P2.
I wish that the effort that's being expended for Spin2 would have an equal amount of effort spent on getting PropGCC for the P2. Whether anyone accepts the fact or not, C is the thing that will drive the P2 and not Spin2. With 512K of memory we will no longer have the memory limitations that the P1 has. 32K is just barely enough memory for C. If the P1 just had 64K of memory, or maybe even 48K, C would have worked on the P1. If we're going to take another 6 months or a year to get Spin2 implemented I'd suggest that Parallax might as well take another year to get PropGCC going as well. I'm 100% certain that if Parallax doesn't do that they're going to find things that should have gone into the silicon, but didn't make it because C was completely untested before the chip was built.
I would rather the silicon, bugs and all!
I am sure the basic instructions of the P1 will work. We now have 16 cogs, faster clock, more hub and cog ram, and 64 I/O.
Even if hub exec was a complete failure, it would not matter to many in reality, other than bruised egos. Even if Smart pins failed, we can still use them as P1.
There are a few bits of P1 not covered in the event of some failures, such as the counters and perhaps video.
But we would still have a very powerful P1 working/usable upgrade for those requiring it
We could survive with a small upgrade to PropTool for a minimal P2 support for P1 spin and PASM support.
Yes, we can tolerate "features". Intel has got along fine shipping us "features" for decades.
I would rather have a P2 with "features" now than no P2 at all.
fea·ture
ˈfēCHər
noun
1.
A distinctive attribute of microprocessors and other device supplied by Intel Inc. causing undocumented behavior or misbehavior in some situations.
"In both the edge and level triggered modes the IR
inputs must remain high until after the falling edge of
the first INTA. If the IR input goes low before this
time a DEFAULT IR7 will occur when the CPU acknowledges
the interrupt. This can be a useful safeguard
for detecting interrupts caused by spurious
noise glitches on the IR inputs. To implement this feature the IR7 routine is used for ‘‘clean up’’ simply
executing a return instruction, thus ignoring the interrupt."
I was being facetious about suggesting new features for Spin. Most of my suggestions have been proposed before, and shot down. So it's kind of pointless to propose them again. Anyhow, at this point I'm hoping that your work on Spin2 is almost done and the chip can go into synthesis soon.
Spin2 still needs more work. I hope to have it breathing soon.
I realize a lot of people think it is worthless, but it's a path that lets me prove a lot of the chip, so that I'll have the confidence needed to make those expenditures, which are huge. I'm just not knowledgable enough about C++ to go down that road, at first.
Chip, I don't think Spin2 is worthless. I just don't think it's important to put in structs, method pointers, a ternary operator, object pointers and C-like operators at this stage in the project. Each feature is probably only a week or two of work, but when you add them all together we're talking about adding a few more months to when the P2 is in silicon. A Spin1-like Spin2 should be able to prove out a lot of the chip. All of the extra Spin2 features can be added later while we're waiting for the chip from the foundry.
As far as C/C++, there are only two or three people on this forum that can implement GCC for the P2. I am not one of those people, but I am trying to get something going in that area on my own. I know very little about the inner workings of GCC, so I've taken the approach of converting the assembly generated by PropGCC to P2 assembly. Fortunately, the instruction subset that PropGCC uses is almost identical to P2 assembly. I also know little about the GNU assembler or the ELF object file format. I'm using my own homebrew object file format, and have written a linker that can put it all together into an executable binary file. I'm hoping that I'll do a good enough job on it to get others interested in using it, but a bad enough job so that Ken and the C gurus will decide it's time to get GCC working on the P2.
Chip, I don't think Spin2 is worthless. I just don't think it's important to put in structs, method pointers, a ternary operator, object pointers and C-like operators at this stage in the project. Each feature is probably only a week or two of work, but when you add them all together we're talking about adding a few more months to when the P2 is in silicon. A Spin1-like Spin2 should be able to prove out a lot of the chip. All of the extra Spin2 features can be added later while we're waiting for the chip from the foundry.
That's a very good point.
The low hanging fruit for Spin2 1.0 is "easy porting of Spin1 code" (tho even here, the timer differences will cause ?head scratching? )
Expanded 'non kernel' features NOT already in Spin1, can wait for Spin2 2.0, which can be done during the foundry run.
Errata will still be collected during tapeout, and even during the FAB run, so that those 'features' can be confirmed on silicon.
At some stage, the final silicon errata needs to be run through, and a Ship-or-Revise decision needs to be made.
Which "you" are you referring to? Chip, me or someone else? I don't know of anyone that's insisting that all implementations of Spin must use bytecodes. Chip wants to make sure that his Spin bytecode VM works correctly and efficiently. I'm suggesting that this can be done with a Spin2 that uses the same syntax as Spin1. I don't believe that structs, method pointers, object pointer, the ternary operator and the C-like operators will have much impact on the VM and it's bytecodes. As I said earlier, my interest at this point is to ensure that the P2 has everything we need for an efficient C implementation.
Which "you" are you referring to? Chip, me or someone else? I don't know of anyone that's insisting that all implementations of Spin must use bytecodes. Chip wants to make sure that his Spin bytecode VM works correctly and efficiently. I'm suggesting that this can be done with a Spin2 that uses the same syntax as Spin1. I don't believe that structs, method pointers, object pointer, the ternary operator and the C-like operators will have much impact on the VM and it's bytecodes. As I said earlier, my interest at this point is to ensure that the P2 has everything we need for an efficient C implementation.
I mostly say this because FastSpin has been around for ages but I've never heard of anyone using it. However, I frequently hear people say we need Spin for P2 ASAP. That suggests to me that people don't view FastSpin as a *real* implementation of Spin.
Chip is focusing on the P2, and Spin2 is part of the package. Just as much as Spin part of the package for P1.
He has said it many times, but no one listens. He needs to do Spin2 they way he wants to in order to build his confidence in the design and implementation enough to risk spending a large sum of money to get it made.
David Betz,
FastSpin is cool and all, but it doesn't hardly use any of the new P2 features. Cordic, LUT(shared or not), streamer (for other than HUBexec if it even does that fully or at all), smart pins, and so on. These are the things Chip wants to prove out before making the big choice.
Chip says it over and over, and none of you listen to him.
Chip says it over and over, and none of you listen to him.
Yes, I know the feeling. That's why I keep saying the same thing over and over. I've yet to hear a compelling reason why I am wrong, so until then I'll keep saying the same thing over and over. I'll stop saying the same thing over and over once I get a response that really says why I am wrong.
Dave Hein,
So, Chip, who is the one making this chip and his company that is funding it, saying that he want's to do it his way to have the confidence he requires isn't enough for you?
It's not about you being right or wrong...
It's not a very clear answer, but if you're saying what I think you're saying it's best not to discuss it here. Anyhow we have gotten way off track here. I guess I'll just have to wait and see how things develop in the next few months.
Spin and PASM are the native languages of the Propeller (1 or 2). C, by contrast, is more like Esperanto -- universal and widely understood, but a rather more oblique entree to the power of the Prop. Chip is absolutely right: Spin has to come first, where the Prop's features get native -- rather than mere function-call -- support.
Spin and PASM are the native languages of the Propeller (1 or 2). C, by contrast, is more like Esperanto -- universal and widely understood, but a rather more oblique entree to the power of the Prop. Chip is absolutely right: Spin has to come first, where the Prop's features get native -- rather than mere function-call -- support.
I can appreciate the frustration of protracted and interminable waiting - it's the story of my life. Nevertheless, what Phil wrote resonates strongly with me. I'm more excited about Chip's incarnation of Spin on P2 (like six clocks per bytecode as rjo__ mentioned) than I am of having a P2 in my hands tomorrow.
OTOH, if P2 happened to be a reduced-cog P1 in a TQFP-32, running internally at160MHz, and costing $2, I would be horribly impatient! I need something like that practically every working day of my life.
I do understand Chip's concept of building the silicon, the programming language, the IDE as a synergistic whole.
That was very well demonstrated in the P1, with the Spin byte code interpreter being burned into it's ROM. And the Spin language and Prop tool being the wonderfully easy things to use that they are.
On the other hand, I don't see anything "native" about Spin with the P2.
There is no Spin byte code interpreter in the P2 ROM. Spin is just another language for a clean slate new processor. As is C/C++ or whatever.
Or, have I missed a point somewhere?
In short, holding up P2 production for the sake of a new language design seems a bit out of sorts.
Spin is just another language for a clean slate new processor. As is C/C++ or whatever.
Or, have I missed a point somewhere?
In short, holding up P2 production for the sake of a new language design seems a bit out of sorts.
Yes and no - if the work was purely at the parser level, I'd agree.
- but it is not, Chip wrote, then tuned the Byte Code engine software and hardware with end the result of much higher performance and more compact code.
Of course ALL languages that use Byte-codes can expect to benefit from that, not just Spin2.
Spin2 just happens to be the test vehicle for this.
Likewise with other features, they do need exercising, and Spin2 is just one means to exercise them.
PASM2 is another means, but that is not going to give the coverage and HLL shakeouts that using any HLL allows.
If tuning the actual processor instruction set in order to get Spin byte codes to run as fast as possible, and hence Spin, is the name of the game then why have PASM? Why not just implement the Spin byte codes in silicon as the native instruction set and skip the interpreter step?
Don't get me wrong, I love the P1 instruction set, the regularity and simplicity of it's opcodes and the way it all works seamlessly in Spin and the Prop Tool.
Yes, he has said it many times for the last 6 months. Or maybe since last year. But I remember that before that, Chip said many times that the purpose was clearly to make a microcontroller that was meant to be programmed in assembly, made to be a pleasure to be programmed in assembly code, ... or similar words.
He spent the last 10 years making the perfect P2 instruction set, just to find out later that it also needs to be a pleasure to be programmed in a high level language. Maybe he just would have started by finding what he wanted to improve in SPIN to make the new perfect SPIN2. And once this language was defined, then design a MCU instruction set around this requirement. And not the other way around.
But, I am fine with that. I can wait another 'x' year(s) for a nice MCU with the perfect assembly instruction set, and a perfect high level SPIN2 interpreter or compiler.
I mostly say this because FastSpin has been around for ages but I've never heard of anyone using it. However, I frequently hear people say we need Spin for P2 ASAP. That suggests to me that people don't view FastSpin as a *real* implementation of Spin.
Does that means that we already have a spin1-like implementation for P2 v19?
FastSpin? I cannot find any link to the interpreter. A search at the forum only gives a code for FGPA v16.
I mostly say this because FastSpin has been around for ages but I've never heard of anyone using it. However, I frequently hear people say we need Spin for P2 ASAP. That suggests to me that people don't view FastSpin as a *real* implementation of Spin.
Does that means that we already have a spin1-like implementation for P2 v19?
FastSpin? I cannot find any link to the interpreter. A search at the forum only gives a code for FGPA v16.
FastSpin is another name for Eric Smith's spin2cpp. He enhanced it a while back to be able to generate P1 and P2 PASM instructions directly rather than compile to C++ which then had to be compiled with PropGCC. At that point it didn't make sense to continue to use its original name since it no longer necessarily compiled to C++. I think the P2 code generation may be a bit out of date with the current FPGA image but I'm sure it could be brought back in line fairly easily if there was any interest. He may already have done that and I missed the announcement. I think Eric has also added object and/or method pointers to both the P1 and P2 versions based on discussion of those features that happened several months ago.
Comments
Spin2 does not even really need to be 'almost done', as long as there has been enough coverage of the chip functionality.
Which raises the question of what is enough test coverage ?
Does Chip want to wait for release of Spin2, and thus get more users into the test room ?
Where does that leave the test coverage of things like smart pins, which seem to have stalled with a new mode added, but no clean-up/usability pass completed ?
Sorry about the delay, Jmg. I will get back to that soon. Just trying to push ahead on Spin.
Spin2 still needs more work. I hope to have it breathing soon.
I realize a lot of people think it is worthless, but it's a path that lets me prove a lot of the chip, so that I'll have the confidence needed to make those expenditures, which are huge. I'm just not knowledgable enough about C++ to go down that road, at first.
Spin2 will be much faster, and will provide a good test harness for P2 testing.
While I have always liked the elegance of indentation, I know some do not. IMHO switching between the two could just be a switch to change the source using an extension to the editor. PropTool already knows the indentation structure.
But I also see that other frontends, such as Basic, could compile down to a spin executable.
The second advantage is that this approach would get the P2 out earlier rather than later. The thing that is soooooooooo frustrating to me is to see all this work happening on Spin2 while the latest FPGA image is just sitting there without any testing going on. I know, it's been 11 years, so what's another 6 months added to the chip "schedule". For most companies this would be a disastrous approach, but it's different for Parallax. Parallax is run more as a hobby than a company. Time-to-market and software tool support isn't really a priority with Parallax. Maybe Parallax's approach is good for the user community because it allows more involvement from the community in chip development and tool support. But it is so frustrating to wait 11 years, and now it's looking more like 12 or 13 years for the P2.
I wish that the effort that's being expended for Spin2 would have an equal amount of effort spent on getting PropGCC for the P2. Whether anyone accepts the fact or not, C is the thing that will drive the P2 and not Spin2. With 512K of memory we will no longer have the memory limitations that the P1 has. 32K is just barely enough memory for C. If the P1 just had 64K of memory, or maybe even 48K, C would have worked on the P1. If we're going to take another 6 months or a year to get Spin2 implemented I'd suggest that Parallax might as well take another year to get PropGCC going as well. I'm 100% certain that if Parallax doesn't do that they're going to find things that should have gone into the silicon, but didn't make it because C was completely untested before the chip was built.
I am sure the basic instructions of the P1 will work. We now have 16 cogs, faster clock, more hub and cog ram, and 64 I/O.
Even if hub exec was a complete failure, it would not matter to many in reality, other than bruised egos. Even if Smart pins failed, we can still use them as P1.
There are a few bits of P1 not covered in the event of some failures, such as the counters and perhaps video.
But we would still have a very powerful P1 working/usable upgrade for those requiring it
We could survive with a small upgrade to PropTool for a minimal P2 support for P1 spin and PASM support.
I would rather have a P2 with "features" now than no P2 at all.
fea·ture
ˈfēCHər
noun
1.
A distinctive attribute of microprocessors and other device supplied by Intel Inc. causing undocumented behavior or misbehavior in some situations.
"In both the edge and level triggered modes the IR
inputs must remain high until after the falling edge of
the first INTA. If the IR input goes low before this
time a DEFAULT IR7 will occur when the CPU acknowledges
the interrupt. This can be a useful safeguard
for detecting interrupts caused by spurious
noise glitches on the IR inputs. To implement this
feature the IR7 routine is used for ‘‘clean up’’ simply
executing a return instruction, thus ignoring the interrupt."
synonyms: bug, error
As far as C/C++, there are only two or three people on this forum that can implement GCC for the P2. I am not one of those people, but I am trying to get something going in that area on my own. I know very little about the inner workings of GCC, so I've taken the approach of converting the assembly generated by PropGCC to P2 assembly. Fortunately, the instruction subset that PropGCC uses is almost identical to P2 assembly. I also know little about the GNU assembler or the ELF object file format. I'm using my own homebrew object file format, and have written a linker that can put it all together into an executable binary file. I'm hoping that I'll do a good enough job on it to get others interested in using it, but a bad enough job so that Ken and the C gurus will decide it's time to get GCC working on the P2.
I do like C++, but it's good to have options
The low hanging fruit for Spin2 1.0 is "easy porting of Spin1 code" (tho even here, the timer differences will cause ?head scratching? )
Expanded 'non kernel' features NOT already in Spin1, can wait for Spin2 2.0, which can be done during the foundry run.
Errata will still be collected during tapeout, and even during the FAB run, so that those 'features' can be confirmed on silicon.
At some stage, the final silicon errata needs to be run through, and a Ship-or-Revise decision needs to be made.
I also looked at your comments and slightly mistook them:)
I now fully agree!!!
Thanks.
Your perspective serves the timeline and immediate goals... and will be a lot easier on our leader.
I have hated computer languages since Apple dropped Pascal. I love Spin. It is just beautiful.
And... with 6 clocks per byte code... good Lord!!!
You are seeing the serious limitations of the one man show. Everything takes a really long time.
Spin2 wouldn't be a issue if there were others working on it while Chip was focused on the P-2
He has said it many times, but no one listens. He needs to do Spin2 they way he wants to in order to build his confidence in the design and implementation enough to risk spending a large sum of money to get it made.
David Betz,
FastSpin is cool and all, but it doesn't hardly use any of the new P2 features. Cordic, LUT(shared or not), streamer (for other than HUBexec if it even does that fully or at all), smart pins, and so on. These are the things Chip wants to prove out before making the big choice.
Chip says it over and over, and none of you listen to him.
Truth right there Roy.
So, Chip, who is the one making this chip and his company that is funding it, saying that he want's to do it his way to have the confidence he requires isn't enough for you?
It's not about you being right or wrong...
-Phil
OTOH, if P2 happened to be a reduced-cog P1 in a TQFP-32, running internally at160MHz, and costing $2, I would be horribly impatient! I need something like that practically every working day of my life.
I do understand Chip's concept of building the silicon, the programming language, the IDE as a synergistic whole.
That was very well demonstrated in the P1, with the Spin byte code interpreter being burned into it's ROM. And the Spin language and Prop tool being the wonderfully easy things to use that they are.
On the other hand, I don't see anything "native" about Spin with the P2.
There is no Spin byte code interpreter in the P2 ROM. Spin is just another language for a clean slate new processor. As is C/C++ or whatever.
Or, have I missed a point somewhere?
In short, holding up P2 production for the sake of a new language design seems a bit out of sorts.
Yes and no - if the work was purely at the parser level, I'd agree.
- but it is not, Chip wrote, then tuned the Byte Code engine software and hardware with end the result of much higher performance and more compact code.
Of course ALL languages that use Byte-codes can expect to benefit from that, not just Spin2.
Spin2 just happens to be the test vehicle for this.
Likewise with other features, they do need exercising, and Spin2 is just one means to exercise them.
PASM2 is another means, but that is not going to give the coverage and HLL shakeouts that using any HLL allows.
Clearly I am missing a point here.
If tuning the actual processor instruction set in order to get Spin byte codes to run as fast as possible, and hence Spin, is the name of the game then why have PASM? Why not just implement the Spin byte codes in silicon as the native instruction set and skip the interpreter step?
Don't get me wrong, I love the P1 instruction set, the regularity and simplicity of it's opcodes and the way it all works seamlessly in Spin and the Prop Tool.
I'm just getting grumpy waiting for silicon...
Yes, he has said it many times for the last 6 months. Or maybe since last year. But I remember that before that, Chip said many times that the purpose was clearly to make a microcontroller that was meant to be programmed in assembly, made to be a pleasure to be programmed in assembly code, ... or similar words.
He spent the last 10 years making the perfect P2 instruction set, just to find out later that it also needs to be a pleasure to be programmed in a high level language. Maybe he just would have started by finding what he wanted to improve in SPIN to make the new perfect SPIN2. And once this language was defined, then design a MCU instruction set around this requirement. And not the other way around.
But, I am fine with that. I can wait another 'x' year(s) for a nice MCU with the perfect assembly instruction set, and a perfect high level SPIN2 interpreter or compiler.
Does that means that we already have a spin1-like implementation for P2 v19?
FastSpin? I cannot find any link to the interpreter. A search at the forum only gives a code for FGPA v16.