[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
9806018 CPU32/CPU32+ problem still with us: patch attached
- Date: Wed, 24 Jun 1998 13:36:39 -0500 (CDT)
- From: joel at oarcorp.com (Joel Sherrill)
- Subject: 9806018 CPU32/CPU32+ problem still with us: patch attached
On Fri, 19 Jun 1998, Robin Kirkham wrote:
> Unfortunately c/src/exec/score/cpu/m68k/m68k.h incorrectly defines
> M68K_HAS_MISALIGNED for the plain old CPU32 (it is correct for the CPU32+).
> As a consequence, the recently-relocated m68k memcpy() may still attempt
> misaligned memory accesses.
> The attached patch to m68k.h proposes a solution (sort-of).
> I suggest that until such time as egcs/gcc differentiates these cores
> that we invent a new preprocessor symbol, RTEMS__mcpu32p__ for this
> purpose, on the assumption that egcs may one day grow a -mcpu32+ option
> which will define a __mcpu32p__ symbol (whether this option would also
> define __mcpu32__ is yet to be resolved).
> BSPs that have a CPU32+ (like gen68360) would for the time being define
> RTEMS__mcpu32p__ using -D. The symbol is `RTEMS__mcpu32p__' because
> symbols of the form __xxx__ should only be defined by the compiler
Rather than using another -D option, it should be in the "targopts.h" set
of defines. But other than that I am happy.
> An aside:
> Note that in egcs-1.0.3a, the option -m68332 is identical to -mcpu32,
> except it defines __mc68332__ as well as __mcpu32__. This is only
> for the sake of compatibility. The story with -m68302 is similar;
> it defines __mc68302__ and __mc68000__. In my opinion these options
> are depreciated and ought to be avoided in RTEMS.
The use of __mc68302__ and __mc68332__ in m68k.h look OK even they go away
in the future.