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

Re: RFC: Removing OLD_EXCEPTIONS powerpc multilib variants



Till Straumann wrote:
Forgive me - I just don't understand - why you have to build
toolchain variants if all you want are different libcpu versions?

Why does the toolchain have to be built for the two exception models?
Just so the compiler picks different libcpu versions based on a
-DOLD_EXCEPTIONS or am I missing something here? Or to get it to
build two different versions using different flags?

The goal is distributing a toolchain that works for all BSPs.
Hence, you only need a (toolchain) variant if a BSP needs the standard
libraries to be built in a different way. soft-float is a candidate,
as is altivec or eabi but binary compatible CPUs or different CFLAGS
the stdlibs dont' depend on are NOT.

I'm not sure we need multilibs for RTEMS itself. Most people are
OK with building it themselves and need only one ore a few BSPs
and are probably happy without RTEMS multilibs.

Baseline: at some level you have to stop multilibbing because
          the number of variants grows exponentially - IMO the
          appropriate level is the toolchain. Once cpukit is
          totally BSP independent multilibbing can be extended
          there.

If I read that correctly, I agree 100% with you. The problem is the
amount of cruft under score/cpu/powerpc and the way it uses direct CPU models as ifdef's. It should be checking ONLY cpp predefines from gcc like soft float and Altivec.


But the fact of the matter is that it checks CPU model name right now and that needs to change.

--joel

Till.

Ralf Corsepius wrote:

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

I don't understand the need for a toolchain variant
for the exception model in the first place -- what
different features does OLD_EXCEPTIONS trigger in
libgcc/newlib/... ??


As far as code generation is concerned: None.

What introduces this need is RTEMS's cpukit. It contains code which is
conditionally compiled, based on pre-defined defines distinguishing
between old- and new- exception processing.

Now, the problem is the sheer amount of defines being used by the
powerpc port and identifying which of them are conditionally being used
based on old-/new-exception processing.

It's simply as this: Oversight has gone lost.


I believe this to be pure bloat anyways.


In an ideal world - yes. Historically - no.

If you can prove that there is no code in cpu which is conditionally
being compiled for old-exception/new-exception processing, these
multilib variants can be removed.

In the past, this did not apply. Since then, a lot as changed, and I am
close to be able to prove or counter-prove this - However, I am still
not there.


It only would
matter if you intend to create RTEMS libcpu variants
- one for the old and one for the 'new' exception model.


Right, that's what I am aiming at - I have an experimental patch pending
which ATM moves ca. 50% of all the powerpc defines from cpukit to
libcpu.

Ralf






--
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