RFC: Removing OLD_EXCEPTIONS powerpc multilib variants

[Joel Sherrill <joel@OARcorp.com>]

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 at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985