Author Topic: Will QB64 produce jump tables from SELECT CASE  (Read 160 times)

This topic contains a post which is marked as Best Answer. Press here if you would like to see it.

Offline romichess

  • Forum Regular
  • Posts: 141
Will QB64 produce jump tables from SELECT CASE
« on: March 25, 2020, 09:22:10 PM »
What if the code is written like so:
SELECT CASE
    CASE 0
        sub0 par1
    CASE 1
        sub1 par1
    CASE 2
        sub2 par1
    ...
END SELECT
 
Will the C++ compiler produce jump tables?
My name is Michael, but you can call me Mike :)

Offline FellippeHeitor

  • QB64 Developer
  • Forum Resident
  • Posts: 1889
  • LET IT = BE
    • QB64.org
Re: Will QB64 produce jump tables from SELECT CASE
« Reply #1 on: March 25, 2020, 10:10:16 PM »
You can check the c++ result by opening internal/temp/main.txt after the IDE gives you an OK in the status bar.

And no, the answer is no.

A select case block is a glorified (and very convenient) long IF block.

Offline romichess

  • Forum Regular
  • Posts: 141
Re: Will QB64 produce jump tables from SELECT CASE
« Reply #2 on: March 26, 2020, 12:24:19 AM »
You can check the c++ result by opening internal/temp/main.txt after the IDE gives you an OK in the status bar.

And no, the answer is no.

A select case block is a glorified (and very convenient) long IF block.

Thanks for the answer. That is very sad for performance. My chess program is going to run really slow. With a few performance enhancements QB64 could become a serious production language. That is a shame that it is not because I really like the Basic syntax.
My name is Michael, but you can call me Mike :)

Online TerryRitchie

  • Seasoned Forum Regular
  • Posts: 462
  • Semper Fidelis
Re: Will QB64 produce jump tables from SELECT CASE
« Reply #3 on: March 26, 2020, 12:43:00 AM »
It's BASIC. If constructs from other languages get thrown in then it's not BASIC any longer.
In order to understand recursion, one must first understand recursion.

Marked as best answer by romichess on March 26, 2020, 06:10:48 AM

Online SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 2361
    • Steve’s QB64 Archive Forum
Re: Will QB64 produce jump tables from SELECT CASE
« Reply #4 on: March 26, 2020, 01:23:07 AM »
You could write your code, look in main.txt in the temp folder, and then manually swap in a switch case block, if you really needed to, before recompiling.
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline romichess

  • Forum Regular
  • Posts: 141
Re: Will QB64 produce jump tables from SELECT CASE
« Reply #5 on: March 26, 2020, 03:15:48 AM »
It's BASIC. If constructs from other languages get thrown in then it's not BASIC any longer.

But but but a jump table can be created from a SELECT CASE construct without the basic coder even being aware. There would be absolutely no change to the basic language itself. Sorry if I was unclear about that.
My name is Michael, but you can call me Mike :)

Online TerryRitchie

  • Seasoned Forum Regular
  • Posts: 462
  • Semper Fidelis
Re: Will QB64 produce jump tables from SELECT CASE
« Reply #6 on: March 26, 2020, 09:38:39 AM »
But but but a jump table can be created from a SELECT CASE construct without the basic coder even being aware. There would be absolutely no change to the basic language itself. Sorry if I was unclear about that.

Ah, I see, yes it was not clear to me.
In order to understand recursion, one must first understand recursion.

Offline Cobalt

  • Forum Resident
  • Posts: 520
  • At 60 I become highly radioactive!
Re: Will QB64 produce jump tables from SELECT CASE
« Reply #7 on: March 26, 2020, 11:24:33 AM »
If Speed was a really big deal, you can like Steve Says, go into the Main.txt and edit the C++ code directly and remove some of the over head. There are a lot of IF\THENs in there dedicated just to watching for EXIT stuff. All those extra lines take precious cycles to process. As long as you have no errors in the Computers decision tree you can add $CHECKING OFF to remove some of that over head and speed that code up a bit.

Don't forget that BASIC isn't exactly a speed language, and CHESS is a very logic based game. So there will have to be compromises made. Just think in terms of 1980s era home computers. Chess was a very slow game back then.

Give the Computer a time limit for its "Thought" process and have it choose the best move it was able to get to in that time. and you can have various difficulty setting based on that 'feature'! and the move process would be based on a recursive routine that assigns a score to each move and the recursion that scored the highest at the Time Limit would be used. Very similar to A+ path finding but instead of the lowest move-cost value your using the highest move-payoff value!.

Although I think you already know that... swear thats been touched on on another topic or over in on the Discord channel.

"The worlds dumbest chess computers will play the fastest game ever played, while the worlds greatest chess computers would play the slowest game ever played!" or something like that.
Granted after becoming radioactive I only have a half-life!

Offline EricE

  • Newbie
  • Posts: 88
Re: Will QB64 produce jump tables from SELECT CASE
« Reply #8 on: March 26, 2020, 11:58:54 AM »
If the cases are a sequence of numbers, 0, 1, 2, ...., n, then for the application in question, how large would n be?
Would each case have it's own sub, or would some cases share the same sub?
I am thinking of some sort of binary search could be implemented, rather than linearly starting at 0 and testing for a match with each possible integer up to n.
« Last Edit: March 26, 2020, 12:02:22 PM by EricE »

Offline romichess

  • Forum Regular
  • Posts: 141
Re: Will QB64 produce jump tables from SELECT CASE
« Reply #9 on: March 27, 2020, 02:58:35 AM »
If the cases are a sequence of numbers, 0, 1, 2, ...., n, then for the application in question, how large would n be?
Would each case have it's own sub, or would some cases share the same sub?
I am thinking of some sort of binary search could be implemented, rather than linearly starting at 0 and testing for a match with each possible integer up to n.
Steve clued me in on the right alternative in another thread, ON GOTO/GOSUB.
My name is Michael, but you can call me Mike :)