SPIN2 operators (was ".spin extension")

SeairthSeairth Posts: 2,474
edited 2016-06-16 - 18:03:15 in Propeller 2
Right now, everyone is creating sample/test code for the P2 and using the ".spin" extension. Except, these files are not compatible with Propeller 1. The new instruction set is not a superset of P1 spin, so existing P1 spin files aren't compatible with the P2 either. As a result, using ".spin" for P2 code is only going to cause increasing confusion. While working on the VSCode extension, I've been using ".p2asm" to distinguish between the two variations, but I'm not crazy about that. Maybe ".spin2" or something like that would be better.

@cgracey,

If you have a preference for an extension (other than ".spin"), can we go ahead and switch to it now? If you don't have a preference, I suggest going with ".spin2".


(Edit: Chip has taken care of the filename extension in the V10 release, so I have updated the title to reflect the discussion topic that took over the thread...)
«1

Comments

  • Spin2 for the Prop2 seems easy and natural to follow.
  • jmgjmg Posts: 14,567
    Seairth wrote: »
    While working on the VSCode extension, I've been using ".p2asm" to distinguish between the two variations, but I'm not crazy about that. Maybe ".spin2" or something like that would be better.

    Why not use both ? - in which case it might be .p2asm and .p2spin ?
    I think I saw another post around this issue, and how .spin is a poor name for what is simply a wrapper for ASM.

    Other tool chains have a quite clear .ASM and .C/.PAS/.BAS etc convention, P2 should follow that simple lead.

  • ElectrodudeElectrodude Posts: 1,437
    edited 2016-06-12 - 00:37:00
    Since Spin and PASM are one unified language, and all (standard) PASM files are really Spin files with no PUB or PRI blocks, it makes sense that they should have the same extension.

    Isn't the P2 PNUT.exe really just a Spin compiler that doesn't have any Spin2 parts implemented yet, only the PASM2 parts?
  • SeairthSeairth Posts: 2,474
    edited 2016-06-12 - 01:07:25
    Isn't the P2 PNUT.exe really just a Spin compiler that doesn't have any Spin2 parts implemented yet, only the PASM2 parts?

    It probably is. And, at some point, Chip will start working on Spin 2, as well. And may even update pnut.exe (or would it be pnut2.exe?) to support Spin 2. Since Spin is Chip's baby, I think it's up to him what extension(s) he wants to use. I don't care what extension he uses, as long as:

    * It's not ".spin"
    * He settles on something now, before we end up with a lot of P2 code with ".spin" extensions.
    jmg wrote: »
    Other tool chains have a quite clear .ASM and .C/.PAS/.BAS etc convention, P2 should follow that simple lead.

    We don't really need Chip to do this, I think. If he want's to have a combined Spin file again, that's fine with me. Separately, we (the community) can define our own .ASM version. Personally, I wouldn't use the current "spin" structure, if I were designing a stand-alone assembly language.

    But let's not get sidetracked! Right now, I just want a Spin 2 "standard" extension (other than ".spin") that we can all rally around (one that Chip will hopefully declare, so as to avoid endless discussion), that will be reflected in the FPGA image zips, that will be used by pnut2.exe (née pnut.ext), etc.
  • Maybe could add something to CON section to define prop version?
  • Rayman wrote: »
    Maybe could add something to CON section to define prop version?

    I'd prefer not to go that route. It complicates detection algorithms, and requires a user to have to open the file just to figure out which propeller the code can run on.
  • I suppose we'll have to add .binary2 and .eeprom2 as well. But, as a counter-example, Intel .hex files are ubiquitous across a slew of different processors.

    I think I would rather see a universal Spin compiler/loader that handles both, similar to the way the PBASIC editor works. For some reason, that tool uses both a pragma ( '{$STAMP BS2} ) and a file extension (.BS2, .BSX, etc.) to indicate which Stamp is being targeted.

    -Phil
  • I suppose we'll have to add .binary2 and .eeprom2 as well. But, as a counter-example, Intel .hex files are ubiquitous across a slew of different processors.

    I think I would rather see a universal Spin compiler/loader that handles both, similar to the way the PBASIC editor works. For some reason, that tool uses both a pragma ( '{$STAMP BS2} ) and a file extension (.BS2, .BSX, etc.) to indicate which Stamp is being targeted.

    -Phil

    I'm guessing the extension is for people's consumption, and the pragma is for the compiler.

    This scheme would also work fine for me (both extension and pragma). But not a special-purpose constant. Use an actual pragma that must be on the first line of the file.
  • Seairth wrote:
    Use an actual pragma that must be on the first line of the file.
    Do you think it should be in comment form, as with the PBASIC editor? Or should it be in a special syntax that causes the current compiler to error out?

    -Phil
  • Seairth wrote:
    Use an actual pragma that must be on the first line of the file.
    Do you think it should be in comment form, as with the PBASIC editor? Or should it be in a special syntax that causes the current compiler to error out?

    -Phil

    Well, you still end up using a special syntax, just embedded in a comment. Personally, I don't like using comments like this. But if there's already a precedent, I say go with what people know.
  • jmgjmg Posts: 14,567
    Seairth wrote: »
    Well, you still end up using a special syntax, just embedded in a comment. Personally, I don't like using comments like this. But if there's already a precedent, I say go with what people know.

    This brings up the need to have the tag not only at the Source File Name level, and inside the Source too, but it should also be in any binary images, so that the download tools can alert users they are about to load a P1 binary onto P2, or vice-versa....
  • jmg,
    The beginning portion of a P1 binary has a known set of stuff in it (some fixed or with limited options) that will be significantly different for P2 binaries, so it will be pretty easy for a loader to detect between the two without needing to add anything else.

    As for the file extensions debate. Personally I don't care what they are, and I am fine with them being the same even. Having a tag/pragma line that overrides a default action for the compiler is fine also.

    In an ideal world (for me), I'd like to see the compiler able to take P1 source code and be able to generate P2 binaries. This should be trivial to do for the spin parts of the code, but harder for PASM parts. Particularly timing sensitive stuff.

    Also, Spin2 (aside from P2 specific things) can be for both P1 and P2. New language features like the ternary operator, structures, function pointers, etc. that I know Chip would like to add to Spin, It just means a compile option for legacy vs. new Spin, and P1 vs P2 target.

    Get ready folks, there's lots of complication to be sorted out and made easy/simple/fun to use... ;)
  • Roy Eltham wrote:
    New language features like the ternary operator, ...
    That makes me wonder (hope) that maybe you've already snuck that into OpenSpin as a test and didn't tell anyone. I must try it! :)

    -Phil
  • Oh God no. No ternary operators. I thought Spin was supposed to be a simple language for beginners and casual programmers.

    Do we really need to add all the complexity of C to Spin? We already have C.
  • Ternary operators are great! They allow the equivalent of a simple if/then/else to be included in an expression, rather than drawn out upon multiple lines. I can't see why anyone -- well any sane person anyway :) -- would object to them.

    -Phil
  • jmgjmg Posts: 14,567
    Ternary operators are great! They allow the equivalent of a simple if/then/else to be included in an expression, rather than drawn out upon multiple lines. I can't see why anyone -- well any sane person anyway :) -- would object to them.
    They get more appealing, if the generated code can be smaller as a result.

  • Phil,
    No it's not in OpenSpin yet, because it would break compatibility with legacy Spin because of the random number operator. It will have to be on a option switch to enable it and some other keyword for doing random numbers.

    Heater,
    Chip REALLY loves the ternary operator. I do too, it's not "hard" at all, in fact I think it makes many things easier. ;)

    jmg,
    on P2 it will be smaller generated code, but on P1 it will have to use existing bytecodes so it'll likely be similar in size to the equivalent if/then/else construct. We'll see it might be able to be smaller on P1 also. I haven't really investigated it there.

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,843
    edited 2016-06-13 - 07:58:21
    Roy Eltham wrote:
    No it's not in OpenSpin yet, because it would break compatibility with legacy Spin because of the random number operator.
    Actually it would not. The random number operator is unary (at both ends). This makes it easy to disambiguate between the ternary "?" and the unary "?", viz:

    a := c > d ? x : 1

    In this example, ?x can't possibly refer to the random operator, since it leaves no operator between c > d and ?x. Therefore, it has to be part of the ternary clause. So even

    a := c > d ? ?x : 1

    makes sense.

    In the postfix situation, you'd have

    a := x ? b : 1

    Again x? as a random operator leaves no operator between x? and b, so it has to be the ternary case.

    Of course, one might be uncomfortable overloading "?" like this, even if doing so does not lead to ambiguities. But that's another question. And who's to say we can't just use "??" for the ternary case? (Personally, I'd prefer the overloaded version.)

    -Phil
  • Phil, you haven't seen how this stuff works inside of the Compiler. Yes syntactically it works out as you say. but it's easier said than done in there...

    I am working on refactoring things to make life easier for myself and to make it easier to do changes like this, so maybe, when we actually do it, I can do what you said. However, the ? random operator is kind of an oddball thing, and would be better and clearer as a keyword that produces a random number, e.g. x := RANDOM

    The refactoring might also allow me to finally get @@@ working, I have tried and given up a few times on that beast. It's not as easy as any of you have claimed or made it out to be in the past.
  • Phil,
    Ternary operators are great! They allow the equivalent of a simple if/then/else to be included in an expression, rather than drawn out upon multiple lines. I can't see why anyone -- well any sane person anyway -- would object to them.
    Did the smiley in there indicate this is all tongue in cheek?

    This person, sane or otherwise, feels that ternary operators make code harder to read and hide structure.

    Hiding ternary if/the/else inside expressions is is even worse. Almost as bad as putting assignments, as side effects, inside conditional expressions like actual if/while/for etc.
  • fastspin (aka spin2cpp) implements the ternary operator as:
      a := if c < 2 then x else 1
    
    which means adding one keyword (then) to the language. I suppose we could even dispense with the "then", but it reads better with it I think.
  • And I'll echo Roy's comment that @@@ is harder than it looks. fastspin only partially supports it :(
  • Roy Eltham wrote:
    Yes syntactically it works out as you say.
    Well ... maybe not. Here's a counterexample:

    a := b ? ? c : d

    So is that (b?) ? c : d or b ? (?c) : d ?

    The way fastspin does it is certainly easy to read. And even though if and else are overloaded, their context as part of an expression is well-established before they're encountered, so it should be easy to parse.

    BTW, Roy, is there a formal grammar for Spin?

    -Phil
  • I'm not aware of any formal grammar for Spin.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,843
    edited 2016-06-13 - 17:51:59
    Roy Eltham wrote:
    I'm not aware of any formal grammar for Spin.
    I remember Chip saying that he wrote the Spin compiler using recursive-descent. If you've done the same, a CFG should pretty much fall out from the compiler's function calls.

    BTW, the ternary operator could also be expressed as a pseudo-function:

    a := ifelse(b > c, d+5, e)

    That may be the most Spin-like approach. Plus it alleviates any need to assign it a precedence.

    -Phil
  • I ported chips x86 asm to C/C++. It's pretty much doing things the same way. I wouldn't call the way it parses the language recursive anything.

    It compiles the objects in a recursive decent manner, reusing the same data structures as it goes and redoing the first pass compile on parents as it returns up the chain (to get the data structures fixed back up). Leaf objects are completely compiled in isolation, and first.

    Anyway, I'm not in favor of any oddball variants of the ternary operator. I think the best option is that we have old Spin/PASM (the stuff we have now on P1), and then the new Spin/PASM. I like the idea of having an option to target P1 with a variant of the new Spin/PASM that contains the new language features/etc. but uses P1 specifics instead of P2 specifics.

    Also, get this into your heads now, new Spin/PASM is *NOT* going to be source compatible with old Spin/PASM. That is a given that was decided a long time ago by Chip. However, the new Spin/PASM will be familiar and easy to transition to for existing Spin/PASM users. Expecting more than that is unreasonable and limiting.

    You could call new Spin/PASM by the name Spin2/P2ASM, but that might get confusing when you have Spin2-ish/PASM available to P1. It all gets muddled by the fact that Spin contains keywords/functionality that is specific to the Propeller instruction set (which is vastly different on the P2). So you really can't talk about Spin as a generic language like C, Pascal, etc., because the platform specific runtime library is included in the language.

  • It's unfortunate that Spin2 will not at least be backward compatible with Spin. Not only are you asked to learn a new language (Spin) to use the Propeller. You're also asked to learn another new language with each new Propeller chip? I know you say it will be "familiar" but it won't be the same and transitioning back and forth for people who want to use both P1 and P2 will be cumbersome and error prone. I don't see why Spin2 can't be a superset of Spin.
  • David,
    Primarily because of the last part of my message above. Spin contains keywords/functionality that are specific to the P1, and are not compatible with the P2, which will have to have it's own set of keywords specific to it. Some of the keywords could stay the same, but the params might need to be different (that's even worse). In order to get what you want, you'd need to make a P1 emulator for P2.

    The generic parts of the language will likely be just a superset of Spin in almost all cases. I think the only thing currently planned to be different in the "generic" stuff is the ? operator, and really, how many people were even aware of the existing ? functionality before this thread? How many of those actually used it for something in Spin code?
  • ElectrodudeElectrodude Posts: 1,437
    edited 2016-06-13 - 19:45:31
    A common subset of Spin, Spin2, etc. should be defined that includes basic things like CON, VAR, OBJ, and much of PRI and PUB syntax. Spin, Spin2, and any other spin variant (such as the x86 Spin people like Heater IIRC and myself have considered) should all comply with this basic subset. Stuff like register bit ranges (e.g. outa[21..13]) and I/O should be extensions to this basic subset, as well as features relying on the P-code nature of the PNUT interpreter (for function pointers and coroutines and stack trickery and such). That way, simpler pure Spin objects that don't directly do any I/O, such string manipulation objects and serial protocol objects that just talk to FDS but don't actually do the I/O themselves, will be compatible between different versions of Spin.
  • Roy Eltham wrote:
    ... and really, how many people were even aware of the existing ? functionality before this thread? How many of those actually used it for something in Spin code?
    Seriously, Roy? It gets used all the time! How else would you add randomness to a Spin program's behavior?

    -Phil
Sign In or Register to comment.