Altivec context was Re: Multilib swamp
gregory.menke at gsfc.nasa.gov
gregory.menke at gsfc.nasa.gov
Wed Mar 2 18:37:26 UTC 2005
"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.
Gregm
More information about the users
mailing list