Have I found a bug in QPC2?

[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.

[mk79]

What we have here is what we computer professionals call an "overflow" 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!"

[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

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.

[tofro]

Marcel beat me to it.

[NormanDunbar]

So the answer to "Have I found a bug in QPC2" is "Of course not!"

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.

[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).

[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!)

Cheers,
Norm.

[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

[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!

[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.