Re: [2637] 2009-10-16 Colin Watson <cjwatson@ubuntu.com>

Re: [2637] 2009-10-16 Colin Watson <cjwatson@ubuntu.com>

[Robert Millan]

On Fri, Oct 16, 2009 at 03:38:44PM +0000, Colin Watson wrote:
> Revision: 2637
>           http://svn.sv.gnu.org/viewvc/?view=rev&root=grub&revision=2637
> Author:   cjwatson
> Date:     2009-10-16 15:38:42 +0000 (Fri, 16 Oct 2009)
> Log Message:
> -----------
> 2009-10-16  Colin Watson  <cjwatson@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."

Re: [2637] 2009-10-16 Colin Watson <cjwatson@ubuntu.com>

[Vladimir 'phcoder' Serbinenko]

Robert Millan wrote:
> On Fri, Oct 16, 2009 at 03:38:44PM +0000, Colin Watson wrote:
>   
>> Revision: 2637
>>           http://svn.sv.gnu.org/viewvc/?view=rev&root=grub&revision=2637
>> Author:   cjwatson
>> Date:     2009-10-16 15:38:42 +0000 (Fri, 16 Oct 2009)
>> Log Message:
>> -----------
>> 2009-10-16  Colin Watson  <cjwatson@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 

Re: [2637] 2009-10-16 Colin Watson <cjwatson@ubuntu.com>

[richardvoigt]

On Sat, Oct 17, 2009 at 6:40 AM, Vladimir 'phcoder' Serbinenko
<phcoder@gmail.com> wrote:
> Robert Millan wrote:
>> On Fri, Oct 16, 2009 at 03:38:44PM +0000, Colin Watson wrote:
>>
>>> Revision: 2637
>>>           http://svn.sv.gnu.org/viewvc/?view=rev&root=grub&revision=2637
>>> Author:   cjwatson
>>> Date:     2009-10-16 15:38:42 +0000 (Fri, 16 Oct 2009)
>>> Log Message:
>>> -----------
>>> 2009-10-16  Colin Watson  <cjwatson@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
>

Re: [2637] 2009-10-16 Colin Watson <cjwatson@ubuntu.com>

[Robert Millan]

On Sat, Oct 17, 2009 at 11:09:28AM -0500, richardvoigt@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."