I think, consumers does not want a super sophisticated product from Parallax, consumers want something easy to use. Company owner Chip also may have forgotten this.
Absolutely untrue! I started with the Basic Stamp. My first project was successful but that initial excitement did not last long. I 'needed' a new challenge.
In reality, the Propeller makes projects less expensive because it has multiple processors. When I redesigned my Basic Stamp project with a Propeller I eliminated four add-on boards which saved me several hundred dollars.
The P2 will make things even less expensive because of its power.
One thing about libraries -- because of its memory tightness it's almost impossible to use library code on P1 without going through it to eliminate unneeded methods, using tricks to reclaim the RAM used for PASM images, and so on. P2 should be much less dependent on that sort of thing so you can just have standard libraries that are useful for everyone out of the box.
One thing about libraries -- because of its memory tightness it's almost impossible to use library code on P1 without going through it to eliminate unneeded methods, using tricks to reclaim the RAM used for PASM images, and so on. P2 should be much less dependent on that sort of thing so you can just have standard libraries that are useful for everyone out of the box.
I believe fastspin and OpenSpin delete unused methods as did BST. I think it's just PropTool that doesn't. It's too bad they don't modify PropTool to use OpenSpin as its compiler.
One thing about libraries -- because of its memory tightness it's almost impossible to use library code on P1 without going through it to eliminate unneeded methods, using tricks to reclaim the RAM used for PASM images, and so on. P2 should be much less dependent on that sort of thing so you can just have standard libraries that are useful for everyone out of the box.
I believe fastspin and OpenSpin delete unused methods as did BST. I think it's just PropTool that doesn't. It's too bad they don't modify PropTool to use OpenSpin as its compiler.
OpenSpin's unused method removal and preprocessor are broken. Or at least they were back when I tried to compile VentilatorOS with it. BSTC also didn't work IIRC, so make of that what you will.
One thing about libraries -- because of its memory tightness it's almost impossible to use library code on P1 without going through it to eliminate unneeded methods, using tricks to reclaim the RAM used for PASM images, and so on. P2 should be much less dependent on that sort of thing so you can just have standard libraries that are useful for everyone out of the box.
I believe fastspin and OpenSpin delete unused methods as did BST. I think it's just PropTool that doesn't. It's too bad they don't modify PropTool to use OpenSpin as its compiler.
OpenSpin's unused method removal and preprocessor are broken. Or at least they were back when I tried to compile VentilatorOS with it. BSTC also didn't work IIRC, so make of that what you will.
Have you filed bugs on fastspin and OpenSpin? I think both authors are pretty responsive at fixing bugs.
I may not actually have done that. I will have to try it again sometime and file proper issues. Altough the preprocessor bug is irrelevant to me now, for I did a workaround (pre-concatenate files) and after encountering the other bug(s), didn't bother to roll it back. Working unused method removal would be really useful.
The thing is, the PropTool was the index development system for P1. Even if you preferred to use something else, you knew that if you loaded code from the Obex (at least until a few years ago) it would be in Spin and compile with the PropTool.
This was important and I am worried that it will be a problem for P2, that there is no such index development system which one can be sure will run an example if one is interested in it. FastSpin is probably the best going candidate for that at this point simply because it is multi-lingual, and I've been using it for all my P2 experimentation. I used PropTool for almost all my professional development work on P1 and only switched to BST when I developed a Spin programming technique that caused PropTool's compiler to run out of RAM at compile time, and of course BST was designed as a superset of PropTool so it would run all my other stuff.
I understand that the index language might not be Spin, because $commercial-considerations. But I think there does need to be an index development platform for whatever becomes the P2 Obex. Tell me what I need to invest in in order to do P2 development, but make sure that if I make that investment I can do whatever I need to.
Hasn't Parallax said they were going to make PropTool available for P2? I thought I read a post about that sometime in the last month or so. If so, I imagine that will be the "index language" since most people here seem to prefer Spin over the other options.
Hasn't Parallax said they were going to make PropTool available for P2? I thought I read a post about that sometime in the last month or so. If so, I imagine that will be the "index language" since most people here seem to prefer Spin over the other options.
Since the new silicon has arrived, I've been tied up with its testing and have not gotten anything new done on Spin2.
It's really frustrating, because the chip on my desk works great, but the chips at ON Semi have been tied up with testing problems, which could be part manufacturing problem, part design problem, as well as part test problem. We are not sure, yet.
Language concerns are definitely a minor side item while Chip is dealing with the final release hardware issues.
But assuming those get solved, then we have to deal with how we will do development. If someone develops a really cool hardware driver, how will it be released, what language will we expect it to be in? Obviously most serious stuff on P1 was in PASM and it was just the wrappers that were C or Spin. Things might be a bit more complicated on P2 with the fast hubexec. I would hope that we might have a consistent policy on this before people start generating nifty code that most of us can't use because we're using five different development platforms to do it.
OpenSpin unused method removal is working as far as I know, it did take a while to get it debugged, but last I knew it was working.
The preprocessor works fine too, it's not the full feature set of preprocessors (like no macros), so maybe the issue is expecting a feature that isn't there?
Currently, I'm not sure I should update OpenSpin for P2, it doesn't make any sense. ersmith's stuff is better and open source. Back in the day Jeff, Chip, and I were supposed to build Spin2 using OpenSpin as a base, but that was pre-P2-Hot. Instead Chip is building Spin2 using x86 asm on his own, and things are different enough now that creating OpenSpin2 will be a pretty large task again, and I just don't have the time. Plus, like I said, it just doesn't make sense. I think it would be better to just add bytecode generation to ersmith's stuff for those people that want the smaller compiled size.
If Parallax wants an OpenSpin2, then I am willing to help, but they'll need to get others involved. Also, I think they need to commit to it more than they did with OpenSpin, because OpenSpin is largely unused because it was never made official and put into proptool. I feel like I did a huge pile of work (and Parallax paid me for it), but no one uses it. People treat BSTC as more official than OpenSpin. Even PropellerIDE used BSTC by default for a long time (OpenSpin was available, and I fixed/changed things for it), and even when it did start using OpenSpin it was a modified old version for a long time (not sure even what it does now, PropellerIDE appears completely dead).
P2 needs to have a solid C/C++ solution, a solid BASIC solution, and MicroPython. It doesn't even need Spin at all, to be honest. I know several folks here will balk at that, but the reality is that Parallax needs to sell P2's to people that are not us, and most of those people don't want Spin at all.
The nice thing about OpenSpin for people like me, is that it can be integrated into a Visual Studio application without the need for external dependencies...
For that reason, I think an OpenSpin for P2 would be useful...
Back in the day Jeff, Chip, and I were supposed to build Spin2 using OpenSpin as a base, but that was pre-P2-Hot. Instead Chip is building Spin2 using x86 asm on his own, and things are different enough now that creating OpenSpin2 will be a pretty large task again, and I just don't have the time.
I thought that was the plan as well. Chip would be the Spin2 language designer and you would realize his design as an update to OpenSpin. I also thought OpenSpin would replace the x86 compiler that is currently used by PropTool.
Doesn't Chip want to eventually write the "real" Spin2 compiler in Spin2?
At that point, we could just spin2cpp it into a PC executable, right?
Yeah, I guess he did say that. Certainly, a compiler written in Spin would be easier to understand and maintain than one written in x86 assembly code. I wonder if he will release the source? I don't think the x86 source for the P1 Spin compiler is available outside of Parallax.
Hey all, we recognize that we need to clarify our intent with the programming tools (which languages we will support, what tools we will offer for different systems, and how we will achieve these things). At this exact moment, we're focused on ON and Chip's efforts as he described above. But soon, we will get together with the community and formalize the path. Until then, we've got a laser-like focus (Chip on the hardware, rest of Parallax team on running the business).
Feel free to share ideas and thoughts (we read all of them) and keep the discussion going as usual, recognizing we'll soon add some clarity to the planning.
Bean,
No triple @ is not supported. It's pretty difficult to implement without significant rework to how the compiler works (which is pretty much exactly how Chip's x86 compiler works). I've explained in greater detail in the past, and it's difficult to search for because of how the forum treats the triple @. /sigh
Back when it was all the rage, the only concrete example of it's usage was "PropBASIC needs it" but it was never clear to me why. Everyone kept posting contrived example use cases, but not anything that could not be done some other way.
P2 needs to have a solid C/C++ solution, a solid BASIC solution, and MicroPython. It doesn't even need Spin at all, to be honest. I know several folks here will balk at that, but the reality is that Parallax needs to sell P2's to people that are not us, and most of those people don't want Spin at all.
Roy
Good, Ken, that you read this. It will not work, not to invest money for a "solid C/C++ solution" with inline assembler as fast as possible. This must be the base of the libraries.
Roy,
I feel your pain having gone to all that trouble with OpenSpin.
And I agree, since we now have Eric’s FastSpin for P2 (and P1), it would probably make more sense to add spin bytecode output if Eric’s willing.
Of course, Chip has signalled there will be a PropTool2 although it has all the baggage of the original PropTool. I, and many others, disagree with this path, but it’s not our company.
Propeller Tool had a major disadvantage, IMHO: it only ran on Windows, unlike SimpleIDE and PropellerIDE. I guess it obly became the de facto tool because it was the first one. But it was superseeded.
The same think will eventually happen regarding the software for the P2. Personal preference will win.
Propeller Tool had a major disadvantage, IMHO: it only ran on Windows, unlike SimpleIDE and PropellerIDE. I guess it obly became the de facto tool because it was the first one. But it was superseeded.
The same think will eventually happen regarding the software for the P2. Personal preference will win.
Propeller Tool had a major disadvantage, IMHO: it only ran on Windows, unlike SimpleIDE and PropellerIDE. I guess it obly became the de facto tool because it was the first one. But it was superseeded.
The same think will eventually happen regarding the software for the P2. Personal preference will win.
Comments
In reality, the Propeller makes projects less expensive because it has multiple processors. When I redesigned my Basic Stamp project with a Propeller I eliminated four add-on boards which saved me several hundred dollars.
The P2 will make things even less expensive because of its power.
Could include things like camera interface and speech recognition...
Once there is GCC, it should be fairly easy to implement...
Once the P2 is available, of course we will make BlocklyProp work on it. We're just not there, yet.
This was important and I am worried that it will be a problem for P2, that there is no such index development system which one can be sure will run an example if one is interested in it. FastSpin is probably the best going candidate for that at this point simply because it is multi-lingual, and I've been using it for all my P2 experimentation. I used PropTool for almost all my professional development work on P1 and only switched to BST when I developed a Spin programming technique that caused PropTool's compiler to run out of RAM at compile time, and of course BST was designed as a superset of PropTool so it would run all my other stuff.
I understand that the index language might not be Spin, because $commercial-considerations. But I think there does need to be an index development platform for whatever becomes the P2 Obex. Tell me what I need to invest in in order to do P2 development, but make sure that if I make that investment I can do whatever I need to.
Since the new silicon has arrived, I've been tied up with its testing and have not gotten anything new done on Spin2.
It's really frustrating, because the chip on my desk works great, but the chips at ON Semi have been tied up with testing problems, which could be part manufacturing problem, part design problem, as well as part test problem. We are not sure, yet.
But assuming those get solved, then we have to deal with how we will do development. If someone develops a really cool hardware driver, how will it be released, what language will we expect it to be in? Obviously most serious stuff on P1 was in PASM and it was just the wrappers that were C or Spin. Things might be a bit more complicated on P2 with the fast hubexec. I would hope that we might have a consistent policy on this before people start generating nifty code that most of us can't use because we're using five different development platforms to do it.
The preprocessor works fine too, it's not the full feature set of preprocessors (like no macros), so maybe the issue is expecting a feature that isn't there?
Currently, I'm not sure I should update OpenSpin for P2, it doesn't make any sense. ersmith's stuff is better and open source. Back in the day Jeff, Chip, and I were supposed to build Spin2 using OpenSpin as a base, but that was pre-P2-Hot. Instead Chip is building Spin2 using x86 asm on his own, and things are different enough now that creating OpenSpin2 will be a pretty large task again, and I just don't have the time. Plus, like I said, it just doesn't make sense. I think it would be better to just add bytecode generation to ersmith's stuff for those people that want the smaller compiled size.
If Parallax wants an OpenSpin2, then I am willing to help, but they'll need to get others involved. Also, I think they need to commit to it more than they did with OpenSpin, because OpenSpin is largely unused because it was never made official and put into proptool. I feel like I did a huge pile of work (and Parallax paid me for it), but no one uses it. People treat BSTC as more official than OpenSpin. Even PropellerIDE used BSTC by default for a long time (OpenSpin was available, and I fixed/changed things for it), and even when it did start using OpenSpin it was a modified old version for a long time (not sure even what it does now, PropellerIDE appears completely dead).
P2 needs to have a solid C/C++ solution, a solid BASIC solution, and MicroPython. It doesn't even need Spin at all, to be honest. I know several folks here will balk at that, but the reality is that Parallax needs to sell P2's to people that are not us, and most of those people don't want Spin at all.
Roy
I used BSTC because PropBASIC needs the "@ @ @" operator.
Does openspin support the "@ @ @" operator ?
Bean
For that reason, I think an OpenSpin for P2 would be useful...
At that point, we could just spin2cpp it into a PC executable, right?
I don't think many non-Parallax-customers would profit from it.
Feel free to share ideas and thoughts (we read all of them) and keep the discussion going as usual, recognizing we'll soon add some clarity to the planning.
Thanks for your patience, too.
Ken Gracey
No triple @ is not supported. It's pretty difficult to implement without significant rework to how the compiler works (which is pretty much exactly how Chip's x86 compiler works). I've explained in greater detail in the past, and it's difficult to search for because of how the forum treats the triple @. /sigh
Back when it was all the rage, the only concrete example of it's usage was "PropBASIC needs it" but it was never clear to me why. Everyone kept posting contrived example use cases, but not anything that could not be done some other way.
Good, Ken, that you read this. It will not work, not to invest money for a "solid C/C++ solution" with inline assembler as fast as possible. This must be the base of the libraries.
-Phil
I feel your pain having gone to all that trouble with OpenSpin.
And I agree, since we now have Eric’s FastSpin for P2 (and P1), it would probably make more sense to add spin bytecode output if Eric’s willing.
Of course, Chip has signalled there will be a PropTool2 although it has all the baggage of the original PropTool. I, and many others, disagree with this path, but it’s not our company.
The same think will eventually happen regarding the software for the P2. Personal preference will win.
Kind regards, Samuel Lourenço
Samuel, did you ever see this?
https://developer.parallax.com/propelleride/
Ken Gracey