altivec

Mike DeSimone Hot-Wire at mail.utexas.edu
Sat Jul 10 10:41:36 EST 1999


>Well, if you do instruction-by-instruction emulation, the iteration count is
>at most 16 (16 bytes in a vector). Furthermore, the overhead of a context
>switch into privileged mode and back again is not negligible (at the very
>least a pipeline flush and some saving/restoring of registers). Finally,
>keeping the emulated vector registers somewhere in memory means that you will
>quite often be limited by the availability of 'only' one load/store unit.

That's true, I forgot about the 16 byte limit.  That will really make the
overhead significant.  Kind of annoying to me (my typical vector length is
over 900).  Maybe having two libraries is the way to go, then...

>> I'm also wondering what has been done on this issue on the Intel side of
>> the fence, since KNI and 3Dnow! are similar to Altivec in concept and, at
>> least for 3Dnow!, implementation.
>>
>Similar? Please forgive my ranting, but AltiVec is feature-complete,
>orthogonal, and implemented without compromises. MMX, 3DNow!, and ISSE have
>none of the above three qualities. They were available sooner, but that's
>about it.

That's why I said "similar in concept" ... not execution.  And I said KNI
(the PIII new instructions), not MMX, which is integers only.  (Also why I
didn't mention Sun's VIS).
_________________________________________________________________________
                                __________
##   ##   ###   #####   #####   \********/   #####    ###    ##### ######
### ###  ## ##  ##  ## ##        \*/\/\*/    ##  ##  ## ##  ##     ##
#######  ## ##  #####   ####       /\/\      #####   ## ##   ####  ####
## # ## ####### ##  ##     ##      \**/      ##  ## #######     ## ##
##   ## ##   ## ##  ## #####        \/       #####  ##   ## #####  ######
_________________________________________________________________________
### Mike DeSimone ### Hot-Wire at mail.utexas.edu ### ares.marsbase.mars ###

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]





More information about the Linuxppc-dev mailing list