[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 Wed, 2005-02-09 at 19:40 -0800, Till Straumann wrote:

Ralf Corsepius wrote:

On Wed, 2005-02-09 at 16:25 -0600, Joel Sherrill  wrote:

Ralf Corsepius wrote:

GCC thinks a lot of -mXXX are -mppc internally anyway and RTEMS PROBABLY
doesn't care until you get to libcpu and libbsp.

Unfortunately nothing could be further from the truth than this, as far as the powerpc is concerned - It is the design issue/flaw I have been repeatedly referring to.

cpukit/score/cpu/powerpc/rtems/score/cpu.h is ca. 700 lines in size,
scattered with ca 30 different defines, which all are candidates for
conditionally compiling something somewhere. The problem there is to
identify which are actually important and which are not.

Try to track how *ALIGNMENT defines are set up and you'll probably
experience what I am referring to.

Turns out the more you live, the more you learn. :)

Absolutely - and life is still too short...

Whom are you telling? :)

PPC_CACHE_ALIGNMENT appears to be the same for almost all configurations. It can be condensed to 1 define of 16 as best I can tell. It is only used to properly align the bitmap structure used
for thread scheduling. If a multlib can distinguish the core in the 7455 and 8260, they use 32. The 74xx has an Altivec so that would be a good candidate to multilib on and use 32.

Some PPCs have 16byte caches [860] most 32 byte. In any way - before considering a multilib

  a) check the implications of always using 32byte alignment by default
     [user with special demands such as squeeze ram might need to rebuild
     a new configuration].
  b) if that's not practical, consider a run-time check. Cache line size
     can easily be determined at startup and read from a variable.

PPC_ALIGNMENT is basically what the heap has to align to. Does a double
have to be 8 or 4-byte aligned? A quick guess is that if you have hardware FPU, then make it 8, else make it 4.

Might be an ABI issue anyways. AFAIK, malloc() must return memory aligned properly for any data type (except vectors, altivec has a special allocator).

SYSV demands that long double variables shall be 16-byte aligned,
EABI relaxes this to 8-byte alignment.

Can anybody confirm these assumptions? If they hold, this was a
breakthrough, causing powerpc.h to substantially collapse.

So far, we really only have SYSV vs EABI

OK - But, what do we have: SYSV or EABI?

We have PPC_ABI_EABI set in RTEMS, we have -nno-eabi in GCC and seem to
be using sysv rules in GCC.

=> We are back to PR195

I think we are using EABI not System V.

Also as far as I know, there was NEVER an RTEMS user on the 601 or 602.
Those still say "Submitted with original port -- book checked only." so that makes them high priority kill targets if they present any issues.
But all I see are alignment constants for them which are easy to get out of the score.

Can we deduce PPC_HAS_FPU directly from a cpp predefine?

Conversely, I think we must.

Adding a _SOFT_FLOAT != PPC_HAS_FPU preprocessor check reveals
PPC_HAS_FPU to be inconsistent in comparison to _SOFT_FLOAT, i.e.

I agree.

Meanwhile I am not sure anymore.

What is the purpose of PPC_HAS_FPU and PPC_HAS_DOUBLE?

Do they describe that a CPU *has* FPU rsp. DOUBLE support, or do they
describe that RTEMS *uses* the FPU rsp. DOUBLE.

In the latter case, tying PPC_HAS_FPU to _SOFT_FLOAT would be correct,
in the former case this would not necessarily be correct.

E.g. a CPU with FPU built in might need a different task switch/require
different instructions inside a task-switch than a CPU w/o FPU, even if
not actually using the FPU. I have never seen a such a case, so I assume
PPC_HAS_FPU is meant to mean "uses FPU".

PPC_HAS_FPU means has and RTEMS may use. You still have the task attributes if the application doesn't want to use the FPU and RTEMS will disable the FPU on a per task basis

PPC_HAS_DOUBLE is a bit harsher. If a CPU implementation had only 32-bit FP registers (rather than 64-bit ones), then we could only save them that way.

PPC_HAS_DOUBLE follows directly from PPC_HAS_FPU so I don't see any hint
of a CPU really having only 32-bit floating point registers. Doing a quick search of gcc, I don't see such an animal either.

Neither do I.


Partial correction: I don't see such an animal in GCC, but I see one in RTEMS.

The m602 seems to be wanting to use
#define PPC_HAS_FPU 1
#define PPC_HAS_DOUBLE 0

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.

The 602 manual definitely confirms it has a 32-bit FPU. I haven't found yet what it does for doubles except the "emulation" keyword in the description. I would leave the code in and let's not worry about it as a multilib variant. Trip it ONLY if explicitly built with 602 defined after doing the multilib checks. I believe gcc does care about this
feature and will generate 64-bit lds/stores.

As a practical matter, no one that I know if is using this CPU. Don't completely kill it, just don't waste CPU cycles building a multilib specifically for it.