Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!news.ececs.uc.edu!newsfeeds.sol.net!hammer.uoregon.edu!news.mathworks.com!uunet!in3.uu.net!199.171.20.9!news.nkn.net!news.panther.net!nemesis!uhclem From: uhclem@nemesis.lonestar.org (Frank Durda IV) Subject: Re: Intel MMX compatibility? X-Newsreader: TIN [version 1.2 PL2] Organization: The Big Blue Box Message-ID: <E46q56.7p8@nemesis.lonestar.org> References: <32DE440B.41C67EA6@jnet.vi> <32DF4CE9.6D3D@metrosol.demon.co.uk> Date: Sat, 18 Jan 1997 03:39:06 GMT Lines: 53 Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:34173 John Lucas wrote: > > I am about to order 2 new P5-200 machines to run FreeBSD. Is there any > experience out there in using the new MMX technology CPUs with FreeBSD? > > If I don't hear otherwise I will order CPUs without MMX to be on the > safe side, but I would like to take advantage of the larger on-chip > cache on the new CPU. Steve Gailey (steveg@metrosol.demon.co.uk) wrote: : As I understand it, the new MMX technology is just some new instructions : in the CPU specifically useful to graphics. This technology, providing : it doesn't introduce new bugs into the die shouldn't break anything. : The new instructions are only of use if your software knows how to use : them. I would get the MMX versions, you may wan't it in the future. Actually, the MMX opcodes share the register section used by Floating Point operations and the processor must be explicitly set to be doing floating point or be doing MMX. The contents of the FP register set on Intel MMX implementations gets scrambled when you change between floating and MMX modes (so their manuals claim), and the change from one mode to the other takes 50 clocks (expensive). You are supposed to "avoid" writing apps that try to use both floating point and MMX opcodes. Clearly Intel never heard of multi-tasking operating systems where you have no control over what opcodes executed before and after your time slice. The Cyrix MMX implementation is a bit better, using two sets of unique registers that are mapped in and out of the floating point register area, so changing modes only costs one clock. Saving and restoring this new processor state will be something the kernel must take care of, so that the processor is in the same mode (and same register content) that it was in when you lost your time slice or got interrupted, and I assume this additional code does not exist in any currently-released version of FreeBSD. The GCC compiler may also have to learn a few new things to avoid doing to avoid trashing the FP/MMX register space. Hopefully someone taking care of floating point/MMX kernel issues will speak up and say where things are on this. For now, so long as your code (and none of the code run by any user on your system) doesn't kick the processor into MMX mode, it should stay in floating point mode and work fine. Frank Durda IV <uhclem@nemesis.lonestar.org>|"The Knights who say "LETNi" or uhclem%nemesis@rwsystr.nkn.net | demand... A SEGMENT REGISTER!!!" |"A what?" or ...letni!rwsys!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983