Re: [PATCH for 3.2] Make PDP-11 port compilable

[Naohiko Shimizu <nshimizu at keyaki dot cc dot u-tokai dot ac dot jp>]

Thank you Paul for your comments.

It is a good news for me that there is a person who is
interested in the PDP/11 port.

I revised the patch with your indication.

On Wed, 4 Sep 2002 11:18:35 -0400
Paul Koning <pkoning@equallogic.com> wrote:

> + (define_insn ""
> +   [(set (mem:QI (pre_modify:HI (reg:HI 6)
> +                                (plus:HI (reg:HI 6) (const_int -2))))
> + 	(match_operand:QI 0 "register_operand" "r"))]
> +   ""
> +   "movb %0, -(sp)"
> +   [(set_attr "length" "1") ])
> +
> 
> This can be done more generally by changing GO_IF_LEGITIMATE_ADDRESS
> to accept pre_modify by -2 and post_modify by 2 for register 6.  Then
> it can be used in any rtx (not just the single one you defined)
> without any changes in the pdp11.md file.  (It will match "R"
> constraints.)


It must be "mov" instead of "movb". It was my mistake. With "movb", we can
update sp only by -1, but "mov" will update by -2.
I think it is difficult to generalize in GO_IF_LEGITIMATE_ADDRESS
because we must convert the QI to HI when pushing the operand on 
the stack. This code seems to be only available for the "char" arguments 
of a function.
Or if you have a good idea please show me the way.

> +(define_insn ""
> +  [(set (match_operand:HI 0 "general_operand" "=rR,rR,Q,Q")
.... deleted ....
> +{
> +  return \"bitb %2, %0\";
> +}"
> +  [(set_attr "length" "1,2,2,3")])
> +
> 
> That's not correct, because "bit" and "bitb" only change the condition
> codes; they do not modify the operands.  The only "and" operation on
> the PDP-11 is bic (which is "and not").

I revised to use "bic". But we have "andbchi3" and "andbcqi3" which
use the "bic". I have no idea why gcc does not use them.

>  (define_insn "xorsi3"
>    [(set (match_operand:SI 0 "register_operand" "=r,r,r,r")
>          (xor:SI (match_operand:SI 1 "register_operand" "%0,0,0,0")
> -                  (match_operand:SI 2 "arith_operand" "r,I,J,K")))]
> +                (match_operand:SI 2 "arith_operand" "r,I,J,K")))
> +   (clobber (match_scratch:SI 3 "=&r,r,r,r" ))]
> 
> Another approach that works (I do not know which is better) is to
> change the operand 2 constraints to "r,r,r,r" so the source operand is
> always a register.  That way it matches what the xor instruction
> requires.  (The problem in the original is that the xor instruction
> has a source operand that's a register, and a general destination
> operand -- the reverse of mul and div.  The author of the original
> pattern assumed that xor follows the same rules as mul/div.)

The CPU must do the same thing for both approach. Then the
generated code might be the same.
Restricting the oprand 2 for the register is much simpler.
Then your approach may be better in general.

Naohiko Shimizu

Attachment: gcc-3.2-pdp11-020905.patch
Description: Binary data