Forum Update - Announcement about May 10th, 2018 update and your password.

What is Spin2?

What is Spin2? Is it a version of Spin for the P2 or is it just a revision of Spin that will be available for either P1 or P2? Parallax will soon (I hope!) have two versions of the Propeller. I'm wondering if people will have to learn two subtly different languages if they hope to program both P1 and P2. Also, some of the changes that are being proposed for Spin2 would be equally welcome when programming the P1. Are P2 and Spin2 linked or is each separately an evolution of its predecessor?
«1

Comments

  • 60 Comments sorted by Date Added Votes
  • Clock LoopClock Loop Posts: 1,443
    edited January 17 Vote Up0Vote Down
    I don't know the answers to your questions, i just wanted to comment on how parallax in the past has offered many variations of their cpus, and some used the same languages, some languages had extra features that only worked with the new chips, etc..

    And simply, parallax just included a directive to tell the compiler what was what.


    I didn't even know spin2 was a thing...

    Considering the p2 is not a simple dip capable platform, it changes the accessibility to many. (1.5v and 3.3v)

    The biggest thing I am seeing here with parallax, is they aren't offering many variants of the P1, like they did with the stamp and the sx.

    I think they should make many variants of the P1, because it means the platform stays accessible in a dip...

    This would allow the p2 features to be backward engineered into a p1 variant that has a different hardware config than the p1, thus needing a spin2 language to work.

    Hack the p2 up into many p1 variants when its done, and put it all under a spin2 language standard. :)
    That would then align with the history of parallax's profit model, which HAS been successful.
    To study the nature of randomness in a digital processor network using the same clock source, 54 prop chips were all connected to a master prop. http://forums.parallax.com/discussion/127983/55-parallax-propeller-s-parallells-processing-of-permanent-perturbations/p1
    Optic communication between homogenous and commensurable, 8-core, 635nm emitting, phase locked loop, bit salad tossing units? http://forums.parallax.com/discussion/comment/1248240/#Comment_1248240
    TheBlackBox: Release v2.0 - Propeller HSS FX/Sequencer with Digital Audio SPDIF output. http://forums.parallax.com/discussion/115258/theblackbox-release-v2-0-propeller-hss-fx-sequencer-with-digital-audio-spdif
    E-Tools - Mono555 calculator, resistor calculator, voltage divider calculator, RCtime calculator, LM317 calculator, Binary-Hex-Decimal calculator, Resistor color matrix, Series LED resistance calculator, OHMS LAW calculator.
    http://forums.parallax.com/discussion/81449/e-tools-html-java-script-electronic-design-tools-free-for-you
  • Spin2 is for the Prop2, only.

    I suppose it could be made to work on the Prop1, but it's maybe not worth the effort.
  • cgracey wrote: »
    Spin2 is for the Prop2, only.

    I suppose it could be made to work on the Prop1, but it's maybe not worth the effort.
    In that case I would suggest making as few changes as possible to avoid confusing people who want to use both or people who want to migrate from the P1 to the P2.

  • jmgjmg Posts: 11,248
    edited January 18 Vote Up0Vote Down
    David Betz wrote: »
    In that case I would suggest making as few changes as possible to avoid confusing people who want to use both or people who want to migrate from the P1 to the P2.

    If that is the target, (ie people who want to use both ), then best call it "Spin1 for P2", rather than Spin2, and include a P1 code generator and conditionals, so ONE SOURCE really can run on P1 or P2.
    Now it can be called Spin1 for P2 and P1, from a single executable.

    The conditionals are used for handling those Timer/Counter/PASM areas, where P2 silicon is not actually anything like P1.

    Anything less risks falling between two stools - it fails to be a (single) language that can actually be used for both.

  • Certainly the PASM part will be different between P1 and P2. The high-level syntax doesn't have to be different though. It seems to me that making the high-level syntax different is shooting yourself in the foot. It was hard enough to get people to learn a new language to use P1. Now you'll tell them that they need to do it all over again to move from P1 to P2? Or do you not care about the P1 customers? And don't say that the Spin and Spin2 are very similar so it should be easy to move from one to the other. If the operators are different it will be hard to remember which set to use. And there is no reason for them to be different. That is why I asked if Spin2 would be able to target both P1 and P2. That seems like the most sensible approach to me. Have a different assembler but the same high-level syntax.

    Also, don't start with a compiler written in x86 assembly language. Have Roy work with Chip to create Spin2 in C++ from the start. Why go through the extra step of having Chip write in x86 code and Roy translate that to C++? Chip should just stick with language design and let Roy do the implementation.
  • rjo__rjo__ Posts: 1,932
    edited January 18 Vote Up0Vote Down
    David Betz wrote: »

    Also, don't start with a compiler written in x86 assembly language. Have Roy work with Chip to create Spin2 in C++ from the start. Why go through the extra step of having Chip write in x86 code and Roy translate that to C++? Chip should just stick with language design and let Roy do the implementation.

    I made that kind of mistake once... biggest mistake of my life. I would encourage Chip to not do this.

    What happens when Roy gets sick or decides he isn't happy with Parallax?

    As a product owner, you have to absolutely be the master of your own product.

    ...or the future is whatever happens next, not what you plan.

    If that means using an old assembly language that you know like the back of your hand... so what?

    I consider Spin1 to be a macro language, closely tied to the functionality of the P1.
    I expect Spin2 to be similar but better because of more experience and a fabulous target.

    About the syntax... there is an issue. If the exact same syntax in Spin2 has a different meaning in Spin1... it will
    cause a problem... so that syntax will have to be warned... which sounds painful for everyone.

    Anything else will be flagged by the compiler and after seeing it a couple of times, you will
    stop doing it.





  • Ugh. This is hopeless. Good luck.
  • geez...:) I was supporting you... read it again!

  • Do you really think Chip wants a user to get a whole slathering of warnings?
  • rjo__ wrote: »
    David Betz wrote: »

    Also, don't start with a compiler written in x86 assembly language. Have Roy work with Chip to create Spin2 in C++ from the start. Why go through the extra step of having Chip write in x86 code and Roy translate that to C++? Chip should just stick with language design and let Roy do the implementation.

    What happens when Roy gets sick or decides he isn't happy with Parallax?

    Someone else takes over the C++ code? If it's open source from the start then that won't be a problem. And C++, while sometimes ugly, is generally a lot easier to maintain than x86 assembly.
  • David Betz wrote: »
    Certainly the PASM part will be different between P1 and P2. The high-level syntax doesn't have to be different though. It seems to me that making the high-level syntax different is shooting yourself in the foot. It was hard enough to get people to learn a new language to use P1. Now you'll tell them that they need to do it all over again to move from P1 to P2? Or do you not care about the P1 customers? And don't say that the Spin and Spin2 are very similar so it should be easy to move from one to the other. If the operators are different it will be hard to remember which set to use. And there is no reason for them to be different. That is why I asked if Spin2 would be able to target both P1 and P2. That seems like the most sensible approach to me. Have a different assembler but the same high-level syntax.

    Also, don't start with a compiler written in x86 assembly language. Have Roy work with Chip to create Spin2 in C++ from the start. Why go through the extra step of having Chip write in x86 code and Roy translate that to C++? Chip should just stick with language design and let Roy do the implementation.

    All of this makes a lot of sense to me. Changing the syntax means making people learn yet another language, and write yet another set of tools (e.g. syntax highlighters for editors).
  • Ersmith

    I don't know that it will be open sourced from the start. Seems to me that we are at the start and I haven't seen any
    '86 assembly floating around.

    OK... so you find another C++ programmer, maybe have a couple sitting around, given jobs they think are important.
    Just to be safe.... $500,000 per year... just to be safe.

    I have to admit that since Apple dropped Pascal without notice to me, I have hated all computer languages.
    Maybe a bit of an over-reaction on my part(sort of a prejudice)...just stating the fact.

    It seems to me that modernity in C might come with a bit of overhead?

    When we are counting clocks, down to the clock... doesn't all of that overhead have any impact?
    That is an honest question, I really don't know.

    Thanks

  • rjo__ wrote: »
    I made that kind of mistake once... biggest mistake of my life. I would encourage Chip to not do this.

    What happens when Roy gets sick or decides he isn't happy with Parallax?
    As a product owner, you have to absolutely be the master of your own product.

    ?? I think David was NOT meaning 'hand ownership over', he was meaning "get someone who knows what they are doing, to quickly make a framework that can be improved.."
    Ownership is never 3rd-party-only.

    David Betz wrote: »
    That is why I asked if Spin2 would be able to target both P1 and P2. That seems like the most sensible approach to me. Have a different assembler but the same high-level syntax.

    Yes, if your primary focus is to cover both P1 and P2 bases here, a single compiler (& simulator?) that can emit both P2 and P1 code seems the only way.
    Two separate tool flows will always diverge in the parser details... creating many nasty bugs where code compiles without errors, but is not quite the same...
    David Betz wrote: »
    Also, don't start with a compiler written in x86 assembly language.

    Yikes, I was assuming x86 was well off the table by now. Surely Chip is not still coding in that ?

  • jmg

    Sorry

    I should have used a different word... "you have to know it better than anyone else." There can't be any black holes.

    "Yikes, I was assuming x86 was well off the table by now. Surely Chip is not still coding in that ?"

    You need to pay more attention:)

    absolutely kidding.




  • jmg wrote: »
    ...
    Yikes, I was assuming x86 was well off the table by now. Surely Chip is not still coding in that ?

    Yes he does.

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Roy ElthamRoy Eltham Posts: 2,263
    edited January 18 Vote Up0Vote Down
    As it stands right now, Chip is coding the compiler stuff in x86 with the pnut wrapper in Delphi, just like he did for P1. There is a bunch of it that is the same as the P1 version, so I won't have to do a full port again. There are chunks of it that I'll have to do diffs between old and new and implement the changes into my code, and then there are chunks that I will have to port from x86 fresh. So the effort required to port Chip's x86 for this new stuff won't be as much as the original work was....

    Honestly, I don't have the time available in order to have it work where I implement Chip's design, bypassing the x86 step. For things to work that way I'd basically need to work almost full time with Chip. However, I intend to get updates as Chip goes, and incrementally update OpenSpin with the changes. It's also possible that after a certain point new things would just be done in OpenSpin instead of x86. In any case, I think it's very likely we will have OpenSpin for Spin2 available (and used as the main compiler) from the start. It may be that someone else here can jump in and help? That's kind of up to Chip/Ken/etc.

    However, they still aren't using OpenSpin as the "official" compiler for P1. I did a bunch of changes so that we could integrate it into PropTool, but Jeff Martin hasn't had time (or priority) for it. Which is fine, we should drop PropTool anyway, since it's windows only. Last I saw Propeller IDE was using bstc by default (but you could switch it to OpenSpin (A variant Brett made of it anyway)), and that seems to be stagnant now too. All the focus seems to be on Blockly, which targets C.

  • rjo__ wrote: »
    geez...:) I was supporting you... read it again!
    My "ugh" was related to your statement:
    If that means using an old assembly language that you know like the back of your hand... so what?
    It just seems crazy to me to write a compiler in assembly language. How do I get it to run on the RaspberryPi or any non-Intel platform? It's got to be harder to maintain and less flexible as well. If Chip isn't comfortable writing in high-level languages, have someone work with him. He is the language designer but he doesn't have to be the implementor as well. This approach may make it easier to provide Spin2 for P1 as well as P2.
  • Roy Eltham wrote: »
    As it stands right now, Chip is coding the compiler stuff in x86 with the pnut wrapper in Delphi, just like he did for P1. There is a bunch of it that is the same as the P1 version, so I won't have to do a full port again. There are chunks of it that I'll have to do diffs between old and new and implement the changes into my code, and then there are chunks that I will have to port from x86 fresh. So the effort required to port Chip's x86 for this new stuff won't be as much as the original work was....

    Honestly, I don't have the time available in order to have it work where I implement Chip's design, bypassing the x86 step. For things to work that way I'd basically need to work almost full time with Chip. However, I intend to get updates as Chip goes, and incrementally update OpenSpin with the changes. It's also possible that after a certain point new things would just be done in OpenSpin instead of x86. In any case, I think it's very likely we will have OpenSpin for Spin2 available (and used as the main compiler) from the start. It may be that someone else here can jump in and help? That's kind of up to Chip/Ken/etc.

    However, they still aren't using OpenSpin as the "official" compiler for P1. I did a bunch of changes so that we could integrate it into PropTool, but Jeff Martin hasn't had time (or priority) for it. Which is fine, we should drop PropTool anyway, since it's windows only. Last I saw Propeller IDE was using bstc by default (but you could switch it to OpenSpin (A variant Brett made of it anyway)), and that seems to be stagnant now too. All the focus seems to be on Blockly, which targets C.
    It's good to hear that you expect OpenSpin2 to be available from the start.

  • Chip, have you considered writing it in plain old C (not C++)? I personally prefer C to C++ because it's far simpler, and there's nothing going on behind the scenes - it's usually pretty obvious what assembly any given piece of code will compile to, although it might order the instructions in a funny order. Since it's such a simple high-level language, it will probably be easier to compile it for the P2 than other high-level languages.
  • Guys, part of what makes SPIN + PASM the tight simple, lean thing it is, happens to be how working in x86 biases decisions about flexibility, and other behavior.

    If Roy says he can post it in a reasonable time, great!

    I, for one, want Chip to apply the tools to this SPIN + PASM iteration the same way it was done before.

    The product, on P1, is great. I would expect nothing less this time.



    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: http://forums.parallax.com/showthread.php?123709-Commented-Graphics_Demo.spin<br>
  • Yes, Roy will make C++ out of it and we can compile it with PropGCC to run as executable on a P2!

    Let @Chip get Spin2 and Pasm2 meld together. I am very sure that someone will build a P1-emulator for the P2 or one just uses Spin2cpp and output for P2.

    The stamps had also different languages, somehow, but programmers adapted to this quite easy. Same will go for people used to Spin with Spin2 and those not used too, will find a lot of similarities.

    Let Spin2 be Spin2 not Spin++ BUT wee need C/C++ so how to get GCC or CLANG development running again?

    I love the way Spin2 is forming and @Chip may even enjoy this part of his work more then we think. Thankfully Spin2 will not be in the ROM so it will not delay anything. @Chip is out of the fire line and can relax while doing it.

    perfect.

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • rjo__ wrote: »
    I don't know that it will be open sourced from the start. Seems to me that we are at the start and I haven't seen any
    '86 assembly floating around.
    Well, openspin is open sourced. Why not start with that as a base for Spin2?
    OK... so you find another C++ programmer, maybe have a couple sitting around, given jobs they think are important.
    Just to be safe.... $500,000 per year... just to be safe.
    ??? This one totally seems like a non-sequitor. I wasn't proposing hiring people in advance just in case you need them. I was just pointing out that if for some reason Roy (or whoever was working with Chip) was not able to continue, that then you could hire someone else to work on the code. Roy's openspin code is nice code. He's definitely the first choice for extending it, but if he's not available someone else could do the job. Heck, Chip can write Verilog, so he could write C code!

    x86 assembly code, on the other hand, is *much* harder for another programmer to pick up and maintain.
  • David BetzDavid Betz Posts: 11,943
    edited January 18 Vote Up0Vote Down
    I apologize for bringing up the x86 assembly issue. In reading over the responses here I realize that we already had this exact same discussion a while back. It is clear that the first version of Spin2 will be written in x86 assembly. I may not think that is the best approach but it is the approach Chip has said he will take. I'll stop questioning it. Sorry for the distraction!

    However, I still like the idea of a Spin2 that can target either P1 or P2. That makes it much more reasonable to change the Spin syntax a bit for Spin2. A programmer who wants to use both P1 and P2 can just migrate to Spin2 and not have to keep track of which operators work in which version of Spin. I assume that Parallax wants to continue to support both P1 and P2 going forward. I believe they've already promised that P1 will continue to be available far after P2 is launched.
  • P1 should be around forever. Maybe it could get a language upgrade, eventually.
  • David Betz,
    I have wanted that since first getting involved. I think We should plan to make Spin2 have the ability to target P1 and P2. Obviously, the PASM inside of it will be specific to the target chip, and any other chip specific features in the Spin side of things would be different depending on the target, but all the syntax, operators, etc. should be able to be the same on both. Any new stuff that can't be made to work using the existing P1 bytecode are just not there for that target.

    Chip,
    Yes, we should plan on this. I for one intend to continue using P1 along side P2, and my coding experiences would be much better if I had all the new Spin features that can work on P1 available there.
  • Roy Eltham wrote: »
    David Betz,
    I have wanted that since first getting involved. I think We should plan to make Spin2 have the ability to target P1 and P2. Obviously, the PASM inside of it will be specific to the target chip, and any other chip specific features in the Spin side of things would be different depending on the target, but all the syntax, operators, etc. should be able to be the same on both. Any new stuff that can't be made to work using the existing P1 bytecode are just not there for that target.

    Chip,
    Yes, we should plan on this. I for one intend to continue using P1 along side P2, and my coding experiences would be much better if I had all the new Spin features that can work on P1 available there.
    Sounds like a good plan. Let me know if there is anything I can do to help.
  • Roy Eltham wrote: »
    Chip,
    Yes, we should plan on this. I for one intend to continue using P1 along side P2, and my coding experiences would be much better if I had all the new Spin features that can work on P1 available there.

    Agreed, This will be important to any 'Spin Eco system' - a old and frozen language does not appeal to managers approving design directions.
    cgracey wrote: »
    P1 should be around forever. Maybe it could get a language upgrade, eventually.

    I think that 'maybe..eventually' focus is quite wrong, as Roy says (and does already in his flow) New Spin should emit for BOTH P1 and P2, from the start.

    Some conditional defines around Timer/PASM blocks, and you should be able to have single source file, that compiles/runs on either P1/P2.

  • jmg wrote: »
    Roy Eltham wrote: »
    Chip,
    Yes, we should plan on this. I for one intend to continue using P1 along side P2, and my coding experiences would be much better if I had all the new Spin features that can work on P1 available there.

    Agreed, This will be important to any 'Spin Eco system' - a old and frozen language does not appeal to managers approving design directions.
    cgracey wrote: »
    P1 should be around forever. Maybe it could get a language upgrade, eventually.

    I think that 'maybe..eventually' focus is quite wrong, as Roy says (and does already in his flow) New Spin should emit for BOTH P1 and P2, from the start.

    Some conditional defines around Timer/PASM blocks, and you should be able to have single source file, that compiles/runs on either P1/P2.

    Where to spend time? I suppose I could spend the rest of my life making sure that one Spin file compiles for both Prop1 and Prop2.
  • cgracey wrote: »
    jmg wrote: »
    Roy Eltham wrote: »
    Chip,
    Yes, we should plan on this. I for one intend to continue using P1 along side P2, and my coding experiences would be much better if I had all the new Spin features that can work on P1 available there.

    Agreed, This will be important to any 'Spin Eco system' - a old and frozen language does not appeal to managers approving design directions.
    cgracey wrote: »
    P1 should be around forever. Maybe it could get a language upgrade, eventually.

    I think that 'maybe..eventually' focus is quite wrong, as Roy says (and does already in his flow) New Spin should emit for BOTH P1 and P2, from the start.

    Some conditional defines around Timer/PASM blocks, and you should be able to have single source file, that compiles/runs on either P1/P2.

    Where to spend time? I suppose I could spend the rest of my life making sure that one Spin file compiles for both Prop1 and Prop2.
    I don't see why you should have to do that. You only need to guarantee that the P1 and P2 code generators both generate correct code for any valid Spin2 high-level program. All bets are off for PASM code. It's up to the programmer to guarantee that a single Spin2 program runs on both P1 and P2 if that is their goal.
  • David Betz wrote: »
    cgracey wrote: »
    jmg wrote: »
    Roy Eltham wrote: »
    Chip,
    Yes, we should plan on this. I for one intend to continue using P1 along side P2, and my coding experiences would be much better if I had all the new Spin features that can work on P1 available there.

    Agreed, This will be important to any 'Spin Eco system' - a old and frozen language does not appeal to managers approving design directions.
    cgracey wrote: »
    P1 should be around forever. Maybe it could get a language upgrade, eventually.

    I think that 'maybe..eventually' focus is quite wrong, as Roy says (and does already in his flow) New Spin should emit for BOTH P1 and P2, from the start.

    Some conditional defines around Timer/PASM blocks, and you should be able to have single source file, that compiles/runs on either P1/P2.

    Where to spend time? I suppose I could spend the rest of my life making sure that one Spin file compiles for both Prop1 and Prop2.
    I don't see why you should have to do that. You only need to guarantee that the P1 and P2 code generators both generate correct code for any valid Spin2 high-level program. All bets are off for PASM code. It's up to the programmer to guarantee that a single Spin2 program runs on both P1 and P2 if that is their goal.

    Yup, tool vendors merely need to give designers the tool-flows, and control - the designers will decide themselves where to place the effort.

    We have had single-source-file target more than one MCU here, sure, it's not common, but is useful, especially around libraries.

    This sort of thing "demos well" to potential customers, as they can see a 'family effort' being put in by the vendor. Buyers like to know there is a step up, or down, from where they are.
Sign In or Register to comment.