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