Question about ~

Phil Pilgrim (PhiPi)

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:

  [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

Mike Green

The post-clear operator does not check the current value of the variable. It just sets it to zero. You're correct about the possibility of a "race condition". A better way to do this is using a request counter where the requestor increments a counter and the server tests the count for non-zero and, if true, performs the service then decrements the count. The increment and decrement operators are indivisible. As long as requestors are the only ones that increment the counter and servers are the only ones that decrement the counter, you won't miss a request.

cgracey

Phil,

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.

Paul Baker

Would it be possible to have a flag tucked in somewhere near the beginning of the program stream to say whether to use the hardcoded interpretor or an interpretor included in the program stream?

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

cgracey

It would just amount to short preample which would kick things off with the new interpreter, instead. Spin code written for the new interpreter would have to be run on that interpreter, of course, so at compile time everything would have to be firmed up, already.

Paul Baker said...
Would it be possible to have a flag tucked in somewhere near the beginning of the program stream to say whether to use the hardcoded interpretor or an interpretor included in the program stream?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Paul Baker

Ok, I see how providing a compiler for a host of possible interpretors would quickly get out of hand.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life is one giant teacup ride.

CJ

Chip,

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.

Phil Pilgrim (PhiPi)

Chip,

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

Mike Green

Chip,
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.