Re: [2637] 2009-10-16 Colin Watson cjwat...@ubuntu.com
On Sat, Oct 17, 2009 at 11:09:28AM -0500, richardvo...@gmail.com wrote: mmx/sse/sse2/3dnow because we don't use floating point arithmetics. If I remember correctly sse has some commands for operations on parallel operations on integers but the only place I see where benefit could be considerable is decompression and decryption. If it's proven that For example, memcpy is much faster using those extended instruction sets. Maybe that's not an important use case for grub2 either. We have some code in our loaders that memcpy large chunks of data. Not sure how relevant this is though. Anyhow, I bet our grub_memmove() is still suboptimal in comparison with those on Glibc. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [2637] 2009-10-16 Colin Watson cjwat...@ubuntu.com
On Fri, Oct 16, 2009 at 03:38:44PM +, Colin Watson wrote: Revision: 2637 http://svn.sv.gnu.org/viewvc/?view=revroot=grubrevision=2637 Author: cjwatson Date: 2009-10-16 15:38:42 + (Fri, 16 Oct 2009) Log Message: --- 2009-10-16 Colin Watson cjwat...@ubuntu.com * configure.ac (TARGET_CFLAGS): Add -mno-mmx -mno-sse -mno-sse2 -mno-3dnow on x86 architectures. Some toolchains enable these features by default, but they rely on registers that aren't enabled in GRUB. Thanks to Vladimir Serbinenko for the suggestion. Would it be preferable to enable those registers instead? -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [2637] 2009-10-16 Colin Watson cjwat...@ubuntu.com
Robert Millan wrote: On Fri, Oct 16, 2009 at 03:38:44PM +, Colin Watson wrote: Revision: 2637 http://svn.sv.gnu.org/viewvc/?view=revroot=grubrevision=2637 Author: cjwatson Date: 2009-10-16 15:38:42 + (Fri, 16 Oct 2009) Log Message: --- 2009-10-16 Colin Watson cjwat...@ubuntu.com * configure.ac (TARGET_CFLAGS): Add -mno-mmx -mno-sse -mno-sse2 -mno-3dnow on x86 architectures. Some toolchains enable these features by default, but they rely on registers that aren't enabled in GRUB. Thanks to Vladimir Serbinenko for the suggestion. Would it be preferable to enable those registers instead? They are disabled for following simple reason: imagine an OS which isn't aware of those registers. Then if user simultaneously launches two applications which use those registers then they won't be preserved accross context switches leading to bugs. I don't know if there is a way to disable these registers again after enabling them. I don't think grub2 will benefit a lot because of mmx/sse/sse2/3dnow because we don't use floating point arithmetics. If I remember correctly sse has some commands for operations on parallel operations on integers but the only place I see where benefit could be considerable is decompression and decryption. If it's proven that decompressing/decrypting with SSE makes it considerably faster then enabling SSE would be a good thing. Anyhow for now we can just disable MMX/SSE/SSE2/3dnow and when someone implements handling those registers he can enable them again On FreeBSD kernel itself is compiled without MMX, SSE, SSE2 and 3dnow to avoid to have to handle them on kernel threads switches. -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [2637] 2009-10-16 Colin Watson cjwat...@ubuntu.com
On Sat, Oct 17, 2009 at 6:40 AM, Vladimir 'phcoder' Serbinenko phco...@gmail.com wrote: Robert Millan wrote: On Fri, Oct 16, 2009 at 03:38:44PM +, Colin Watson wrote: Revision: 2637 http://svn.sv.gnu.org/viewvc/?view=revroot=grubrevision=2637 Author: cjwatson Date: 2009-10-16 15:38:42 + (Fri, 16 Oct 2009) Log Message: --- 2009-10-16 Colin Watson cjwat...@ubuntu.com * configure.ac (TARGET_CFLAGS): Add -mno-mmx -mno-sse -mno-sse2 -mno-3dnow on x86 architectures. Some toolchains enable these features by default, but they rely on registers that aren't enabled in GRUB. Thanks to Vladimir Serbinenko for the suggestion. Would it be preferable to enable those registers instead? They are disabled for following simple reason: imagine an OS which isn't aware of those registers. Then if user simultaneously launches two applications which use those registers then they won't be preserved accross context switches leading to bugs. I don't know if there is a way to disable these registers again after enabling them. I don't think grub2 will benefit a lot because of I think this cannot be accurate because virtual machines would be badly broken (registers enabled by the host, guest without awareness is exactly the situation you describe). mmx/sse/sse2/3dnow because we don't use floating point arithmetics. If I remember correctly sse has some commands for operations on parallel operations on integers but the only place I see where benefit could be considerable is decompression and decryption. If it's proven that For example, memcpy is much faster using those extended instruction sets. Maybe that's not an important use case for grub2 either. decompressing/decrypting with SSE makes it considerably faster then enabling SSE would be a good thing. Anyhow for now we can just disable MMX/SSE/SSE2/3dnow and when someone implements handling those registers he can enable them again On FreeBSD kernel itself is compiled without MMX, SSE, SSE2 and 3dnow to avoid to have to handle them on kernel threads switches. -- Regards Vladimir 'phcoder' Serbinenko Personal git repository: http://repo.or.cz/w/grub2/phcoder.git ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
