QL Tinkering

Helpful tips and guides, also new users can ask for help here.
Post Reply
RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: QL Tinkering

Post by RWAP »

qbits wrote:
Welcome any reviews on Game and checks on my code where I might have screwed up, not having every platform to test the program on. It should Load and work on most although an original QL will need expanded memory. The QL2k emulator has a clock multiplier assuming x1 is equivalent to original QL hardware speed, the Game will run very slow as expected. At x10 its bearable-ish, x50 that might be acceptable, x500 I have no problems. My best judgement of the QPC2 and SMSQ emulators they are probably running at x1000.

QBITS
Great to see some progress being made on the game. As for speed, this can of course, be overcome by cmopiling the game with Turbo.

However, it would be useful to identify which parts of hte program are slowing the game down. There are some tricks in SuperBASIC which can then help:

a) Integer FOR loops are quicker (although they only work on Minerva and SMSQ/e)
b) Can you use integer variables elsewhere?
c) Some of the FOR loops include INK commands even though the INK colour does not change within the loop. Watch out for extraneous commands such as this, where they can be moved to the outside of the loop.
d) SELECT ON and IF statements can also be speeded up if you ensure that the most likely outcome appears near the start.
e) Move the less used procedures and functions towards the end of the program (as the interpreter always has to search through the listing for the required function / procedure - I cannot recall whether the interpreter retains a lookup table to the location of procedures and functions - it has been some years since I read (and re-read) Jan Jones' book).
f) Move the DATA statements to the very end of the program.
g) Commands such as :

Code: Select all

IF astro(n,7)>0 AND astro(n,5)<3:astro(n,5)=3
are actually slightly quicker if written

Code: Select all

IF astro(n,7)>0: IF astro(n,5)<3:astro(n,5)=3
If using nested IF statements, also consider which one is least likely to be true, so that the line is negated as soon as possible.
I always intended to write a section on writing SuperBASIC programs for speed for the SBASIC/SuperBASIC Reference Manual, but never managed to get around to it.


User avatar
vanpeebles
Commissario Pebbli
Posts: 2815
Joined: Sat Nov 20, 2010 7:13 pm
Location: North East UK

Re: QL Tinkering

Post by vanpeebles »

qbits wrote:Hi, its been a busy spring my eldest buying their own home. So there’s been a bit of ongoing DIY. Then summer blistering and a trip to India, 31 degrees at Heathrow on the day we left, 40 plus in Delhi phew! Our journey took us up into the Himalayans a more balmy 25 with a stiff breeze was much better.
QBITS
Welcome back! :)


User avatar
Cristian
Aurora
Posts: 960
Joined: Mon Feb 16, 2015 1:40 pm
Location: Veneto

Re: QL Tinkering

Post by Cristian »

RWAP wrote: There are some tricks in SuperBASIC which can then help:
Clever tricks! I didn't know them. Very useful for me also, thanks!


qbits
Trump Card
Posts: 171
Joined: Sun Dec 11, 2016 3:32 pm

Re: QL Tinkering

Post by qbits »

Hi,

Thanks RWAP that’s certainly given me food for thought!
I’ll take your advice and tricks in SuperBASIC and try them out.

Hi again to you vanpeebles & Cristian

QBITS


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: QL Tinkering

Post by pjw »

RWAP wrote:There are some tricks in SuperBASIC which can then help:
Just a few minor updates to these excellent tips:
a) Integer FOR loops are quicker (although they only work on Minerva and SMSQ/e)
Both Turbo and Q-Liberator can also be made to use integer loop variables (see their respective manuals). The resulting code
should then work on all ROMs (and SMSQ/E etc)
b) Can you use integer variables elsewhere?
c) Some of the FOR loops include INK commands even though the INK colour does not change within the loop. Watch out for extraneous commands such as this, where they can be moved to the outside of the loop.
d) SELECT ON and IF statements can also be speeded up if you ensure that the most likely outcome appears near the start.
e) Move the less used procedures and functions towards the end of the program (as the interpreter always has to search through the listing for the required function / procedure - I cannot recall whether the interpreter retains a lookup table to the location of procedures and functions - it has been some years since I read (and re-read) Jan Jones' book).
Point (e) does not apply to SBASIC.
f) Move the DATA statements to the very end of the program.
I dint know. Does anybody know why this is?


