PPC Context_Control layout with __SPE__ defined

[Sebastian Huber]

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

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.