new baby in the multilib family

Till Straumann strauman at slac.stanford.edu
Tue Jul 15 19:05:13 UTC 2008


Tim wrote:
> On Mon, 2008-07-07 at 14:32 -0700, Till Straumann wrote:
>   
>> I just realized that a new baby (8540) recently has joined the already big
>> powerpc multilib family (IMO w/o good reason).
>>     
>
>   
>> b) have somebody explain why they think mcpu=XYZ other than mcpu=powerpc 
>> is necessary
>>     If no good reason is found after discussion, kill the unnecessary ones.
>>
>>     
>
> +1 for trimming ppc multilibs.
>
> I'm working on ppc440 support - it looks like setting mcpu=powerpc
> (inside make/custom/my_bsp.cfg) might prevent the use of a whole bunch
> of extended mnemonics: those that use mtspr/mfspr for example. It'd be
> cool to keep these for readability in dlentry.S (or equiv).
>   
The reason it breaks is because of asm.h:

#if defined(ppc403) || defined(ppc405)
#define evpr 0x3d6
...

There is really no need for a different multilib flavor in this case (a 
good example
for why our current jungle became what it is). You simply build
your BSP with

-mcpu=powerpc -Dppc403 -msoft-float

...

It would be better to (unconditionally) define e.g.,

#define ppc405_evpr 0x3d6

and use that in dlentry.S. An even better way would be using the

mtevpr

mnemonic (which is understood by powerpc-rtems-gcc -mcpu=powerpc)
instead of a macro.

-- Till

PS:
The proposed way to reduce multilibs is
  a) reducing multilibs to essential variants (gcc configuration, 
t-rtems & friends)
  b) build all UISA code (newlib, cpukit, ...) using the supported
     multilib variants
  c) build libcpu/libbsp with
             -mcpu=xxx -myyy
     to select appropriate multilib variant AND
            -D<ppc_flavor>
     to select appropriate conditionally compiled sections in libcpu/libbsp
> Thoughts?
>
> Tim
>
>   




More information about the users mailing list