Problems porting GCC compiler to Gould

Rob McMahon cudcv at daisy.warwick.ac.uk
Tue Apr 19 08:49:36 AEST 1988


I don't know if this is the right group to send this to, if not maybe
someone could point me in the right direction ?  Sorry if this is such a
long article, if you know nothing about the guts of GCC, please skip it.

I'm in the process of porting GCC to a Gould under UTX 2.0.  In fact I
have this very nearly done, there are only 1 1/2 problems left, and I'm
not sure what the best solution is.  Is there anyone out there with any
experience here ?

The problem is the Gould has no variable-count shift instructions, or
unsigned compare.  The variable shift must be done by forging an
instruction in a register, and then 'executing' the register.  The UTX C
compiler does unsigned compare by zero-extending both operands to the
next biggest datatype and doing a (signed) compare on the result.

Both these operations need scratch registers to work in, and my problem
is how to get these.  Taking the shift as the easier example, I would
like to be able to do:

(define_insn ""
  [(set (match_operand:SI 0 "general_operand" "=d")
	(ashift:SI (match_operand:SI 1 "general_operand" "0")
		   (match_operand:SI 2 "general_operand" "n")))]
  "GET_CODE(operands[2]) == CONST_INT"
  "lslw %2,%0")

(define_insn "ashlsi3"
  [(set (...) (ashift:SI (...) (match_operand:SI 2 "general_operand" "r")))
   (clobber (match_dup 2))]
  ""
  "*return gould_output_shift(GLD_LSLW, operands, insn);")

in the hope that the compiler would move the count to a new register, if
it needed it again, where I could convert it into a shift instruction.

Well I can understand that clobber is done at the wrong stage for this
to be possible, and that it needs a hard register, so I'd put up with
(clobber (reg:SI 0)), and use reg_dead_p to see if I really needed to
work in register 0, or could work where the count already was.

It seems that having taken the named pattern, complete with clobber, it
will not choose the nameless pattern for constants, unless it has an
identical clobber.  This is not too bad for the shift instructions where
I only need one register, but for the unsigned compare I may need 4
(convert two integer operands to two double-length integer operands),
and with only 8 general registers to play with, I'd rather not waste
these when I don't need them.

What I really need (for the shift, this doesn't help the unsigned
compare) is a modifier in the constraints to say I'm going to clobber an
input operand, and it's value can't be trusted afterwards, like an
extension to %.  Still, pressing on, there is no longer any need to have
a named and a nameless pattern, I just have:

(define_insn "ashlsi3"
  [(set (...) (ashift:SI (...) (match_operand:SI 2 "general_operand" "rn")))
   (clobber (reg:SI 0))]
  ""
  "*
  if (GET_CODE(operands[2]) == CONST_INT)
    return \"lslw %2,%0\";
  else
    return gould_output_shift(GLD_LSLW, operands, insn);
")

but I still can't use my scratch register, because the compiler is
willing to put one of the operands in r0, even though I've said I'm
going to clobber it.  Presumably it thinks I have the sense to take a
note of what the operand was before clobbering, and will fill in the
right value after clobbering, if this is an output operand.

So:

o What do I have to do to get a scratch register ?

o Do I really have to define another 3 register classes, one excluding
  r0 for instructions that need one scratch register, one excluding r0 &
  r1, and one excluding r0-r3 ?

o Do I just have to put up with the fact that not all cases of the
  instruction are going to need these scratch registers ?

o Should clobber's be required to match when looking for instruction
  patterns, or is my problem just that I'm abusing this feature ?

o Should there be a "this input operand gets mangled" modifier available
  in constraints ?

Any help/suggestions welcomed, but please go easy on me if I've done
anything really silly.

Rob

-- 
UUCP:   ...!mcvax!ukc!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv at uk.ac.warwick.cu          ARPA:   cudcv at cu.warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England



More information about the Comp.lang.c mailing list