How should comments and expressions work in PASM that isn't inside Spin?
ersmith
Posts: 5,914
I've been working on expanding the inline assembly facility in FlexC and FlexBASIC, to bring it in line with what's already available in the Spin language (e.g. so that you can put PASM programs to run in another COG directly in the .c or .bas source code). But in doing that I ran into a fundamental question: what should the syntax for comments and expressions be in this inline assembly? In a .c file should all the comments be C-style ones, even inside the asm block? Or should the rules for Spin PASM apply in there?
The C style code would look like:
whereas Spin style assembly inside a C file would look like:
I can see arguments for doing it both ways:
The first way, using C style comments and expression syntax, makes the integration with C much more seamless and allows us to make use of preprocessor #defines and such inside of the inline assembly. It's also a little bit easier to implement.
The second way, using Spin style comments and expression syntax, makes cutting and pasting PASM code between languages easier, and will look more familiar to assembly language programmers.
What preferences do you guys have? (Assume I can only do one... my time is not unlimited!). I'd be particularly interested in how other language designers feel about this. @cgracey , what would you recommend? Should PASM syntax be the same within all languages? Or should it adapt in a (limited) way to the language in which it's embedded?
The C style code would look like:
__asm {
// code for blinking a pin
// gets the pin number as a parameter
org 0
entry
rdlong pinNum, ptra++
LR__0001
drvnot pinNum
waitx ##0x20000000 /* wait a bit */
jmp #LR__0001
pinNum long 0
}
whereas Spin style assembly inside a C file would look like:
__asm {
' code for blinking a pin
' gets the pin number as a parameter
org 0
entry
rdlong pinNum, ptra++
LR__0001
drvnot pinNum
waitx ##$20000000 ' wait a bit
jmp #LR__0001
pinNum long 0
}
I can see arguments for doing it both ways:
The first way, using C style comments and expression syntax, makes the integration with C much more seamless and allows us to make use of preprocessor #defines and such inside of the inline assembly. It's also a little bit easier to implement.
The second way, using Spin style comments and expression syntax, makes cutting and pasting PASM code between languages easier, and will look more familiar to assembly language programmers.
What preferences do you guys have? (Assume I can only do one... my time is not unlimited!). I'd be particularly interested in how other language designers feel about this. @cgracey , what would you recommend? Should PASM syntax be the same within all languages? Or should it adapt in a (limited) way to the language in which it's embedded?
Comments
If not, then what is the difference between detecting ' or /* or both?
Anyway, if only one is possible I vote to keep pasm syntax with pasm code.
As part if my evil plan, I’d like to use BASIC as “bait” or “training wheels”. My minions can gain confidence in basics like programming flow and logic, and then push them to get a bit more adventurous and try some inline assembly (or Spin, see below). The ultimate goal would be to let them work their way up to discarding BASIC almost entirely.
Eric: Any plans to include inline SPIN inside a BASIC program, ala the way ASM blocks are done now?
Similarly, if interpreted C style: would copy the value 65 (ASCII value of 'A') into register a, whereas in Spin it is a syntax error.
And for extra scary differences, in C the expression "2+3<<4" evaluates to "(2+3)<<4" or 80, whereas in Spin it evaluates to "2+(3<<4)" or 50.
Ok... let's try it...
...whatever you think...
Having 3 different PASM styles makes no sense for most PASM users.
Having PASM mimic the style of the outer language would be nice too... at least for me...
I have the QuickReference.pdf as cheat sheet... so there is a small chance, I'll survive it... whatever direction it will take...
Shoe-horning in just enough of Spin to do PASM inside of BASIC is going to be hard enough (although not nearly so bad for BASIC as it is for C, since BASIC syntax is already closer to Spin). Don't expect in-line Spin anytime soon.
Just to be clear: I have no intention whatsoever to change any rules for PASM inside Spin. It's only PASM inside C and BASIC that is in question.
To clarify further: there is already provision for in-line assembly (ASM blocks) in C and BASIC. It's just that so far the only use of these has been relatively simple, small enough that the need for comments and complicated expressions hasn't come up. (At the moment comments and expression parsing in in-line assembly follow the rules of the enclosing language.)
I really am torn about this, because for small snippets it's much more logical to the programmer for the ASM expressions to follow the rules of the language around it; but for large blocks of code like a whole COG program it's no longer so clear.
Maybe we need two kinds of in-line assembly, __asm and __pasm, where __pasm indicates Spin syntax. That's going to be a lot of work though
I can see now why the GCC people chose to make their in-line assembly go inside of strings, it makes the parsing much easier and avoids these syntactical issues.
I've used assemblers that can accept both. Comment to end of line is fairly easy to manage/alias.
They also tolerate 0xabcd and 0abcdH on numbers.. & can work with 32b numbers in expressions.
Comment syntax ‘ for spin/pasm would be nice to remain ‘.
As for the block comments syntax (spin/pasm) this could be changed to the local hosts version before inserting if necessary. Remember we use { } and {{ }} in spin/pasm. So Maybe we (coder) have to change any comment block encoding to the local syntax eg /* */.
I see SPIN+PASM as one thing. Technically, on P2, that does not have to be true as PASM only development is possible, and some would argue, practical.
With so many coming from P1, and or simple preferences for syntax, they are probably going to continue to be one thing. I myself much prefer things like $ for hex, and the %% notation for binary and two bit data. The 0x business is hard to read. But that's me.
There are cases:
One is a snippet. That seems like it can follow enclosing language rules with minimal fuss.
Two, a program, driver. Here, we want to leave it be. Too much to change. These won't be inlined, or if they are, it is sort of a pathological edge case, right?
Three, someone is writing SPASM. Enclosing language rules is consistent.
And there is my revised answer.
Enclosing language rules is much better than the gcc way, FWIW! So, there is that bonus.
If a particular snippet ends up being difficult, it can always be packaged up as a class, etc...
I thought Chip had cleaned up Spin, so the worse syntactic chaff was removed ? Maybe the // missed the cut ?
Something that 'fails silently' is best avoided...
Operator precedence is something users can check for in the LIST files, and brackets can always ensure you get what you expect ?
Mike
GCCs asm integration is just cruel and wrong.
Putting PASM into strings is simply ugly.
Mike
Well, but it's not an operator in C. The way you write remainder in C is with %, not //.
For programmers who are used to Spin/PASM things like // will seem natural. But a C programmer who doesn't know Spin is going to read a line like: very differently from a Spin programmer, and if you're in the middle of writing C code you might very well code this as: since you're thinking in C.
There probably isn't any one correct answer. Right now I'm leaning towards leaving __asm the way it is now (inside an __asm block comments and expressions are parsed the way the surrounding language does). I might be able to additionally achieve a subset of PASM with Spin rules inside a new keyword like __pasm. I don't know if that would make things even more confusing.
The difference in what '//' means in C versus Spin as shown in posts above, would really throw someone off (their code will execute differently, not just give them a syntax error).
Just my .02$
dgately
As a side-benefit, having the comment differ between languages is how most Polyglot programs work (though I doubt we want to target inline assembly at polyglots...).
// is not moving a finger like /* does and is seen more often in assemblers now as an alias comment.
It may be possible to allow 3 EOL cases , meaning the semicolon could become a common/portable ASM standard, clear of other syntax issues ?
It is also the comment character in a lot of other assembly languages and more easily reachable than the forward slash (at least on my QWERTZ keyboards. Shift+7, owie ouch)
Please could ' and ; both be accepted in all P2 assemblers?
Request seconded.
P2 is coming. When the original Propeller came there was a common development language for it. If you went to the OBEX looking for code you knew what language it would be in and you knew it would work in the development system you were using.
I don't care what development system that ends up being for P2. I really don't. (except I really, really hate C++ but that's just me.) But even if it's C++ we need to be clear on this. If the driver I need for a video mode, a temperature sensor, or serial port is there, it needs to either be in the language I'm using, or in the one I know I need to know to translate from. This is the way it was for P1 until $recently.
Parallax, you need to fix this before it becomes a deal-killing problem. You need to tell us what the lingua spin is for P2, and make sure we all have access to the development tools for it, and if any other languages are being seriously supported you need to make sure we have access to good paths between those and the One True Prop Language. And please, please, please don't try to pretend there is more than one True Prop Language. Decide. Tell us. And enforce it. You have to.
Ersmith,
I'm not sure what would be best. There are a lot of ramifications to supporting different comment schemes and, especially, operators with their differing precedences.
I'm with @"Dave Hein", I don't think we need to add yet another way to comment. I actually agree that semicolon would have been a nicer choice for the comment character, but Spin chose single quote a long time ago and introducing a third variant of the assembly syntax seems like a dubious idea.
Having said that, if @cgracey wants to add semicolon comments to PNut I'll support them in fastspin. I think the stand alone assembly language should be compatible across assemblers. Again, just to re-iterate, this thread has been about inline assembly inside C code. A plain .spin2 assembly file should be pretty much the same whether you compile it in PNut, p2asm, or fastspin. I did add the preprocessor, but that's a pretty common extension and can be provided by an external program. Otherwise I'd like to keep stand-alone assembler consistent.