In message <[EMAIL PROTECTED]> you wrote: > > On Jun 18, 2008, at 5:58 PM, Paul Mackerras wrote: > > > Kumar Gala writes: > > > >> Is VSX mutually exclusive with altivec/fp? is there a MSR bit for > >> it? > > > > It's not exclusive, it's an extension of altivec/fp, and yes it has > > its own MSR bit to enable it. > > what MSR bit does it use... I'm not seeing the code add or test a new > MSR bit anywhere.
It's introduced in patch 8. #define MSR_VEC_LG 25 /* Enable AltiVec */ +#define MSR_VSX_LG 23 /* Enable VSX */ #define MSR_POW_LG 18 /* Enable Power Management */ > What exactly do you mean by its an extension of altivec/fp? Are the > instructions considered part of altivec/fp or is it just reusing the > register storage like SPE? VSX is considered separate instructions, but it uses the same architected registers as FP and VMX. ie if you execute a VSX instruction which touches VSX regsister 0, it'll change FP register 0 (and visa versa). Also, if execute a VSX instruction which touches VSX register 32, it'll change VMX register 0 (and visa versa). In fact, for this patch we use the 128bit VMX load/stores to perform the context save/restore on the VSX registers 32-63. I guess in theory you could have VSX without FP and VMX, but this patch assumes you have FP and VMX if you have VSX. This set of patches should allow any crazy mix of FP, VMX and VSX code and the architected state should be context switched correctly. Sorry, I'm not familiar with how SPE works, so I can't comment on it's relevance. Mikey _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
