SPIN2 operators (was ".spin extension")
Seairth
Posts: 2,474
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...)
@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...)
Comments
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.
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.
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.
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 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.
-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.
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....
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...
-Phil
Do we really need to add all the complexity of C to Spin? We already have C.
-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.
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
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.
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.
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
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
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.
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?
-Phil