Why can't it just be an = instead of := and no prefix or bracket wrapping? What you are doing isn't really an assignment operation anyway. It's telling it which value(s) to push on the stack for passing into the method.
Doesn't that make it unambiguous in Spin, at least in this context, since = is only used in CON sections for Spin right now?
Python has a similar thing and it just uses paramname=value
Another way to make it unambiguous is the make it some other unused symbol with the = , like .= or $= .
Why can't it just be an = instead of := and no prefix or bracket wrapping? What you are doing isn't really an assignment operation anyway. It's telling it which value(s) to push on the stack for passing into the method.
Isn't that the same as an assignment? After all, if you're transferring a value to a variable, that's an assignment, right?
Anyway, it's not just a matter of pushing values onto the stack in order. It's recognizing which values get assigned to which parameters and substituting their defaults when those values are missing. So, yes, I would definitely call it an assignment.
Phil,
If you want to get technical, then yes the parameters you pass to a function are "assigned" to the local variable inside the function, but most people don't really think of that as assignment. Yes, under the covers at the lower level it's assignment, but at the high level it's not really. I mean almost everything you do involves a mov/read/write instruction in asm, so everything is an assignment then, eh? I mean those instructions involved move one value into another, so obviously everything is an assignment under the covers. So everything at the higher levels is too. Right?!?!
What this syntax is intending to do is declare which param slot of the method you want your value or variable to go into. To me that is not an assignment operation the same way that := is, but whatever. I honestly don't care what symbol or syntax is used, but I think one that is unambiguous would be good. Also, simple is better, and to me = is simplest, also Electrodude's suggestion of a : is simple too.
Also, I agree with ersmith that the prefix symbol on the parameter name is ugly, but if that is what it end up being, then fine.
Two details emerged there:
1: ALTx instructions are not affected by AUGx instructions.
2: AUGx instructions setup special registers that can sustain indefinitely. Unlike ALTx instructions.
Which means the hidden AUGS in your example can be placed in the binary prior to the ALTR.
Comments
Doesn't that make it unambiguous in Spin, at least in this context, since = is only used in CON sections for Spin right now?
Python has a similar thing and it just uses paramname=value
Another way to make it unambiguous is the make it some other unused symbol with the = , like .= or $= .
Anyway, it's not just a matter of pushing values onto the stack in order. It's recognizing which values get assigned to which parameters and substituting their defaults when those values are missing. So, yes, I would definitely call it an assignment.
-Phil
If you want to get technical, then yes the parameters you pass to a function are "assigned" to the local variable inside the function, but most people don't really think of that as assignment. Yes, under the covers at the lower level it's assignment, but at the high level it's not really. I mean almost everything you do involves a mov/read/write instruction in asm, so everything is an assignment then, eh? I mean those instructions involved move one value into another, so obviously everything is an assignment under the covers. So everything at the higher levels is too. Right?!?!
What this syntax is intending to do is declare which param slot of the method you want your value or variable to go into. To me that is not an assignment operation the same way that := is, but whatever. I honestly don't care what symbol or syntax is used, but I think one that is unambiguous would be good. Also, simple is better, and to me = is simplest, also Electrodude's suggestion of a : is simple too.
Also, I agree with ersmith that the prefix symbol on the parameter name is ugly, but if that is what it end up being, then fine.
-Phil
I just bumped into your post in the tricks&traps topic, where you document an issue around using AUGx instructions alongside ALTx instructions - https://forums.parallax.com/discussion/comment/1466413/#Comment_1466413
There is a solution as detailed in this topic - http://forums.parallax.com/discussion/169801/augs-not-cancelling-after-a-altd-instruction
Two details emerged there:
1: ALTx instructions are not affected by AUGx instructions.
2: AUGx instructions setup special registers that can sustain indefinitely. Unlike ALTx instructions.
Which means the hidden AUGS in your example can be placed in the binary prior to the ALTR.
An aside, SETQ also has special register Q that can even be read back multiple times using MUXQ - https://forums.parallax.com/discussion/comment/1465673/#Comment_1465673