[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Altivec Context Management
Ralf Corsepius wrote:
On Fri, 2005-11-04 at 08:16 -0600, Joel Sherrill wrote:
+ Add Altivec multilib
If we have extra registers which gcc is aware of, this forces our hand
and it adds a multilib.
We already have this multilib.
-mcpu=7400 implies altivec, all others don't.
Sorry I missed that piece of knowledge. Then RTEMS should just honor
the __ALTIVEC__ flag which is set when -mcpu=7400 is set. It will
require no tool changes for gcc 4.0.x.
The gcc version for 4.6 does not set __ALTIVEC__ when -mcpu=7400 is
I.e. if -maltivec is a problem to RTEMS and some BSPs, you should use a
different -mcpu=<cpu>. If this is not possible, the powerpc port in
RTEMS is facing a the limitations of its design.
IMO, a separate -maltivec multilib variant doesn't make without a major
redesign of the powerpc port.
It doesn't sound like the multilib variant is needed as long as
-mcpu=7400 is really the correct CPU model CFLAG for the BSPs/CPU models
But RTEMS does need to honor the __ALTIVEC__ flag and based upon gcc's
use of the vector registers, this would mean it is part of the basic
integer context when available.
Whether this should be done for 4.6 tools is up for discussion but it
is clear that gcc 4.0.x and newer definitely will have to ship with
Altivec multilibs for RTEMS.
They already do. RTEMS itself just needs to honor Altivec.
Good.. one less piece to deal with.
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