Scott Wood wrote:
BTW, it's actually simpler than I originally described (I had implemented
this years ago in the TimeSys kernel for x86 and some other arches that
already use FP or similar resources for memcpy, but the memory was a
little fuzzy); the FP restore code doesn't need to test anything, it
always restores from the regular spot. The kernel code wishing to use FP
saves the user context in an alternate save area (it could even be on the
stack, allowing atomic context to use it as well, if it's not too large),
and restores it when it's done.
Sure, it's simple, the problem is that VRSAVE isn't maintained in the
kernel, which means for AltiVec context switches you need to save and
restore 32 128-bit registers every time. And that takes a LONG time..
Just imagine if you did a ~512 byte memcpy, you could guarantee that it
would take twice as long as it should!
There are ways around it, like assembly and fixed registers, and saving
the ones you use (this is the sort of thing gcc does for you usually,
but you can do it by hand just as well) and restoring the ones you
trashed afterwards, but that makes code messier and less readable.
Not insurmountable problems, but it makes using AltiVec harder. You
would have to really justify a speed increase. I think you could get
that on cryptography functions easily. For page zero/copying, I think
you would also get the increase to outweigh the prologue/epilogue
required and also the loss of preemption.
TCP/IP copy with checksum? Probably absolutely definitely..
Straight memcpy? I am not so sure.
Like I said I am far more worried about how you'd get a reasonable
benchmark out of it. Profiling kernels is a messy business..
--
Matt Sealey <[EMAIL PROTECTED]>
Genesi, Manager, Developer Relations
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