Per
dont be happy. worry
- ?
RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: QL Tinkering

Post by RWAP »

pjw wrote:
RWAP wrote:There are some tricks in SuperBASIC which can then help:
Just a few minor updates to these excellent tips:
a) Integer FOR loops are quicker (although they only work on Minerva and SMSQ/e)
Both Turbo and Q-Liberator can also be made to use integer loop variables (see their respective manuals). The resulting code
should then work on all ROMs (and SMSQ/E etc)
Of course - although both Turbo and Q-Liberator would speed up the program anyway - it is about squeezing out the best speed from the SuperBASIC initially.

pjw wrote:
RWAP wrote:e) Move the less used procedures and functions towards the end of the program (as the interpreter always has to search through the listing for the required function / procedure - I cannot recall whether the interpreter retains a lookup table to the location of procedures and functions - it has been some years since I read (and re-read) Jan Jones' book).
Point (e) does not apply to SBASIC.
I think it applies to SuperBASIC though (SBASIC is used by SMSQ/e) - can anyone clarify - I am sure it is covered in the Jan Jones book somewhere?
pjw wrote:
RWAP wrote:f) Move the DATA statements to the very end of the program.
I dint know. Does anybody know why this is?
I believe that this is the way that the SuperBASIC parser works - it has to jump over the DATA statements and check if any of them need to be computed during each pass - if they are at the end of the program, then the parser will not need to check them whilst the program is running (only at the start when the READ statements are executed). Again I think it is in Jan Jones' book. Turbo also used to insist on the data statements being at the end.


User avatar
Andrew
Aurora
Posts: 786
Joined: Tue Jul 17, 2018 9:10 pm

Re: QL Tinkering

Post by Andrew »

QL SuperBASIC The Definitive Handbook - Jan Jones
page 66:
"DATA statements themselves do not have any effect on normal execution. They may be put anywhere. It is most efficient, however, to put them at the very beginning of a program. This is because moving to a data item always starts from the first line of a program so, if all the DATA statements are up there, it takes less time to find them."


RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: QL Tinkering

Post by RWAP »

Andrew wrote:QL SuperBASIC The Definitive Handbook - Jan Jones
page 66:
"DATA statements themselves do not have any effect on normal execution. They may be put anywhere. It is most efficient, however, to put them at the very beginning of a program. This is because moving to a data item always starts from the first line of a program so, if all the DATA statements are up there, it takes less time to find them."
Thanks Andrew - I had it the wrong way around then...


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: QL Tinkering

Post by tofro »

Bah. And I was typing up a long answer quoting the exact same sentence of the book. :D

Thanks Andrew!


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: QL Tinkering

Post by pjw »

RWAP wrote:
pjw wrote:<>
Both Turbo and Q-Liberator can also be made to use integer loop variables (see their respective manuals). The resulting code should then work on all ROMs (and SMSQ/E etc)
RWAP wrote:Of course - although both Turbo and Q-Liberator would speed up the program anyway - it is about squeezing out the best speed from the SuperBASIC initially.
Sure, I just wanted to add this bit of information while we were at it ;)
pjw wrote: Point (e) does not apply to SBASIC.
I think it applies to SuperBASIC though (SBASIC is used by SMSQ/e) - can anyone clarify - I am sure it is covered in the Jan Jones book somewhere?
Youre right about SuperBASIC, but this question was asked (in June 2018) in ql-users:
On 20 June 2018 at 22:35, Dave Park via Ql-Users <ql-users@lists.q-v-d.com> wrote:
<>
Separately, does the sBASIC in SMSQ or Minerva still scan for
procedures/functions from the beginning of the program, so earlier FN/PROCs
have a speed advantage over later ones like in JM/JS?
I did the research and replied:
The SBASIC compiler performs a number of additional passes to SuperBASIC's parser, to end up with a much purer "executable". The compiled program is not machine code, of course, it consists of fixed length tokens that still need to be "interpreted". But all useless baggage has been eliminated from the program flow, expressions teased into simple RPN steps, and locations resolved to absolute addresses. So no, the size of the program or distance to procedures does not effect the speed of execution.


Per
dont be happy. worry
- ?
Post Reply