This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Cleanups for the m68k backend
On Tuesday 08 July 2003 14:51, Gunther Nikl wrote:
> > 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.: [...]
It's certainly possible to improve the current situation _and_
keeping the MIT syntax, but we get the most effective result with
the smallest effort by removing it completely.
> 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).
I see. Then we need to use the method suggested by Andreas...
It's not that bad.
> > 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?
This is a completely different problem. It bothers me and GCC developers
in general, so it should be addressed too. Not by me, because I'm not
qualified for the job.
My initial post was about cleaning up m68k.c and m68k.md by unifying
Motorola and MIT syntaxes to remove those two hundereds #ifdef's cluttering
the code. Of course it will take several days of work, therefore we're
evaluating an easier solution: getting rid of the least used syntax.
> > 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.
That must have been left in GCC by mistake: all m68k ports of NetBSD
have been switched to ELF since 1.6.
> > 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.
Found:
Tue Nov 24 20:24:59 1998 Jim Wilson <wilson@cygnus.com>
* configure.in (m68020-*-elf*, m68k-*-elf*): New targets.
* configure: Rebuild.
* config/elfos.h: New file.
* config/m68k/m68020-elf.h, config/m68k/m68kelf.h,
config/m68k/t-m68kelf: New file.
Who is using m68020-*-elf*? Could we drop it and rename "m68020-elf.h"
to "m68k-elf.h" which is much more easier to understand? I'm using a
ColdFire CPU, so it's funny that I should care about a header named after
the 68020 ;-)
> > 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.
I'm glad someone finally did it. I was worried when the Amiga was being
left behind with 2.95.2.
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html