SPIN IF/ELSE block limit?
KDBrown
Posts: 13
I came upon a surprise yesterday, and that was an error message saying that I had exceeded a block limit of 8. I did not grab a snapshot of the message and I should have, but I was able to refactor the code to make this go away pretty quickly so it was not a big problem. But the question is this: is there any reference material about this? I read over the Prop Manual Pages 112...117 and found no mention of this limit
Comments
Thanks,
Marcus
I'm not sure I subscribe to that view, after all you may want to be traversing a 10 dimensional array or other data structure.
But if you do, the the error on exceeding a nesting of 8 is perhaps a good thing not just an arbitrary compiler limitation.
But what about the 256 limit on branches in a case statement?
(Actually, now that I think about it it might be less than that. Like 64 or something. I hit the limit when switching on opcodes in my first 8080 simulator so 256 would have been enough. Anyone know the limit here?)
Perhaps such a huge case statement is also a sign of bad design. But then there is no way of easily dispatching on a range of values in Spin. Like say a table full of function addresses than can be indexed and jumped to as in C.
Now, does it make sense to have cases bigger than that? Is it good style?
Didn't mean to go off topic but you guy's are talking about it.
Yes, as I said above my first experiments into an 8080 emulation on the Prop were done in Spin. My first ever Prop program. Horrible slow but at least I wanted to see if I had the logic correct and could run some 8080 code. That is when I hit the limit.
I have no idea how case gets compiled in Spin. The fact that it allows complicated ranges in each case suggests that it is compiled to a bunch of "if" statements basically.
I always thought that the case statement (switch) in language like C was a way to do a fast look up on integer values to determine what code to execute next. So a switch involving cases 0,1, 2, 3 etc should not compile to a bunch of tests but rather a single lookup and jump. Very fast.
Anyway, case (switch) is just something high level language designers had to dream up to get stuff done efficiently after Edsger Dijkstra pronounced "goto considered harmful"
Exceptions are yet another work around to that ban on goto.
-Phil
If your case is testing a bunch of numbers then one can see how that could be made into nested cases and a binary search tree is the limit of that idea. This works because numbers have an order.
Now, if your cases are numbered sequentially then that can be reduced to a table look up. A constant time operation. Much better than serially testing each case or the nLog(n) time of a binary search.
It's not clear to me how you would make a binary tree out of the general case of the "case" statement where the values switched on are not numbers but expressions. Like this from the Prop manual:
case X+Y 'Test X+Y 10 : !outa[0] 'X = 10? Toggle P0 A*2 : !outa[1] 'X = A*2? Toggle P1 30..40: !outa[2] 'X in 30 to 40? Toggle P2By the way, I notice the manual has errors here. The code comments indicate we are testing X where as we are actually testing X+Y.