gcc 3.4.2 cpu32 patch

[Ralf Corsepius]

On Thu, 2004-11-18 at 15:54 +0100, Bernardo Innocenti wrote:
> Ralf Corsepius wrote:
> > On Thu, 2004-11-18 at 17:49 +1100, Chris Johns wrote:
> > 
> >>Ralf Corsepius wrote:
> >>
> >>>Correct me if I am wrong, but AFAIS, it would be sufficient to extend
> >>>RTEMS m68k score to using __mcoldfire__ and __mcpu32__.
> >>>

> > AFAIU, GCC now seems to interpret the cpu32 as a sub-variant of the
> > m68020, while RTEMS expects the cpm32 to be treated as a cpu-variant
> > neighboring the 68020.
> 
> Internally, GCC always has been seeing the CPU32 as an m68k
> with no bitfield instructions, which is very, very close to
> the truth.
> 
> What's been changed in GCC 3.4 is that we've moved away from
> the specs-based approch, which was mapping command-line
> options to predefines.
Unfortunately, the latter is what current RTEMS code expects.

> Kernels sometimes want more detail: GCC doesn't care
> about the difference between the 68000 and the 68010,
> but system code might want to use the VBR.
You've hit the nail right on its head :-)

This is exactly what RTEMS code applies GCC's predefines for.

> > So, we would have to reflect this change into rtems:
> > #if __mc68020__
> > #if __cpu32__
> > ..
> > #else
> > #endif
> > #endif
> 
> In the long term, I think adopting this new scheme would
> be best for user-code such as RTEMS.

OK, fine with me. I think we have a solution for this problem.

>   There are very few
> cases where you need to special-case a 68332 wrt a 68020.
> The only thing I can come up with is performing bitfield
> operations with inline assembly.

:-) Exactly this is done in RTEMS.

> A much better scheme would be adding predefines for the
> different m68k ISAs instead of trying to capture them with
> chip names.  This scheme would still be full of pitfalls
> because there's no clear subset/superset relation between
> different members of the m68k family.

This is the same problem we are facing with other CPUs. GCC is moving
towards ISAs and ABIs, while RTEMS internals historically is "structured
by CPU-variants", because this often allows a finer grained/more
detailed optimization than GCC needs.

Ralf