Question about ~
Phil Pilgrim (PhiPi)
Posts: 23,514
I have a question about the post-clear operator, "~": if the variable it's being applied to is already zero, does the operator clear the variable again?
Now this might seem like a silly question. After all, what possible difference could it make? Well, it turns out that it makes a big difference if the variable is a handshaking flag shared by two cogs. Imagine a scenario where one cog (the client) sets the flag to request a service. (In this scenario, the client doesn't care when the server finishes performing the service — only that it fielded the request.) Another cog (the server) polls the flag and, if set, clears the flag and provides the service. Now, it would be handy to use the post-clear operator for this, as follows:
But this will not work if flag is cleared again by the operator when it's already clear. Why? Because, between the time flag is read by the server cog and the time it's re-cleared, the client may have set it, resulting in a lost request. Hence my question.
-Phil
Now this might seem like a silly question. After all, what possible difference could it make? Well, it turns out that it makes a big difference if the variable is a handshaking flag shared by two cogs. Imagine a scenario where one cog (the client) sets the flag to request a service. (In this scenario, the client doesn't care when the server finishes performing the service — only that it fielded the request.) Another cog (the server) polls the flag and, if set, clears the flag and provides the service. Now, it would be handy to use the post-clear operator for this, as follows:
[b]repeat[/b]
[b]if[/b] flag~
perform_service
But this will not work if flag is cleared again by the operator when it's already clear. Why? Because, between the time flag is read by the server cog and the time it's re-cleared, the client may have set it, resulting in a lost request. Hence my question.
-Phil
Comments
This is an interesting point. Like Mike said, the post-clear and post-set operators both re-write zero if it was present. I wish this issue would have occurred to me earlier. I've found a few other minor things that I wish had been done differently, too, like have a post-NOT operator. We could always do this: keep the interpreter as a live program which gets downloaded each time you load your program. It would take 2KB of RAM. This would allow us to make changes to BOTH the interpreter AND compiler. What do you think about a static 2KB penalty?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Or alternatively, you could have a pointer defining the location of the interpretor.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life is one giant teacup ride.
Post Edited (Paul Baker) : 6/19/2006 6:59:16 PM GMT
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life is one giant teacup ride.
I think we are just as well keeping the 2KB handy for whatever, implementing crafty code that works only takes the slightest of space and speed hits (maybe a handful of hub rotations more?). 2KB is alot when you are trying to fit that last object in.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?
I've killed a fly with my bare mind.
Thanks much for your consideration! But I agree with Paul. Having more than one interpreter would be asking for trouble, and I have yet to see any issues with the current one that would justify the added confusion or a 2K penalty. The question I brought up is one of convenient notation only and is easily worked around. As to additions, like a post-not operator, the interpreter seems robust and universal enough that these could be accommodated by changes to the compiler only (i.e. push the variable's value on the stack, then not the variable). Right?
-Phil
You're going to eventually have to deal with having several versions of the Propellor Spin interpreter, just like you have several versions of the Stamp interpreter. It would be nice to have some things dealt with seamlessly in the Spin IDE rather than having to have lots of conditional compilation statements like for Baud constants and other timing dependencies with the Stamp series.
Memory is likely to be tight in situations where the use of new operators or other changes to the interpreter might be helpful. For now, allowing a RAM-resident Spin interpreter to be optionally used via an "old" Spin preamble would be useful, particularly in the development of any subsequent Propellor versions. I suspect it will be more common for a cog to go unused than 2KB of hub memory space. Maybe one cog could just sit there with a "new" Spin interpreter loaded and copy itself through one or two longs in hub memory to another cog using a short assembly program in that cog. It would take longer than loading directly from hub memory, but that additional overhead might be better tolerated most of the time than giving up 2KB of hub memory.