This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH for 3.2] PDP-11 -msoft-float support
Thank you for your comments Rechard.
On Mon, 7 Oct 2002 01:16:47 -0700
Richard Henderson <rth@redhat.com> wrote:
>
> > - fprintf(stream, "\tmov fp, -(sp)\n");
> > - fprintf(stream, "\tmov sp, fp\n");
> > + fprintf(stream, "\tmov r5, -(sp)\n");
> > + fprintf(stream, "\tmov sp, r5\n");
>
> Why?
>
> Anyway, consider using reg_names so that everything is consistent.
>
> > + /* change fp -> r5 due to the compile error on libgcc2.c */
>
> An actual explanation should be provided. This does not help
> anyone understand why they shouldn't revert the change.
The register name change is for GAS which does not understand 'fp.'
The DEC compiler may be usable with 'fp.'
I want the output of the gcc to be compatible with both GAS and DEC assembler.
The 'r5' is valid for both. (Of course we can change GAS to take 'fp' but
I don't want to make patches for both projects.)
>
> > - fprintf((stream), "\tadd $%o, sp\n", fsize);
> > + fprintf((stream), "\tadd $0%o, sp\n", (fsize)&0xffff);
>
> Should be "$%#o".
It seems much better. I will take it. Thank you.
> > -#define LEGITIMATE_CONSTANT_P(X) (1)
> > +#define LEGITIMATE_CONSTANT_P(X) (TARGET_FPU? 1: !(GET_CODE(X) == CONST_DOUBLE))
>
> Are you sure? This means many long long values aren't legitimate.
> Can you store the constant zero to memory easily? In which case
> CONST0_RTX should be valid.
I thik the long long constants are not cheap in pdp11. Because pdp11 only has 16bit
instructions except FPU. But if there is some simple way to restrict
the macro not to legitimate the floating point constant, please let me know.
> > (define_insn "movdi"
> > - [(set (match_operand:DI 0 "general_operand" "=g")
> > - (match_operand:DI 1 "general_operand" "g"))]
> > + [(set (match_operand:DI 0 "general_operand" "=g,rm,m")
> > + (match_operand:DI 1 "general_operand" "m,r,a"))]
> > ""
> > "* return output_move_quad (operands);"
>
> Are you sure you don't want offsetable memory, ie the 'o' constraint?
Maybe offsettable memory should be valid. The 'm' may be changed by 'R'
or something. But it remains for future study.
>
> > +;; lsr
> > +(define_insn ""
> > + [(set (match_operand:HI 0 "general_operand" "=rR,Q")
> > + (lshiftrt:HI (match_operand:HI 1 "general_operand" "0,0")
> > + (const_int 1)))]
> > + ""
> > + "clc\;ror %0"
> > + [(set_attr "length" "1,2")])
>
> Are you sure your length attribute is correct? It looks
> to me like you've always got 2 instructions here.
The 'Q' operand means costly operand in pdp11 port.
Though it generate 2 instructions for the body,
to make the 'Q' operand it needs additional instructions.
But maybe we can simply reduce the second alternative.
>
> > +(define_insn "negsi2"
> > + [(set (match_operand:SI 0 "register_operand" "=r")
> > + (neg:SI (match_operand:SI 1 "general_operand" "0")))]
> > + ""
> > +{ /* Here we trust that operands don't overlap */
>
> Huh? You forced them to overlap.
Sorry I forgot to delete the comment in the insn
which I borrowed the code from other insn.
> I went ahead and committed the patch, since I suspect
> that no one else is using pdp11, and that'll reduce
> the subsequent patches.
I also think no one else want to use pdp11 anymore.
But it is usable for educational purposes and I want to
make gcc, binutils, newlib workable for it.
I hope some educational institutes may be interested in pdp11 again.
> Please see http://gcc.gnu.org/cvs.html to see how to
> generate patches against the cvs repository instead
> of snapshots. Hopefully you're not behind a firewall
> that prevents this...
I will check the url and study how to use cvs from now.
Thank you.
--
Naohiko Shimizu
Dept. Communications Engineering/Tokai University
1117 Kitakaname Hiratsuka 259-1292 Japan
TEL.+81-463-58-1211(ext. 4084) FAX.+81-463-58-8320