ppc multlibs and BSP removal was Re: powerpc altivec support

Wed Feb 9 12:40:08 UTC 2005

Ralf Corsepius wrote:
> On Tue, 2005-02-08 at 20:44 -0800, Till Straumann wrote:
> 
>>Ralf Corsepius wrote:
>>
>>
>>>On Tue, 2005-02-08 at 15:52 -0800, Till Straumann wrote:
>>> 
>>>
>>>
>>>>Hi.
>>>>
>>>>I'm looking into ALTIVEC support for RTEMS along the lines of
>>>>lazy FP context switching. However, I'd like to hide this from
>>>>SCORE code for obvious reasons. OTOH, it seems also ugly
>>>>to switch the vector registers as a side effect of CPU_Context_switch().
>>>>
>>>>Any suggestions?
>>>>
>>>>Ralf: what needs to be done to get an altivec enabled toolchain and
>>>>newlib for the CPU variants that support it?
>>>>   
>>>>
>>>
>>>Basically, by adding appropriate multilib variants to GCC.
>>>
>>>In general have to prove that such a multilib variant actually makes
>>>sense (gives a measurable improvement in performance) 
>>>and can not be avoided by other means.
>>>
>>
>>As far as I could see, lack of an altivec variant has the following 
>>implications:
>>
>> - libgcc doesn't use altivec --> only a possible stack misalignment
>> - newlibc setjmp/longjmp would not save/restore the altivec registers 
>>-> BAD
>> - newlibc vfprintf() would not support vector formats -> undesirable
>>
>>==> if we added altivec support to RTEMS [very desirable for 
>>number-crunching
>>         applications], we certainly need a newlibc with altivec support.
>>
>>         The good news is, however, that the newlibc code (essentially 
>>setjmp/longjmp)
>>         which needs a small __rtems__ patch anyways could perform a 
>>quick run-time
>>         check for altivec, i.e., altivec could essentially be enabled 
>>for any ppc variant
>>         (or at least 7400++).
> 
> 
> If customizing newlib's code for --altivec is worth it (I don't know),
> then somebody (you?) would have add this to newlib.
> 
> 
>>>However, due to the number of multilib variants being used by the
>>>powerpc, convincing me to add another one to powerpc-rtems-gcc will be
>>>extraordinarily tough.
>>>
>>>
>>>>BTW: I see in gcc/config/rs-6000/t-rtems (gcc-3.2.3 / rtems-4.6) that
>>>>          "no-eabi" is passed to all PPC variants (MULTILIB_EXTRA_OPTS)
>>>>          -- this might be out of sync, as EABI is the default PPC abi for
>>>>          RTEMS
>>>>   
>>>>
>>>
>>>Is it? That's news to me, but ...
>>>
>>>cf. http://www.rtems.org/cgi-bin/gnatsweb.pl?cmd=view&pr=195
>>>
>>>... nobody ever has been able to sort this out.
>>> 
>>>
>>
>>Looks like chicken + egg.
> 
> IMO, the origin of this problem is RTEMS design. It encourages
> optimizing for cpu-variants and forgets about data abstraction and
> intentional suboptimality (My usual example: Nobody needs an i586+mmx
> multilib variant, because an i586 will suffice in 99% of all cases. 

In this case newlib actually uses an Altivec conditional.  At the 
moment, RTEMS knows nothing about Altivec.  As Till mentioned, t seems 
to imply some alignment requirements.  Which is a multilib level issue.

> However, embedded folks do not seem wanting to accept similar
> consideration on embedded processors :-( ).
> 
> Another, less general issue in this particular case is lack of knowledge
> of the persons being involved. Everybody (including me) only knows about
> a "subset of the big picture", but nobody knows "everything".
> So, instead of cleaning up the mess, we are stuck with keeping up the
> status quo and try hard not to change anything, because somebody insists
> on something.

This is a real issue on the powerpc and mips.  There are LOTs of odd 
variant CPUs and it is hard to make generic statements.

>>BTW: mno-eabi probably doesn't really have a great impact as this 
>>effectively only
>>           changes the stack alignment. The really interesting thing 
>>could be
>>           enabling both 'meabi' and 'msdata=eabi'. This would improve 
>>both, space
>>           *and* speed efficiency.
> 
> Let me put it this way: We have full control over the ABI and ABI
> details being used, and can change that at any time.
> 
> You (the powerpc-rtems users) would have to tell me or Joel, what kind
> of ABI you prefer use. I see your BSPs using "-meabi -msdata=eabi", I
> see other BSPs not using it. I see probably obsolete code in the
> powerpc's cpu.h referring to other ABIs, I see RTEMS features (~itis?)
> infecting cpu.h in general ...
> 
> ... but I don't feel sufficiently knowledgeable on the powerpc
> architecture to be able to resolve this knot.
> 
> As a consequence of this, my standard approach to resolving such ABI
> issues is to question all requests for "non-defaults" CFLAGS and
> requests for additions of multilibs
> 
> 
>>OTOH, I totally agree that there are too many possible and useful variants.
> 
> Exactly - IMO, drastic measures would be justified.
> 
> E.g. I am not opposed to dropping one of the exception-processing
> variants for rtems-4.7, even if this will upset some powerpc users.

I think old exception process is now done to 4xx and a few 6xx BSPs.
I know of one old exception 6xx BSP which is in use and needs to be 
updated.  They have offered to do the conversion but that project has 
been up to its eyeballs the past 6 months and has barely made deadlines 
close enough to keep managment happy on required tasks. If someone can 
mechanically update it to the new exception model, I will be happy to
merge that and kill the 6xx BSPs.

I might even be willing to consider killing all the old exception 6xx 
BSPs except that and quit building it for a while.

Till.... if you could do that mechanically, it would kill some 
multilibs. and leave old exception processing on

Ralf.. at a quick glance.  I THINK the following variants multilibs are
up for discussion:

   + m821 and m860 -- these are equivalent and equal "mppc".  Mapping
     both to another multilib and kill.
   + All 601 and 602 variants should be dead.  Can someone comment.
   + Can mpc8260 should be mapped to a 603e variant AFAIK.
   + Ralf.. is the default multlib the same as 603?

I guess I am seeing that some of the variants could be overkill.  The 
same core is used in lots of CPUs.  Can we analyze each multilib and 
justify its existence?

>>I'd propose to discuss doing away with some of the 604 compatible variants
>>- probably, just one of them would be enough, e.g.:
>>
>>a) 604 with no altivec
>>b) 7400 with altivec
> 
> Let me ask differently: Which altvec variants do you want to add?
> 
> In RTEMS/CVS, we already have a 7400 BSP. With GCC-4.0, -m7400 already
> implies altivec. AFAIS, this BSP probably doesn't work when having been
> built against a multilib'ed RTEMS. 
> => I see a demand (need?) for a -m7400/altivec multilib variant, but I
> don't know if it is required or if this would be useful.
> 
> I don't know if altivec is useful for other powerpc-cpu-variants.

I think we can kill more than enough to make it possible to add.

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

>>--> AFAIK, a) can be run on anything from 604..7400 (assume gcc/newlib needs
>>       only the UEA)
>>--> applications with need for altivec can use b)
>>
>>Also, I don't see the benefits of a soft-float variant for all of the 
>>604++ machines
>>(maybe that applies to pre-604 also, I just know 604++ best).
>>
>>OTOH, having a few 'msdata=eabi meabi' variants would be useful.
> 
> I can't comment on these topics, others will have to comment on this :(

This always confused me.

>>Baseline: IMO, the number of pre-built variants should be cleaned up AND
>>                  a HOWTO would be desirable for users wanting to build 
>>tailored toolchains.
>>                  An embedded board with low memory might significantly 
>>benefit
>>                  from meabi/msdata=eabi and a high end application 
>>might need
>>                  cpu=7450 maltivec mabi=altivec. The user should be 
>>assisted
>>                  generating a tailored toolkit
> 
> With GCC-4.0:
> 
> gcc/configure --target=powerpc-rtems<custom> --disable-multilib ...
> make CFLAGS_FOR_TARGET=<custom-CFLAGS>

Can you put this in the WIki somewhere?

> 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