lkml.org 
[lkml]   [1997]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: MMX stuff..
   Date: 	Sun, 2 Feb 1997 15:47:08 -0800 (PST)
From: Zach <zab@grumblesmurf.net>

i might be understanding things wrong, but i thought it only did a fpu
load/restore when a task tried to use the fpu and someone else had used it
more recently. isn't there a specific exception for using the floating
point when it wasn't your turn so you don't have to do it with every
context switch?

Yes the kernel has to save it somewhere to use it all the time like
this.

but you're right on some level.. if you had a process doing mmx and fpu
things at the same time, things get real ugly. i think having two
different processes, one doing fpu and one doing mmx would be the same as
having two doing fpu.

On the UltraSparc saving all 64 FPU registers costs two instructions,
it only makes sense when the amount to copy has a length over some
threashold. Typically this is around 256 bytes or so. The gains are
enormous, you get 64 bytes per store (this is RISC remember) and these
special floating point register block load/store instructions gets the
maximum possible bus bandwidth the processor can ever achieve.

The UltraSparc has some funky bit manipulation and other weird
instructions for image processing that go along side with these block
loads and stores, I haven't figure out a way to do IP checksums with
them yet, but I'm sure I'll come up with something. ;-)

---------------------------------------------////
Yow! 11.26 MB/s remote host TCP bandwidth & ////
199 usec remote TCP latency over 100Mb/s ////
ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ ><
\
 
 \ /
  Last update: 2005-03-22 13:38    [from the cache]
©2003-2011 Jasper Spaans