Case limit of 64 statements?

JBWolf · 2014-01-10 11:22

Hello,
I am making a large 'shuffle mode' list for running led's.
This is being approached by generating a random number and then using a 'case' statement.
Problem is, I just started on #65 and get error "Case limit of 64 statements exceeded".
Any way to increase the case limit ? I would like to have 75.
Thanks

Phil Pilgrim (PhiPi) · 2014-01-10 11:30

You could try nesting them. Use a 0/1 random number to pick the first case group, then another random number in each group to pick from the 37 or 38 in the group.

-Phil

JBWolf · 2014-01-10 11:51

thats what I'm working on doing now

wasnt sure if there was some way to increase the cases limit though, just a spin limitation then?

Duane Degn · 2014-01-10 11:52

This is what I'd do.

I think it's what Phil means by nesting.

case x
    1: 'do stuff
    .
    .
    .
    63: ' do different stuff
    other: ContinueCase(x)

PUB ContinueCase(x)

  case x
    64: ' do more stuff
    65: ' do other stuff

Yes, it's a limit in Spin.

It seems like the above technique is a relatively simple work around.

Dave Hein · 2014-01-10 11:57

JBWolf wrote: »

thats what I'm working on doing now
wasnt sure if there was some way to increase the cases limit though, just a spin limitation then?

I think it's a compiler limitation. You could clone a copy of OpenSpin and modify it to get around the limitation. Or you can kludge your Spin code to work around it, which would be easier to do.

JBWolf · 2014-01-10 15:04

what is kludge?

im just going to do as phil mentioned... which is exactly what you are giving an example of duane.
I can group them into general categories anyways.
was just hoping there would be some buffer i could increase for case.
you know, like : CON Case[75]

Dave Hein · 2014-01-10 15:17

JBWolf wrote: »

what is kludge?

Sorry, I should have said you can restructure your Spin code to work around the compiler limitation.

localroger · 2014-01-10 17:29

JBWolf wrote: »

what is kludge?

A kludge is a hack which is ugly, but works.

Dave Hein · 2014-01-10 18:42

There may be another reason to restructure a large number of cases other than the 64-case limit. If I understand correctly, each case is tested until a matching case is found. So there could be situations where 63 cases would be evaluated before the matching 64th one would be executed. This could result is poor performance if this happened often. It may be better to group the cases into small groups and then uses if statements to execute only the relevant case statement.

localroger · 2014-01-10 19:01

Yes, since the cases are tested linearly (as opposed to with a jump table, as most modern C compilers will go to heroic lengths to arrange) There is advantage to breaking the case statement up not into two sections, but into the square root of the number of sections. If you have 100 cases and you split it up into 2 groups of 50 your worst case search time is 100 comparisons. If you break it up into 10 groups of 10 your worst case search time is 10 + 10 = 20 comparisons.

Heater. · 2014-01-11 03:11

I wonder.

If you happened to have, say, 128 cases. Numbered nicely from 0 to 127. You could arrange make an "if" branch from the first bit of the case. Then "if" branches on the second bit. And so on. In 7 tests you have arrived at your case.

Kind of verbose, but must be quicker on average.

JBWolf · 2014-01-11 12:40

It sounds like it takes longer for the processor to compare case's rather than if's? did I interpret that correctly?
or did you mean something more like a single case statement with 4 possible results, with each of those 4 results calling a method which has another possible 20 cases each..... cutting down like that (that approach would reduce comparison count by 60).

I could actually redo the case structure with 'if' statements, but I think I like the idea of categorizing the many methods into types/genres and nesting cases

localroger · 2014-01-11 12:51

CASE is streamlined compared to multiple IF..THEN because the comparison value only has to be computed or loaded once, and stays on the stack until a match is found or the CASE statement ends. This (and code size) limits the attractiveness of going to higher and higher roots to further granularize the comparison.

For example, say you stayed with CASE but in my example of 100 you go to the third root in stead of square; you need 4 or 5 cases per block then, but your worst case time is 15 compares -- not much better than 20 with the square root, and with more code and setup cost for the third level.

Heater. · 2014-01-11 13:11

CASE is a weird animal. Logically we don't need it. In languages like C it's nice because the compiler can build a table of addresses of code to jump to and then indexing that table and jumping to the code happens very quickly.

In other languages it's not so clear. Perhaps each case is no longer a constant but an expression that needs to be evaluated. At that point a bunch of chained "if..elseif" is about the same performance wise.

Personally I would do whatever reads most nicely in the source code. Leave any performance tweaking until you know if you need it or not.

localroger · 2014-01-11 18:20

CASE is useful if you want to compare a single derived value to a multiple number of targets. WIth IF..THEN you have to re-derive the value for comparison every time. With CASE, it's on the stack. Even if you can't do the C compiler thing and build a jump table, it has computatonal advantages.

Case limit of 64 statements?

Comments