View Single Post
Old 31 May 2019, 18:03   #1

phx's Avatar
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,538
V34 Bugs in IEEEDPFieee and RawDoFmt

There is no note about it in the BUGS section of the V40 mathieeedoubtrans.doc and I don't remember that I heard about it before, but can anybody confirm that IEEEDPFieee from Kickstart 1.x is bugged?

I did the following short test program to convert an IEEE single precision number into double precision:
        move.l  4.w,a6
        lea     mathdbtransname(pc),a1
        moveq   #0,d0
        jsr     -552(a6)                ; OpenLibrary
        tst.l   d0
        beq     exit

        ; convert single precision 0.267261 to double precision
        move.l  d0,a6
        move.l  #$3e88d677,d0
        jsr     -108(a6)                ; IEEEDPFieee
        movem.l d0-d1,-(sp)             ; save double precision conversion

        move.l  a6,a1
        move.l  4.w,a6
        jsr     -414(a6)                ; CloseLibrary mieeedoubtrans

        lea     dosname(pc),a1
        moveq   #0,d0
        jsr     -552(a6)
        move.l  d0,-(sp)                ; save DOSBase
        move.l  d0,a6
        jsr     -60(a6)                 ; Output
        move.l  d0,-(sp)                ; save stdout

        ; print double precision result in hex
        move.l  4.w,a6
        lea     fmtstr(pc),a0
        lea     8(sp),a1                ; double precision value on stack
        lea     write(pc),a2
        move.l  sp,a3
        jsr     -522(a6)                ; RawDoFmt and Write to stdout

        movem.l (sp)+,d0/a1
        jsr     -414(a6)                ; CloseLibrary dos
        addq.l  #8,sp
        moveq   #0,d0

        movem.l d0/a6,-(sp)
        movem.l (a3),d1/a6
        move.b  d0,(sp)
        move.l  sp,d2
        moveq   #1,d3
        jsr     -48(a6)                 ; Write next character to stdout
        movem.l (sp)+,d0/a6

        dc.b    "mathieeedoubtrans.library",0
        dc.b    "dos.library",0
        dc.b    "%lx%lx",10,0
The result printed on Workbench 3.1 is

which is correct (0.267261). Workbench 1.3, on the other hand, prints:
3FD1DDFF D0000000

This is 0.279175 and a considerable difference. Is that a known bug? Perhaps Kickstart 1.x mathieeedoubtrans was not much tested or used with IEEE single precision, as it also had no mathieeesingbas/trans libraries? Or does it even expect FFP instead of IEEESP?

Bonus bug:
I was suprised that 1.3 first prints 3FD1DDFF with a blank, then waits for 30 seconds(!), prints D0000000 and waits for another 30 seconds! I didn't remember that RawDoFmt() was also that bugged...
phx is online now  
Page generated in 0.04230 seconds with 11 queries