[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ppc multlibs and BSP removal was Re: powerpc altivec support

Ralf Corsepius wrote:
On Thu, 2005-02-10 at 15:07 +0300, Sergei Organov wrote:

Ralf Corsepius <ralf.corsepius@rtems.org> writes:

On Wed, 2005-02-09 at 19:40 -0800, Till Straumann wrote:


PPC_HAS_DOUBLE is primarily used in task-switches, so I am wondering
what PPC_HAS_DOUBLE actually means:
* The CPU lack some (double) instructions, therefore requires a
customized task-switch. Makes me wonder, what happens with GCC generated
FPU code on these CPUs.
* The CPU needs customization because it lacks a feature.

It means that CPU lacks both double registers and double instructions, I think. I.e., FPU registers are 32 bits and single-precision instructions should be used for load/store.

The only such CPU in RTEMS seems to be 602,

As far as PPC_HAS_DOUBLE is concerned, yes.

As far as PPC_HAS_FPU is concerned, the situation is not clear to me.

but I've no idea if it's in
fact used/supported.

For GCC the 602, 603 and 603e are identical.

They apply the same ISA:

from rs6000.c:

from rs6000.h:
%{mcpu=602: -mppc} \
%{mcpu=603: -mppc} \
%{mcpu=603e: -mppc} \

So the only part being involved which distingushes between them is

i.e. if all 602/603/603e specific defines could be removed from cpukit,
we could fold all of them into one multilib variant.

Let's head for that. If someone comes up with a real 602 and wants a BSP for it, we can encourage them to do the double emulation.

ATM, there remains PPC_HAS_DOUBLE (used by the 602) and
PPC_LOW_POWER_MODE (used by the 603e) which prevent this.

Double check me but PPC_LOW_POWER_MODE is defined but never used.

I would assert that it SHOULD be in libcpu/powerpc somewhere.
Offhand, I don't know how it works. Normally, low power requires
some CPU model specific idle thread. It looks like the 603e has it is CPU specific HID registers so I would say this logic belows in
libcpu/powerpc/shared in a lowpower/idle file. It might be nothing more than letting that file define the IDLE thread based on the CPU model.

The reality is that right now, I can find no code using this information.

All other defines currently being used by the 602/603/603e can be
eliminated (e.g. *_CACHE), or generalized (PPC_ALIGNMENT =

That certainly simplifies it. :)