Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Building current



> Looking at gas/confg/tc-vax.c:vip surely makes my eyes bleed.

I looked at it from the other direction, trying to see why gcc
generated $-1 for ashq and $0xffffffffffffffff for movq.

I find PRINT_OPERAND in gnu/dist/gcc/config/vax/vax.h (this is on
1.4T), which is commented (note the second comment in particular)

/* Print an instruction operand X on file FILE.
   CODE is the code from the %-spec that requested printing this operand;
   if `%z3' was used to print operand 3, then CODE is 'z'.

VAX operand formatting codes:

 letter    print
   C    reverse branch condition
   D    64-bit immediate operand
   B    the low 8 bits of the complement of a constant operand
   H    the low 16 bits of the complement of a constant operand
   M    a mask for the N highest bits of a word
   N    the complement of a constant integer operand
   P    constant operand plus 1
   R    32 - constant operand
   b    the low 8 bits of a negated constant operand
   h    the low 16 bits of a negated constant operand
   #    'd' or 'g' depending on whether dfloat or gfloat is used  */

/* The purpose of D is to get around a quirk or bug in vax assembler
   whereby -1 in a 64-bit immediate operand means 0x00000000ffffffff,
   which is not a 64-bit minus one.  */

And, using -dp, I get

        movq $0xffffffffffffffff,-8(fp) ;# 8 movdi/2

and

        ashq 4(ap),$-1,r2 ;# 7 ashldi3

and, on inspecting vax.md, the pattern for movdi says "movq %D1,%0"
whereas that for ashldi3 says "ashq %2,%1,%0" with no D.

Using various other values, I find that using 64-bit values whose high
33 bits are 0xffffffff80000000 produces similar related trouble; for
example, using 0xffffffffffff1234ULL ends up with 00000000ffff1234 in
the immediate-mode operand for the ashq.

Here's the ashldi3 pattern that generates the ashq, near as I can tell:

(define_insn "ashldi3"
  [(set (match_operand:DI 0 "general_operand" "=g")
        (ashift:DI (match_operand:DI 1 "general_operand" "g")
                   (match_operand:QI 2 "general_operand" "g")))]
  ""
  "ashq %2,%1,%0")

I speculate that it could fix this to just s/%1/%D1/ here.  I'm going
to start a test build in my simulator with this change, but it will
take some three or four days to complete even if everything works fine,
so if someone else can try this - or rather the analogous change to
whichever version is in use - on something faster, that might be good.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index