The Sinclair QL Forum

Hi everyone!

I've just been making some tweaks to a Y-Modem like file-transfer prog that I developed some time ago and use regularly to move files between my laptop running QPC and my QL.

One little niggle that I had never resolved was a simple 'progress' indicator that, when the prog runs in either SBasic on QPC or Minerva SuperBasic produces the expected results, but whenever TURBO'd, always returns 0% until finally it switches to 100% - again on both platforms.

Here's the basic line:

progress=INT( (expBlk% / totBlks%) * 100)

I'm guessing some clever INTeger optimisation in TURBO that is producing an int result for division in the inner parenthesis (expBlk% / totBlks%) - which clearly would result in 0 until the two int variables match, when it becomes 1.

I can easily recode using FP vars instead of INTs to avoid this, but wondered if this is expected behaviour in TURBO'd programs?

Whilst still interested in whether this is an expected TURBO thing, I got around this trivial problem without resorting to nasty FPs, but simply with:

progress = INT( (expBlk% * 100) / totBlks% )

I then decided I didn't need 'progress' as an FP at all and simply recoded the whole thing as an INT:

progress% = (expBlk% * 100) / totBlks%

I must remember to watch out for such TURBO INTeger optimisations in the future...

Most probably, Turbo reverts to integer division when divididng two integer types (sounds logical, doesn't it?), while SBASIC does what it always does when calculating expressions: It uses a floating point result.

Tobias

Thinking about it, the normal divide / should probably be excluded from the optimisation - after all, if you wanted integer divide, you would simply use the DIV operator.

As it is, I have to watch-out that expBlk% never exceeds 327 using the workaround.

No biggie - I'll always love TURBO - thanks SNG and GG

Hi,
Try this:

100 PRINT MODULO(999999,987654)
110 :
120 DEFine FuNction MODULO(ms,md)
130 RETurn ms-(INT(ms/md)*md)
140 END DEFine
:

This seems to be OK for huge 6-didgit numbers, which I wrote recently.
Please feel free to use it.
If you should find any bugs, please let us all know...

Regards,
Steve.

stevepoole wrote:<>

Code: Select all

100 PRINT MODULO(999999,987654)
110 :
120 DEFine FuNction MODULO(ms,md)
130 RETurn ms-(INT(ms/md)*md)
140 END DEFine

<>

I was going to suggest the following MODification which is slightly faster (But DIV only works on long ints in SBASIC, IIRC):
But on checking whether the two functions returned identical results, I came across the following anomaly:

999969 DIV 31 = 32257, as expected, but from then on we get
999970 DIV 30 = -32204 !?! - should be 33332
999971 DIV 29 = -31055 - should be 34481
etc

Surely this is a bug?

Hi Per,
I can vouch for the bug on QPC2 too... I get the same bad results as you using DIV .
Who has the code for the DIV function ? It definitely needs debugging.
The problem is that SMSQ integers range from -32768 to 32767 !
The MODULO (or should it be MODULUS?) code uses bigger 'integers'. This is why I wrote it in the first place.
Regards,
Steve.

We all have the source code, Steve. Its available here: http://www.wlenerz.com/smsqe/

Its obvious whats going on: DIV accepts long word parameters, but only returns a signed (short) word result, same as an SBASIC integer%. I guess I was just shocked because it doesnt seem like an obvious implementation choice to me. As every other ql-er, I wrote my own LDIV and LMOD functions in assembler and mine return a long word result (converted to FP on return to BASIC, of course)

pjw wrote: Its obvious whats going on: DIV accepts long word parameters, but only returns a signed (short) word result, same as an SBASIC integer%.

That is maybe not the whole of the problem - for some arguments (like $80000 DIV 2) we get correct (long integer) results.

Tobias

tofro wrote:That is maybe not the whole of the problem - for some arguments (like $80000 DIV 2) we get correct (long integer) results.

Hence the disclaimer under my signature I guess the next step will be to actually peek at the source code to see whats going on..