This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [m68k] Convert CPP_SPEC to TARGET_CPU_CPP_BUILTINS
Gunther Nikl wrote:
On Tue, Sep 16, 2003 at 02:19:40PM -0500, Joel Sherrill wrote:
#if ( defined(__mc68020__) || defined(__mc68030__) )
#if defined(__mc68030__)
/* Only the mc68030 has a data cache; it is writethrough only. */
...
You could define __mc68030__ on your own when you really need it.
We could but this hints at the philosophical issue about the cpu model
flags. I am pretty sure this is not consistent across gcc. At least,
the mips and powerpc confuse me enough not to be sure. :)
Right now, there is an odd mix of flags about CPU cores and CPU
models. Most of the time, the multilibs correspond pretty directly to
CPU core variations and the CPU model specific flags map to those
multilibs.
First, the set of CPU model flags is incomplete. Why have 68332 and not
68331 or 68340 -- all CPU32 cores. From a user perspective, it would be
helpful to have lots of CPU model flags that were internally mapped to
the right CPU core multilib and just set an extra predefine for the
particular model. This is an old message showing some of the ideas:
http://gcc.gnu.org/ml/gcc/1997-10/msg00221.html
From RTEMS experience on the mips and powerpc, if there were more CPU
model flags that hid the mapping, it would make it much easier to get
the right set of CPU flags. It is often hard to get the right CPU
flags on those families.
So I agree that there should be CPU core flags like -mcpu32, -m5200,
-mips1, -mips2, etc.. But there should also be an always growing set of
CPU model flags which are usually simple wrappers for the CPU core
setting plus a define for the CPU model. This would help the user
since I think it is safe to assume that the gcc maintainer knows
more about which CPU model settings are appropriate than Joe Developer.
Second, there are a handful of odd cases where a CPU core flag implies
some particular CPU model. There are at least the case where -mcpu32
implies mc68332 and sine ColdFire CPU core variations where a particular
model is implied (CFV3-> mcf5307, CFV4 -> mcf5407). Similarly, 68020
implies both mc68020 and mc68030.
The trend to system-on-chip CPUs has really reinforced my notions on
code portability in embedded systems and we push this idea in RTEMS
to get more reuse. I contend that for each CPU architecture
there are a handful of CPU cores. Those CPU cores are then combined
with arbitrary peripherals, cache, etc. to meet customer requirements
and that creates a unique CPU model. Those CPU models are then
combined with other standard parts to form boards.
GCC is concerned primarily with the CPU core and that is reflected in
the multilib variations. If you want to know what peripherals you
have on CPU, then you have to know the precise CPU model.
So I see two alternatives -- go strictly to flags reflecting only CPU
core or add more CPU model flags which in turn map to the appropriate
CPU cores. But right now, gcc is doing a bit of both and mixing them
up.
http://lists.debian.org/debian-glibc/2002/debian-glibc-200209/msg00200.html
That appears to be mostly glibc related but there is a patch for gcc 3.2
CVS on it that improves 68030 code generation.
I can't affirm that. There is only a 68030 test in a longlong header of
GCC. The test would succeed with -m68030 even with mc68030 beeing defined
because it also tests mc68020.
OK. I just did a quick perusal of it and gave it too much credit. :)
Gunther
--
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985