Spin2 Semantics

13

Comments

  • jmg wrote:
    Were that is needed in other languages, I've see underscore '_' used as a line continuation - that seems a natural symbol ?
    I like the _ as a line continuation. A bare _ with a space before it seems very natural to me and doesn't conflict with its other use.

    -Phil

    This is the best approach, I agree.
  • cgracey wrote: »
    David Betz wrote: »
    cgracey wrote: »
    [I figure there are going to be more P2 programmers than P1 programmers, so it's not so critical to hold onto every old way.
    I certainly hope that is true. However, I wonder what kind of image this is going to present for Parallax if people start realizing that every new version of the Propeller is likely to have a new language. While people kind of expect this of the assembly language of a processor it isn't so common for high-level languages. Maybe Spin is supposed to be somewhere in between. Actually, I don't think the issue is so much code portability between the P1 and P2 as it is programmer portability. There are a number of quirks in Spin1 and it seems there will be different ones in Spin2. Moving back and forth between the two is likely to be confusing. Does that matter to you?

    It matters somewhat, but to stay fully compatible with everything is not realistic. We'll have some different math operators and function pointers added. The rest is pretty much the same.
    Those don't sound very P2 specific. Couldn't Spin2 be made to target P1 as well?

  • cgracey wrote: »
    jmg wrote:
    Were that is needed in other languages, I've see underscore '_' used as a line continuation - that seems a natural symbol ?
    I like the _ as a line continuation. A bare _ with a space before it seems very natural to me and doesn't conflict with its other use.

    -Phil

    This is the best approach, I agree.

    +1
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    cgracey wrote: »
    [I figure there are going to be more P2 programmers than P1 programmers, so it's not so critical to hold onto every old way.
    I certainly hope that is true. However, I wonder what kind of image this is going to present for Parallax if people start realizing that every new version of the Propeller is likely to have a new language. While people kind of expect this of the assembly language of a processor it isn't so common for high-level languages. Maybe Spin is supposed to be somewhere in between. Actually, I don't think the issue is so much code portability between the P1 and P2 as it is programmer portability. There are a number of quirks in Spin1 and it seems there will be different ones in Spin2. Moving back and forth between the two is likely to be confusing. Does that matter to you?

    It matters somewhat, but to stay fully compatible with everything is not realistic. We'll have some different math operators and function pointers added. The rest is pretty much the same.
    Those don't sound very P2 specific. Couldn't Spin2 be made to target P1 as well?

    Certainly, it could be made to work, minus the CORDIC stuff.
  • IMHO

    Spin2 should be as far as possible a superset of Spin1, while fixing the gotchas.
    This helps those of us who program both P1 and P2 transition back and forth easier.

    I don’t expect Spin2 to ever target P1. There are too many extras in P2. Just forget this one.

    I will complete my Faster Spin1 Interpreter to P2. That’s my base because it’s totally the spin1 ROM compatible, but faster using a vector table decode which is similar to using execf/skip. Tho not finished, I can run PropTool compiled spin bytecode on P2 much faster, but in bytecode. Fastspin is different and yet the same. I don’t see any reason both cannot co-exist. If you have the space and want faster execution, use Fastspin.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • cgracey wrote: »
    David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    cgracey wrote: »
    [I figure there are going to be more P2 programmers than P1 programmers, so it's not so critical to hold onto every old way.
    I certainly hope that is true. However, I wonder what kind of image this is going to present for Parallax if people start realizing that every new version of the Propeller is likely to have a new language. While people kind of expect this of the assembly language of a processor it isn't so common for high-level languages. Maybe Spin is supposed to be somewhere in between. Actually, I don't think the issue is so much code portability between the P1 and P2 as it is programmer portability. There are a number of quirks in Spin1 and it seems there will be different ones in Spin2. Moving back and forth between the two is likely to be confusing. Does that matter to you?

    It matters somewhat, but to stay fully compatible with everything is not realistic. We'll have some different math operators and function pointers added. The rest is pretty much the same.
    Those don't sound very P2 specific. Couldn't Spin2 be made to target P1 as well?

    Certainly, it could be made to work, minus the CORDIC stuff.
    I wasn't actually suggesting that you should create a Spin2 runtime environment for P1 immediately, just that it ought to be possible. My guess is that Eric will probably do it in fastspin once there is a stable definition of Spin2.
  • David Betz wrote: »
    cgracey wrote: »
    Certainly, it could be made to work, minus the CORDIC stuff.
    I wasn't actually suggesting that you should create a Spin2 runtime environment for P1 immediately, just that it ought to be possible. My guess is that Eric will probably do it in fastspin once there is a stable definition of Spin2.

    I don't know; it depends on how different Spin2 is from Spin1. I'm getting a bit nervous about how many changes there may be in Spin2. Chip can work on this full time, but I can't afford to, I'm afraid.
  • ersmith wrote: »
    David Betz wrote: »
    cgracey wrote: »
    Certainly, it could be made to work, minus the CORDIC stuff.
    I wasn't actually suggesting that you should create a Spin2 runtime environment for P1 immediately, just that it ought to be possible. My guess is that Eric will probably do it in fastspin once there is a stable definition of Spin2.

    I don't know; it depends on how different Spin2 is from Spin1. I'm getting a bit nervous about how many changes there may be in Spin2. Chip can work on this full time, but I can't afford to, I'm afraid.

    Eric, I really don't think it amounts to a whole lot. I'm just spending a lot of time on implementation details now. In the end, it'll be what you'd imagine with a few tweaks. Nothing crazy. There's just not much to Spin, anyway.
  • jmgjmg Posts: 13,917
    Cluso99 wrote: »
    I will complete my Faster Spin1 Interpreter to P2. That’s my base because it’s totally the spin1 ROM compatible, but faster using a vector table decode which is similar to using execf/skip. Tho not finished, I can run PropTool compiled spin bytecode on P2 much faster, but in bytecode. Fastspin is different and yet the same. I don’t see any reason both cannot co-exist. If you have the space and want faster execution, use Fastspin.

    Does this Spin 1.5? have a conditional compile support, to allow one source file to target both P1 & P2 ?

  • jmg wrote: »
    Cluso99 wrote: »
    I will complete my Faster Spin1 Interpreter to P2. That’s my base because it’s totally the spin1 ROM compatible, but faster using a vector table decode which is similar to using execf/skip. Tho not finished, I can run PropTool compiled spin bytecode on P2 much faster, but in bytecode. Fastspin is different and yet the same. I don’t see any reason both cannot co-exist. If you have the space and want faster execution, use Fastspin.

    Does this Spin 1.5? have a conditional compile support, to allow one source file to target both P1 & P2 ?

    It’s the interpreter, not the compiler.

    Having said that, bst and homespun both support conditional compilation and IIRC they can output just the spin bytecode section. OpenSpin supports conditional compilation too.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • jmgjmg Posts: 13,917
    Cluso99 wrote: »
    It’s the interpreter, not the compiler.
    Well yes, I can rephrase : does it support conditional code interpreter parsing ?
    ie like the C #define, #ifdef, #include et al.
    Cluso99 wrote: »
    Having said that, bst and homespun both support conditional compilation and IIRC they can output just the spin bytecode section. OpenSpin supports conditional compilation too.
    Do any of those support P2 ?

    This is for the teaching situation post from above, where there is appeal for a single source file, that can run on either/any Parallax hardware platform the class may have.


  • Cluso99 wrote: »
    Dave Hein wrote: »
    Cluso99 wrote: »
    David Betz wrote: »
    jmg wrote: »
    Being able to easily move legacy P1 code to P2, has clear appeal, and it sounds like Cluso99 intends to cover that base ?
    Eric's fastspin covers this case and exists already.

    While it covers the case, it is NOT the same as it compiles to PASM. Thus, anything that is RAM critical, or even with some RAM free, may not work due to larger code size.

    I am talking about a Spin1 interpreter running on P2. I stopped working on it a couple of months age when I thought there was no need. I am now convinced otherwise, so I'll finish it when I get time, which is currently short atm.

    I believe all 3 can and will co-exist (fastspin, spin1 on P2, spin2) for P2. Each will have their audience.

    I think it's a good idea to have a Spin1 interpreter for the P2. This will allow P1 Spin programs to run on the P2 with little or no changes to the Spin source code. The programs would have to run in the lower 64K of RAM, but the upper RAM could be used for display memory and user data. Now that Chip has posted his Spin2 interpreter it should be fairly easy to modify it to run Spin1 bytecodes.

    No need to use Chip's Spin2. I have already done most of the bytecode spin1 interpreter in P2ASM and it uses skip and will use skip/skipf/execf once its fully debugged. Fortunately I already had my Spin Fast Interpreter using a vector table for all bytecodes which meant that using execf is a breeze.

    I am known to be a PITA sometimes, but a P1 PASM emulator could allow to run not just Spin1 but also PASM1 on the P2. But the main point here is to have Spin2 not being completely different.

    cgracey wrote: »
    David Betz wrote: »
    cgracey wrote: »
    [I figure there are going to be more P2 programmers than P1 programmers, so it's not so critical to hold onto every old way.
    I certainly hope that is true. However, I wonder what kind of image this is going to present for Parallax if people start realizing that every new version of the Propeller is likely to have a new language. While people kind of expect this of the assembly language of a processor it isn't so common for high-level languages. Maybe Spin is supposed to be somewhere in between. Actually, I don't think the issue is so much code portability between the P1 and P2 as it is programmer portability. There are a number of quirks in Spin1 and it seems there will be different ones in Spin2. Moving back and forth between the two is likely to be confusing. Does that matter to you?

    It matters somewhat, but to stay fully compatible with everything is not realistic. We'll have some different math operators and function pointers added. The rest is pretty much the same.

    This sounds nice, my pledge here is to not change basic things like the assignment operator from := to = this would be simply silly and complete unneeded.

    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.
  • jmg wrote: »
    Cluso99 wrote: »
    I will complete my Faster Spin1 Interpreter to P2. That’s my base because it’s totally the spin1 ROM compatible, but faster using a vector table decode which is similar to using execf/skip. Tho not finished, I can run PropTool compiled spin bytecode on P2 much faster, but in bytecode. Fastspin is different and yet the same. I don’t see any reason both cannot co-exist. If you have the space and want faster execution, use Fastspin.

    Does this Spin 1.5? have a conditional compile support, to allow one source file to target both P1 & P2 ?

    yes, FastSpin does this already.

    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.
  • msrobots wrote: »
    I am known to be a PITA sometimes, but a P1 PASM emulator could allow to run not just Spin1 but also PASM1 on the P2.
    Another possibility would be to assemble P1 assembly source directly into P2 machine code. For the most part P1 assembly is just a subset of P2 assembly with some changes that have been made to the symbol names. There are also some P1 instructions that are implemented differently on the P2, such as WAITCNT and the LOCK instructions. The tricky part would be to implement the P1 counters and video functionality on the P2.

  • Problem is a lot of P1 code uses self-modifying code extensively. Also not all P1 opcodes map onto a single P2 opcode.
  • msrobots wrote: »
    ...
    This sounds nice, my pledge here is to not change basic things like the assignment operator from := to = this would be simply silly and complete unneeded.

    Mike

    Agreed.
  • The latter case can be handled fairly easily. As an example, a WAITCNT would generate an ADDCT1 followed by a WAITCT1.

    Self-modifying code for the source or destination values should work OK, except that extra delay may need to be added. A MOVI could be handled as long as an immediate source value is specified. The assembler would have to map the P1 opcode to the appropriate P2 opcode. If an immediate value is not specified the mapping would have to happen at run time. In this case the assembler would have to signal that it couldn't handle the instruction.
  • C programmers are already familiar with line continuation using the backslash "\" char but maybe this is not possible if this char gets used elsewhere as an operator in Spin2 (does it?).

    I guess like a book splits words over lines using hyphens, Spin2 can similarly split its commands over two or more lines with underscores. I sort of get it but it'll be weird to see at first, as a C programmer anyway. But people adapt.
  • cgraceycgracey Posts: 11,710
    edited 2019-06-05 - 02:16:58
    rogloh wrote: »
    C programmers are already familiar with line continuation using the backslash "\" char but maybe this is not possible if this char gets used elsewhere as an operator in Spin2 (does it?).

    I guess like a book splits words over lines using hyphens, Spin2 can similarly split its commands over two or more lines with underscores. I sort of get it but it'll be weird to see at first, as a C programmer anyway. But people adapt.

    Underscores look like minus signs: - _

    Who will know what that character is dangling out there?
  • Cluso99Cluso99 Posts: 15,398
    edited 2019-06-05 - 02:47:37
    jmg wrote: »
    Cluso99 wrote: »
    It’s the interpreter, not the compiler.
    Well yes, I can rephrase : does it support conditional code interpreter parsing ?
    ie like the C #define, #ifdef, #include et al.
    Of course not. It is an interpreter that is interpreting pre-compiled bytecode.
    Cluso99 wrote: »
    Having said that, bst and homespun both support conditional compilation and IIRC they can output just the spin bytecode section. OpenSpin supports conditional compilation too.
    Do any of those support P2 ?

    This is for the teaching situation post from above, where there is appeal for a single source file, that can run on either/any Parallax hardware platform the class may have.
    [/quote]
    No, although OpenSpin may at some time in the future. You'll need to ask Roy.
    Could be a nice project for you :)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • cgracey wrote: »

    Underscores look like minus signs: - _

    Who will know what that character is dangling out there?

    That is true. A backslash would at least separate the confusion with minus.
  • cgracey wrote: »
    msrobots wrote: »
    ...
    This sounds nice, my pledge here is to not change basic things like the assignment operator from := to = this would be simply silly and complete unneeded.

    Mike

    Agreed.

    I am not so sure.
    == should definitely stay.
    := vs = I am on the fence because it's used in a lot of other languages.

    I am all for trying to use consistent behaviour between different languages.

    For instance, I am currently coding in Python. Great, lots of those horrid { } in C are gone. But then they add : after if xyz: and else: and then they use elif xxx: Since Python is indented like spin, why the need for ":"?

    Oh why can't the basics be the same...
    if...elseif...else...
    case...opt1...opt2...else/other/whatever
    pub/pri/sub/def/
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99Cluso99 Posts: 15,398
    edited 2019-06-05 - 02:58:47
    Dave Hein wrote: »
    msrobots wrote: »
    I am known to be a PITA sometimes, but a P1 PASM emulator could allow to run not just Spin1 but also PASM1 on the P2.
    Another possibility would be to assemble P1 assembly source directly into P2 machine code. For the most part P1 assembly is just a subset of P2 assembly with some changes that have been made to the symbol names. There are also some P1 instructions that are implemented differently on the P2, such as WAITCNT and the LOCK instructions. The tricky part would be to implement the P1 counters and video functionality on the P2.
    Been there, done that...

    JMPRET (JMPRET/CALL/RET) is a major stumbling block, and its heavily used in P1 :(
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • rogloh wrote: »
    cgracey wrote: »

    Underscores look like minus signs: - _

    Who will know what that character is dangling out there?

    That is true. A backslash would at least separate the confusion with minus.

    And the backslash is also compatible with C preprocessors if they get used for conditional compilation in any toolchain at some point.
  • cgraceycgracey Posts: 11,710
    edited 2019-06-05 - 03:13:50
    Which is better?
    CLKSET(clkmode,clkfreq)
    
    -or-
    CLKSET(clkfreq,clkmode)
    
  • msrobotsmsrobots Posts: 2,909
    edited 2019-06-05 - 03:28:12
    depends if you will allow predefined optional parameters like FastSpin does.

    PUB writeStringAtPos(parString as string, parX=2, parY=3)

    Enjoy!

    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.
  • jmgjmg Posts: 13,917
    cgracey wrote: »
    Which is better?
    CLKSET(clkmode,clkfreq)
    
    -or-
    CLKSET(clkfreq,clkmode)
    

    My personal preference is to have the clkfreq first, as that is the `dominant` parameter here, but it does not really matter in the big picture...
  • koehlerkoehler Posts: 577
    edited 2019-06-05 - 03:45:14
    cgracey wrote: »
    I just want it to be optimal for what it is.

    I agree with msrobots, insofar as :=/=, etc.

    Nothing is going to turn people off any less now than it did 10 years ago, and thats YAFPL.
    I think having special glyphs or non-standard assignment/equals testing, etc is yet again cutting off one's nose in the Not Invented Here syndrome seen here last decade with Interrupts.
    ..
    ..
    ..Actually, maybe just forget everything I wrote.
    If there is a Basic available for P2, I would expect education to jump on that vs Spin. Maybe Python if its ready.
    If there really was a focus on Education, then Parallax would simply focus on Python first and foremost, or whatever else if the big, current draw in the edu sector, blockly, wiring, ?
    Spin is most likely the realm of enthusiasts, and as such focusing on speed, etc and being Chip's baby is fine.
    Trying to sell it as for the edu market is just not realistic.

    ---- This space available for rent ----<br>
  • jmgjmg Posts: 13,917
    koehler wrote: »

    ..Actually, maybe just forget everything I wrote.
    If there is a Basic available for P2, I would expect education to jump on that vs Spin. Maybe Python if its ready.
    ...
    Both of those exist already. Python is more experimental, whilst the Basic compiler comes with Spin and C too...
    see:
    https://forums.parallax.com/discussion/164187/fastspin-compiler-for-p2-assembly-spin-basic-and-c-in-one-compiler/p1

    https://forums.parallax.com/discussion/169862/micropython-for-p2/p1

    last reports had Python running VGA+USB, via `The Spin/C part runs in Risc-V emulation. The PASM part runs in another COG, natively`, which is sounding quite impressive really.
    koehler wrote: »
    If there really was a focus on Education, then Parallax would simply focus on Python first and foremost, or whatever else if the big, current draw in the edu sector, blockly, wiring, ?
    Blockly ? - and with that, comes C. I'm not sure if the P2 fastspin C can compile Blockly-generated-C yet, IIRC from comments the main issue was around libraries, rather than compiler depth.

  • cgraceycgracey Posts: 11,710
    edited 2019-06-05 - 03:44:54
    koehler wrote: »
    cgracey wrote: »
    I just want it to be optimal for what it is.

    I agree with msrobots, insofar as :=/=, etc.

    Nothing is going to turn people off any less now than it did 10 years ago, and thats YAFPL.
    I think having special glyphs or non-standard assignment/equals testing, etc is yet again cutting off one's nose in the Not Invented Here syndrome seen here last decade with Interrupts.
    ..
    ..
    ..Actually, maybe just forget everything I wrote.
    If there is a Basic available for P2, I would expect education to jump on that vs Spin. Maybe Python if its ready.
    If there really was a focus on Education, then Parallax would simply focus on Python first and foremost, or whatever else if the big, current draw in the edu sector, blockly, wiring, ?
    Spin is most likely the realm of enthusiasts, and as such focusing on speed, etc and being Chip's baby is fine.
    Trying to sell it as for the edu market is just not realistic.

    My brother Ken is flying back from a teacher training he just did in Chicago and they used MicroBit Python over the web. The teachers loved it because no app was required. Having teachers and students install apps to do something is always a protracted nightmare.
Sign In or Register to comment.