MVME5500 broken with gcc-4.0.2
strauman at slac.stanford.edu
Mon Oct 31 23:55:07 UTC 2005
Peter Dufault wrote:
> On Oct 31, 2005, at 6:05 PM, Till Straumann wrote:
>> rtems/gcc (implicitely) uses -maltivec on all 74xx CPUS and
>> the MVME5500 calls for -mcpu=7450.
>> Unfortunately, with -maltivec, gcc uses vector registers for
>> some optimizations.
>> --> until proper altivec support is implemented in RTEMS random
>> *data corruption* must be expected.
>> make/custom/mvme5500: use -mcpu=750
>> -- Till
> I've been using the mvme5500 24/7 using an earlier rev of gcc 4.0 in
> a heavily floating point control application, with optimization on,
> with a similar gcc configuration. I don't explicitly use the
> altivec. I assume you're saying that gcc is using the vector
> registers for data movement but RTEMS isn't saving / restoring them
> and that's where the problem should come in,
> but I'm not noticing any problems.
It's nasty because probability for corruption can be very low but >0. A
context switch must happen
while a vector register is in use and the register must be modified by
Hopefully, MSR_VE should be off at startup so you would incur an
exception (happens to me)
at an attempt to use vector registers.
> I've got lots of multi-axis floating point control going on and a
> heavy network load. Did anything change in newer 4.0.x releases?
> I've built everything with 4.0.2 but haven't run things yet.
More information about the users