🚀 go-pugleaf

Hi all!.

I'm porting gcc-2.6.0 to an Arix A1000 (which Unisys used to rebadge as
their 5000 series). This is an 68020/68881 SVR3.2 box.

I need help changing the machine description, m68k.md to accomodate a
bug in the native assembler (and kernel or CPU board!).

The problem I am seeing is in two (so far) of the floating point
instructions. The test code is:

        main() {
            long double ld = 10.0, ld2;
            int i;
            i = ld == 10 ? 1 : 0;
            ld2 = 1.0/ld;
        }

The first problem I came across was in the fcmp instruction (see *1*).
The assembly code produced was (./xgcc -B./ -dp -s tst.c):

        #NO_APP
            file    "tst.c"
        gcc2_compiled%:
        text
            even
        LC%0:
            long 0x40240000,0x0
            even
        LC%1:
            long 0x3ff00000,0x0
            even
        global main
        main:
            link %a6,&-20
            jsr __main ;# 6 call+1
            mov.l &1076101120,-8(%a6) ;# 9 movdf/4
            clr.l -4(%a6)
            fmov.d -8(%a6),%fp0 ;# 27 movdf/2
            fcmp.d %fp0,LC%0 ;# 12 cmpdf_fpa+1/1      *1*
            fseq %d0 ;# 13 seq
            mov.b %d0,%d1 ;# 29 movqi/1
            extb.l %d1 ;# 14 extendqisi2
            mov.l %d1,-20(%a6) ;# 32 movsi+1/1
            mov.l -20(%a6),%d0 ;# 35 movsi+1/1
            neg.l %d0 ;# 15 negsi2
            mov.l %d0,-20(%a6) ;# 17 movsi+1/1
            fmov.d LC%1,%fp0 ;# 37 movdf/2            *2*
            fdiv.d -8(%a6),%fp0 ;# 19 divsf3-1
            fmov.d %fp0,-16(%a6) ;# 39 movdf/1
        L%1:
            unlk %a6
            rts

If the address LC%0 is less than 0x10000 (ie. the address fits in 16 bits)
the assembler produces code with a word address eg.:

            fcmp.d   %fp,0x600.w

The bug comes up when the address LC%0 is less than 0x10000 but greater than
0x7fff (ie. high-bit set). The assembler still produces the word address,
but the processor sign-extends this address to 32 bits, as it says it will do
in the MC68020 manual. ie. address 0xa000 becomes 0xffffa000.

Uh-Oh! Bus error, core dumped etc.

Even worse, due to (I guess) a problem in the kernel or the CPU board, we
get a kernel panic and the whole machine goes down in a screaming heap.
(This thing feels like MS-Windows!)

Ok, so after a great deal of reading the texi documents (I'm not a compiler
person), the solution I came up with was:

   In the m68k.md machine description, the instruction pattern after
   (define_insn "cmpdf_fpa" ...) is:

      (define_insn ""
        [(set (cc0)
          (compare (match_operand:DF 0 "general_operand" "f,mG")
               match_operand:DF 1 "general_operand" "fmG,f")))]
      ...

   I changed the constraints to "f,iG" and "fiG,f". This had the desired
   effect of having the compiler produce assembly code with an immediate
   operand (see *1*):

        #NO_APP
            file    "tst.c"
        gcc2_compiled%:
        text
            even
        LC%0:
            long 0x3ff00000,0x0
            even
        global main
        main:
            link %a6,&-20
            jsr __main ;# 6 call+1
            mov.l &1076101120,-8(%a6) ;# 9 movdf/4
            clr.l -4(%a6)
            fmov.d -8(%a6),%fp0 ;# 27 movdf/2
            fcmp.d %fp0,&0x4024000000000000 ;# 12 cmpdf_fpa+1/1    *1*
            fseq %d0 ;# 13 seq
            mov.b %d0,%d1 ;# 29 movqi/1
            extb.l %d1 ;# 14 extendqisi2
            mov.l %d1,-20(%a6) ;# 32 movsi+1/1
            mov.l -20(%a6),%d0 ;# 35 movsi+1/1
            neg.l %d0 ;# 15 negsi2
            mov.l %d0,-20(%a6) ;# 17 movsi+1/1
            fmov.d LC%0,%fp0 ;# 37 movdf/2                         *2*
            fdiv.d -8(%a6),%fp0 ;# 19 divsf3-1
            fmov.d %fp0,-16(%a6) ;# 39 movdf/1
        L%1:
            unlk %a6
            rts

I'm don't even know why this worked - it was the first thing I tried, and
subsequent reading made me think that it shouldn't have. We don't have any
integer immediate operands as indicated by 'i', and changing to "f,G" and
"fG,f" which I tried later didn't work.

Oh well, so far so good... But.

The next instruction that showed this sign-extension problem was the fmov
(see *2*). This pattern for this in the machine description is:

   (define_insn "movdf"
     [(set (match_operand:DF 0 "general_operand"
                                        "=rm,rf,rf,&rof<>,y,rm,x,!x,!rm")
       (match_operand:DF 1 "general_operand" "rf,m,0,rofE<>,rmE,y,xH,rm,x"))]

I've tried lots of screwing round with the constraints to try to force
the operand to be immediate, with no success.

Can someone who knows how this all really works please suggest something?

Thanks!

----------------------------------------------------------------------------
Li-Chuan Dunlop     <no fancy .sig>