PPC Context_Control layout with __SPE__ defined

[Till Straumann]

The altivec support uses a similar technique for cache-alignment, too.
Maybe we should think this over and still come up with a 'unified'
approach.

T.

On 08/09/2011 07:57 AM, Sebastian Huber wrote:
> Hello Till,
>
> On 08/08/2011 10:00 PM, Till Straumann wrote:
>> Sebastian.
>>
>> 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.
>
>>
>> I.e.,
>>
>> instead of (score/cpu/powerpc/rtems/score/cpu.h)
>>
>> #ifdef __SPE__
>> uint32_t context [ ];
>> #endif
>>
>> 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,
> Sebastian
>