Cleanups for the m68k backend

[Gunther Nikl]

On Tue, Jul 08, 2003 at 11:46:04AM +0200, Bernardo Innocenti wrote:
> On Tuesday 08 July 2003 09:47, Gunther Nikl wrote:
> 
>  > On Tue, Jul 08, 2003 at 07:36:03AM +0200, Bernardo Innocenti wrote:
>  > >  Every obsolete feature you drop opens the opportunity for more
>  > > cleanups.
>  >
>  >   True, but I won't call MIT syntax obsolete.
> 
>  It's not obsolete. It's just useless when no supported target
> depends on it. Since it's useless, we have the opportunity to
> declare it obsolete and drop it from GCC.

  You want to remove a _working_ feature! Please there have been several
  suggestions that would improve the situation, eg.:

     http://gcc.gnu.org/ml/gcc/2003-07/msg00380.html

  or

    http://gcc.gnu.org/ml/gcc/2003-07/msg00530.html

  However, it seems output_asm_insn() is only suitable for simple
  instructions (not everything that can be done with asm_fprintf()
  can be done with output_asm_insn).

>  > Since a lot of dead configurations are already gone the m68k backend
>  > should be much more manageable now.
> 
> Not as managable as most developers would like it to be. There are
> many areas where the m68k back-end shows its age and makes things
> difficult to work with. The most invasive thing is that MOTOROLA/MIT
> dual syntax.

  I disagree. Droping one variant solves no problem. AFAICS, your problem
  is the structure of target headers, isn't? Why don't you solve your real
  problem and keep a working feature?

> Within this thread we've found out that some of the remaining targets
> could switch to the Motorola syntax in no time.

  I don't think so. AFAICT, m68k-netbsd is supported and its non-ELF. I
  believe it needs MIT syntax.

>  The problem here is that I don't know how it's supposed to work for
> all possible targets. What does m68020-elf.h mean? Who introduced it
> and for what reasons?

  Since my target isn't ELF I can help you. I can only suggest that consult
  the ChangeLogs, use cvsweb (http://gcc.gnu.org/cgi-bin/cvsweb.cgi/) and
  look at other non-m68k ELF ports. Thats what I did when I revived the
  AmigaOS port.

> Digging into this problem is something that's best done by long-time
> GCC developers like you.

  I am sorry to say, but I am not a long-time GCC developer. I am using
  GCC since 10 years (2.3.3). Only recently I ported the old 2.95 AmigaOS
  patches to 3.x. Now I have more insight in GCC internals than before,
  but mainly for my non-ELF target.

  Gunther