How many elements in a CASE ?

[smp]

Hello again,

I spent the weekend working on my latest project, which involves the use of a large CASE statement. Things were going well as I was building up the CASE tests, up to a point when all of a sudden I got a syntax error in some simple code within the CASE statement that appeared to be fine. After some noodling around, I thought that maybe I had reached the limit on the number of tests that could be in a CASE statement. I then broke the CASE statement into two CASE statements, and that now passes the syntax checking.

In this project of mine, I will likely have 245-250 tests to do. I would much prefer to have them all in one CASE statement, if possible.

What is the maximum number of tests that are allowed in one CASE statement?

Thanks, in advance, for your patience and attention.

smp

[Didier Lachieze]

According to the User Guide p521:

Quote:The CASE command is limited to 127 branches.

[smp]

(02-22-2016 02:49 PM)Didier Lachieze Wrote:  According to the User Guide p521:

Quote:The CASE command is limited to 127 branches.

Hello Didier,

Thank you very much for this information.

I find the description of the CASE command on page 529 of my User Guide, but it does *not* have that particular line! I guess I have a different version of the User Guide. Too bad, as it is expensive to have a several hundred page document printed out at my local Kinko's.

Thanks again for your assistance.

smp

[cyrille de brébisson]

Hello,

Yep, as stated above, 127 branches max...

HOWEVER, you can have a DEFAULT, and in this default, you can have another CASE with another 127 branches!


Cyrille

[smp]

(02-23-2016 07:03 AM)cyrille de brébisson Wrote:  HOWEVER, you can have a DEFAULT, and in this default, you can have another CASE with another 127 branches!

Thanks very much for that suggestion, Cyrille. Much appreciated.

I thought of that, too, but I've been struggling a bit with getting the original CASE to go - until I remembered that the 127 tests *includes* the DEFAULT. DOH!

Oh, well, there's a lesson that I will not easily forget.

smp

[Tim Wessman]

Honestly, we never expected anyone to hit that limit. 126 cases seems like there might be a much better (simpler?) design. You sure you can't adjust and use a different form?

[smp]

(02-23-2016 09:14 PM)Tim Wessman Wrote:  Honestly, we never expected anyone to hit that limit. 126 cases seems like there might be a much better (simpler?) design. You sure you can't adjust and use a different form?

Well, I'm trying to build an 8080 emulator, and using a CASE statement is a straightforward way to figure out which instruction was just fetched from memory. I'm definitely not the best programmer in the world, but I think I can get this done. I'll post it here for people to comment on when I get it running.

smp

[cyrille de brébisson]

Hello,

Case will involve a lot of tests (all the tests needs to be tested one at a time)... and this can be quite slow for byte 255....

A better approach would be to check bit 7, 6, 5... in row. Note that you can use var(index) access on integers to extract a single bit!
This would 1: change your case(256) to a series of if/then/else and lead to a consistent 8 tests per instruction.

Or, you could have your evaluation code for instruction n be called Ins_n and then do an expr("Ins_"+n+"(parameters if needed)");
This would replace your 256 long case by a single line and would be much faster than the case. I am not sure if it would be faster than the 8 tests solution.

You can also use a list (l) that contains the code for each of the instructions and do eval(l(instruction)).

Cyrille

[smp]

(02-24-2016 07:53 AM)cyrille de brébisson Wrote:  Case will involve a lot of tests (all the tests needs to be tested one at a time)... and this can be quite slow for byte 255....

Hello Cyrille,

Thank you *very* much for your advice. I am not a strong programmer, having only dabbled a little with a variety of languages over my lifetime. I am also very new to programming on the Prime, so I am making slow progress, and I am asking my somewhat embarrassing questions as I go along. I will study your suggestions, and I will probably return with some more questions as I attempt to understand them.

Thanks very much, once again, for all your attention and advice.

smp

[debrouxl]

In C/C++, using a 256-case switch() statement, minus the default cases, was the way to go. However, in PPL, in order to keep execution time down, you'll have to use what Cyrille suggested.
Be sure to benchmark the solutions first

[cyrille de brébisson]

Hello,

C/C++ is typed, so when you do a switch/case, the compiler knows what the input type is, and the case are constant. This allows the compiler to generate a jump table...

in HPPL, the variables are not typed, and the case statements can be much broader... This forces a sequential scanning of the cases.

Here, the internal 'counter' is limited to 8 bits, and each case takes 2 items: the test part and the evaluate if ok part. Therefore the limit...

It was thought at the time that the 127 limit would not be a problem as a program that needed more was most likely not correctly implemented (for the structure of HPPL).

Cyrille

[smp]

(02-24-2016 07:53 AM)cyrille de brébisson Wrote:  Hello,

Case will involve a lot of tests (all the tests needs to be tested one at a time)... and this can be quite slow for byte 255....

A better approach would be to check bit 7, 6, 5... in row. Note that you can use var(index) access on integers to extract a single bit!
This would 1: change your case(256) to a series of if/then/else and lead to a consistent 8 tests per instruction.

Or, you could have your evaluation code for instruction n be called Ins_n and then do an expr("Ins_"+n+"(parameters if needed)");
This would replace your 256 long case by a single line and would be much faster than the case. I am not sure if it would be faster than the 8 tests solution.

You can also use a list (l) that contains the code for each of the instructions and do eval(l(instruction)).

Cyrille

Hello Cyrille,

I spent much of the day today converting my program over to use the second of your suggestions. Even though I have only about half of the 8080 instructions coded, and I've tested only a few for actually working correctly (rather than simply being syntactically correct), I can visually see that the program is running much faster.

I am so pleased to realize that I can code the 8080 simulator program as a relatively small mainline program and 256 tiny programs that each handle one instruction. The EVAL("INS_"+n) statement is working great for me, rather than multiple CASE statements.

Thank you so much for taking the time to assist me with this effort. I greatly appreciate your (and Tim's) attention and assistance.

smp