Altivec context was Re: Multilib swamp

Till Straumann strauman at slac.stanford.edu
Wed Mar 2 20:39:24 UTC 2005


Joel Sherrill wrote:

>
>> 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. 

Yeah, sorry - I just dug that out.

>
> 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. 

I'm not sure if that's a good, generic solution. How about changing

void
_Context_Switch(Context_Control *from, Context_Control *to);

into

void
_Context_Switch(struct Thread_Control_struct *from, struct 
Thread_Control_struct *to);

? Since 'Context_Control' is defined by the CPU-specific code, and 
_Context_switch()
is, too, [_Context_switch simply is macroed to _CPU_Context_switch].
The new interface would simply allow the CPU specific code to handle
all necessary context information. However, it needs access to the
Thread_Control_struct [e.g., to check the thread's flags].

Similar changes would have to be made to _Context_Initialize() and
a hook would probably needed in _Thread_Initialize() to allow CPU
specific extensions to allocate memory from the workspace.

Anyways - until all the hooks are there, I probably add altivec support
as a user extension first...


>
>
> As always the issue is whether one can control the compiler well
> enough to limit these architectural extensions to a subset of
> tasks. 

At least with altivec this is should not be a problem. The only thing
that changes for code that doesn't use the special vector data types
is the stack alignment which must be maintained.

>
>

-- Till




More information about the users mailing list