Messages in this thread |  | | Date | Sun, 2 Feb 1997 18:59:46 -0500 | From | "David S. Miller" <> | Subject | Re: 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 /_____________/ / // /_/ ><
|  |