PPC Context_Control layout with __SPE__ defined
strauman at slac.stanford.edu
Tue Aug 9 09:48:08 CDT 2011
The altivec support uses a similar technique for cache-alignment, too.
Maybe we should think this over and still come up with a 'unified'
On 08/09/2011 07:57 AM, Sebastian Huber wrote:
> Hello Till,
> On 08/08/2011 10:00 PM, Till Straumann wrote:
>> Is there any good reason for the layout of the Context_Control struct
>> being radically different (from a C- point of view)
>> if __SPE__ is enabled?
> the layout is different because the save and restore will be cache
> aligned. Due to that (and other) optimization the SPE context switch is
> faster than the non-SPE context switch on the e500v2.
>> IMHO it would be preferable to adhere to the existing scheme so that
>> e.g., unbundled diagnostics and tools which access register contents
>> in a task context don't break.
> Yes, this is currently a big problem. It is on my TODO list. One problem
> is that our QorIO project ended this February. Due to some tool chain
> problems the BSP integration was a bit delayed. I have currently no time
> or budget to fix such issues. The current SPE support is the best I can
> offer at the moment.
>> instead of (score/cpu/powerpc/rtems/score/cpu.h)
>> #ifdef __SPE__
>> uint32_t context [ ];
>> I would suggest
>> uint32_t pad1;
>> uint32_t pad2;
>> uint32_t gpr1;
>> uint32_t msr;
>> uint32_t lr;
>> uint32_t cr;
>> uint32_t gpr14;
>> Another possibility would be removing the non-essential
>> registers (r2, r13, pc) from the non-SPE context, too
> We should really consider to remove r2 and r13 from the context. With
> the EABI these are useless no-ops.
>> and use an identical layout for SPE and non-SPE.
> It would be nice to have a cache aligned context. I don't know how we
> can achieve this best. I am not that happy with the current SPE approach.
> Kind regards,
More information about the rtems-users