Have I found a bug in QPC2?

Discussion and advice about emulating the QL on other machines.
User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Have I found a bug in QPC2?

Post by NormanDunbar »

I've been trying to write up an article for the somewhat irregular Assmebly magazine, and I think I might have a bug in QPC2, either than, or I'm bonkers again! I've narrowed it down to the following code in which I've hard coded values rather than have to go through lots of setup etc to get the values I needed.

The code is supposed to work out a MODulus operation to wrap a word offset from $7FFF to $0000 when incremented. I know that if I extend to long before adding 1, I get the correct answer, that's not the problem.

Code: Select all

start    
           clr.l d0             ; For return to SuperBASIC
           move.w #$7FFF,d1     ; D1 = $xxxx 7FFF
           addq.w #1,d1         ; D1 = $xxxx 8000
           move.w d1,d2         ; D2 = $xxxx 8000
           ext.l d1             ; D1 = $FFFF 8000 
           divu d2,d1           ; D1 = $FFFF 8000 WTH? Should be $0001 FFFF
           swap d1              ; D1 = $8000 FFFF !!!!!!
           rts
So, the bug. If I divide $FFFF 8000 by $8000 on my various calculators, I get $0001 FFFF, if I do the above code and single step in QMON2 (not the Marcel special version) I get the DIVU result of $FFFF 8000 which is wrong, isn't it? Please tell me it's wrong! ;)

It works perfectly this way round, extending first before incrementing and the DIVU gives the correct result. This is the problem I'm demonstrating, but the result kept coming back wrong, so I had to find a small example that shows the fault.

Code: Select all

start    
           clr.l d0             ; For return to SuperBASIC
           move.w #$7FFF,d1     ; D1 = $xxxx 7FFF
           ext.l d1             ; D1 = $0000 7FFF
           addq.l #1,d1         ; D1 = $0000 8000
           move.w d1,d2         ; D2 = $xxxx 8000
           divu d2,d1           ; D1 = $0000 0001
           swap d1              ; D1 = $0001 0000
           rts

If it helps any, the code is assembled with George Gwilt's GWASS assembler. Speaking of which, has anyone seen or heard anything from George? I haven't heard a thing for ages.

Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Have I found a bug in QPC2?

Post by mk79 »

What we have here is what we computer professionals call an "overflow" :twisted: Divu is 32bit -> 16x16 bit. $1FFFF does not fit in 16-bit. The CPU manual in this case says
Overflow may be detected and set before the instruction completes. If the instruction detects an overflow, it sets the overflow condition code, and the operands are unaffected.
So the answer to "Have I found a bug in QPC2" is "Of course not!" :lol:


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

Re: Have I found a bug in QPC2?

Post by tofro »

Hi Norman,

I could do you the favour in saying it's wrong. At least once.

And then tell you I lied, because it isn't. (Well: The result is wrong, but that's not QPC's fault - There simply is no result)

You need to always look at the flags (especially the V flag) after a division (it's set in your example). What happens is that a division overflow occured (the quotient doesn't fit into a 16-bit word), thus
68k Programmer's Manual wrote:Overflow may be detected and set before the instruction completes. If the instruction detects an overflow, it sets the overflow condition code and the operands are unaffected.
So, your DIVU didn't do anything, that's why the d1 is unchanged.

On QPC supporting the 68020 long division, you could simply do a

Code: Select all

divu.l d2,d1
and get the proper result (without the remainder, of course).

And no, I haven't heard anything from George, not for several years now.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Have I found a bug in QPC2?

Post by tofro »

Marcel beat me to it.


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Have I found a bug in QPC2?

Post by NormanDunbar »

mk79 wrote:So the answer to "Have I found a bug in QPC2" is "Of course not!" :lol:
I knew it would be my fault! Thankfully, it was.

I looked at $1FFFF and knew something was wrong with it, but couldn't put my finger on it. And of course, it has 5 digits so overflow.

Thanks to you both for reminding me to look harder next time!

Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
Pr0f
QL Wafer Drive
Posts: 1298
Joined: Thu Oct 12, 2017 9:54 am

Re: Have I found a bug in QPC2?

Post by Pr0f »

I wonder if it's worth including this in your article when you publish it? - as it's a good illustration for those of us that are prone to making mistakes like this (I am including myself in that).


User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Have I found a bug in QPC2?

Post by NormanDunbar »

Mind reader!

I've already written it up. Might as well embarrass myself even more. After all, we learn from mistakes. And we all make mistakes. (Said the hedgehog climbing off the toilet brush!) :D

Cheers,
Norm.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
qbits
Trump Card
Posts: 171
Joined: Sun Dec 11, 2016 3:32 pm

Re: Have I found a bug in QPC2?

Post by qbits »

Hi Norman
I Have been working on program using COLOUR_24 and made a note on a similar problem.
Hex(‘FFFFFF’) returns 1.677722E7 whereas HEX$(1.677722E7,24) return 000004 not FFFFFF as expected.
This is probably to do with the way floating point numbers are processed.
So I set the upper limit for each of my RED GREE BLUE Colours to $FE and resolved the problem.
But I'd like to know more?

QBITS


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

Re: Have I found a bug in QPC2?

Post by pjw »

Well, you have

Code: Select all

x = HEX('FFFFFF'): PRINT x
which prints 1.677722E7, but

Code: Select all

PRINT HEX$(x, 24)
prints FFFFFF, as expected. However FFFFFF is also just 16777215, so

Code: Select all

PRINT HEX$('16777215',24)
also prints FFFFFF. Its all about using the right tools for the job!


Per
dont be happy. worry
- ?
User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Have I found a bug in QPC2?

Post by mk79 »

Floating point values are rounded on PRINT, so you don't get the real value if you just type in what you see. Apart from that why don't you just do "red*65536+green*256+blue", all components 0..255.


Post Reply