Altivec context was Re: Multilib swamp

[Joel Sherrill <joel@OARcorp.com>]

gregory.menke at gsfc.nasa.gov wrote:
> "Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
>  > 
>  > > Brings me right back to the question I asked originally - how could we 
>  > > best add hooks for
>  > > altivec register context switching [ without introducing an ugly #ifdef 
>  > > __PPC__ into cpukit]?
>  > > 
>  > > Ideas?
>  > 
>  > I thought I had emailed you privately with a suggestion based upon
>  > what I thought would be most general to other architectures.
>  > Multimedia/vector extensions are not uncommon in architectures
>  > anymore.  Although some only consist of instructions which are
>  > an alternate view of FP or 64-bit integer registers.
>  > 
>  > I propose a 3rd type of context to be added to the integer and
>  > FPU ones we have now and a task attribute which is comparable to
>  > that for has floating point.  It could be disabled on CPUs without
>  > this capability just like FP is done now.
>  > 
>  > As always the issue is whether one can control the compiler well
>  > enough to limit these architectural extensions to a subset of
>  > tasks.
>  > 
> 
> 
> I'm in favor- some MIPS processors have a number of coprocessors
> beyond the FPU which could be made inaccessible if not context swapped
> for tasks without permission to manipulate them.  But I think any
> features along those lines will inevitably bring along nasty cpukit
> #ifdefs.

Then Thomas' idea of a multi-bit register extension value and user 
extensions for context switches would be the most flexible one.


--joel