[Bug 1740] Change PowerPC multi-libs for e200 and e500 cores
bugzilla-daemon at rtems.org
bugzilla-daemon at rtems.org
Fri Feb 25 08:42:31 UTC 2011
https://www.rtems.org/bugzilla/show_bug.cgi?id=1740
--- Comment #16 from Sebastian Huber <sebastian.huber at embedded-brains.de> 2011-02-25 02:42:25 CST ---
(In reply to comment #13)
> (In reply to comment #12)
[...]
> I'd also like to discuss the SPE issue a little more. Sebastian earlier asked:
> "You can use -mspe in your BSP and application code. Do you really need a
> libc,
> libm, libgcc with -mspe?"
During that time I was not aware that the SPE support in GCC is quite brittle.
>From my point of view -mspe and -mabi=spe is mandatory, if you want to use any
SPE instructions. This is covered by:
#undef SUBSUBTARGET_OVERRIDE_OPTIONS
#define SUBSUBTARGET_OVERRIDE_OPTIONS \
do { \
if (TARGET_E500) \
{ \
if (!rs6000_explicit_options.float_gprs) \
rs6000_float_gprs = 1; \
if (rs6000_float_gprs != 0 && \
!rs6000_explicit_options.spe) \
rs6000_spe = 1; \
if (rs6000_spe && \
!rs6000_explicit_options.spe_abi) \
rs6000_spe_abi = 1; \
} \
} while(0)
This is also similar to:
gcc/config/rs6000/eabispe.h
> and I have to answer "I don't know", I'm concerned about callbacks from
> contexts without the SPE into code compiled with -mspe. It can be handled by
> disabling the SPE in all contexts where its use isn't expected, and then
> handling the enable in a "no SPE available" exception, but I'm not sure I like
> that in a real-time OS and I want to understand the benefits and drawbacks of
> the recommended approach.
The SPE is enabled in every context with my new interrupt and context switch
code. You can also use SPE instructions in interrupt handlers. There is no
performance penalty here, in fact it is faster than disabling the SPE during
interrupts.
--
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the bugs
mailing list