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