I've been looking at various -ac patches for the last couple of
weeks and have been wondering why only this piece of difference
still remains between Linus' 2.4.2 and Alan's -ac2. All the other
diffs in i387.c from 2.4.1-ac2 seem to have been merged into Linus
tree at around 2.4.2-pre1. Could anybody explain it for me please?
--- linux.vanilla/arch/i386/kernel/i387.c Thu Feb 22 09:05:35 2001
+++ linux.ac/arch/i386/kernel/i387.c Sun Feb 4 10:58:36 2001
@@ -179,7 +179,7 @@
unsigned short get_fpu_mxcsr( struct task_struct *tsk )
{
- if ( cpu_has_fxsr ) {
+ if ( cpu_has_xmm ) {
return tsk->thread.i387.fxsave.mxcsr;
} else {
return 0x1f80;
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
Followup to: <[email protected]>
By author: "Quim K Holland" <[email protected]>
In newsgroup: linux.dev.kernel
>
> I've been looking at various -ac patches for the last couple of
> weeks and have been wondering why only this piece of difference
> still remains between Linus' 2.4.2 and Alan's -ac2. All the other
> diffs in i387.c from 2.4.1-ac2 seem to have been merged into Linus
> tree at around 2.4.2-pre1. Could anybody explain it for me please?
>
> --- linux.vanilla/arch/i386/kernel/i387.c Thu Feb 22 09:05:35 2001
> +++ linux.ac/arch/i386/kernel/i387.c Sun Feb 4 10:58:36 2001
> @@ -179,7 +179,7 @@
>
> unsigned short get_fpu_mxcsr( struct task_struct *tsk )
> {
> - if ( cpu_has_fxsr ) {
> + if ( cpu_has_xmm ) {
> return tsk->thread.i387.fxsave.mxcsr;
> } else {
> return 0x1f80;
>
IMO, XMM is correct here; FXSR is incorrect. Linus?
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
"H. Peter Anvin" wrote:
>
> Followup to: <[email protected]>
> By author: "Quim K Holland" <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > I've been looking at various -ac patches for the last couple of
> > weeks and have been wondering why only this piece of difference
> > still remains between Linus' 2.4.2 and Alan's -ac2. All the other
> > diffs in i387.c from 2.4.1-ac2 seem to have been merged into Linus
> > tree at around 2.4.2-pre1. Could anybody explain it for me please?
> >
> > --- linux.vanilla/arch/i386/kernel/i387.c Thu Feb 22 09:05:35 2001
> > +++ linux.ac/arch/i386/kernel/i387.c Sun Feb 4 10:58:36 2001
> > @@ -179,7 +179,7 @@
> >
> > unsigned short get_fpu_mxcsr( struct task_struct *tsk )
> > {
> > - if ( cpu_has_fxsr ) {
> > + if ( cpu_has_xmm ) {
> > return tsk->thread.i387.fxsave.mxcsr;
> > } else {
> > return 0x1f80;
> >
>
> IMO, XMM is correct here; FXSR is incorrect. Linus?
I sent Linus a patch that changed that to xmm (along with the same in another
place or two, where needed). Linus I guess dropped that one line out of the
patch while Alan kept it. That's the reason for the difference. As to the
correctness, the mxcsr register really only exists if you have xmm, so the xmm
is the correct test. However, the memory location in the fxsr structure was
reserved by the time the fxsr was put together, so the worst this does is give
an undefined mxcsr value on machines where mxcsr doesn't exist, which is why I
didn't yell too loudly when Linus dropped that line out. User space
programmers should be checking for xmm capability themselves before ever
paying attention to mxcsr anyway, so it's not an end of the world error.
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
>>>>> "DL" == Doug Ledford <[email protected]> writes:
>> > --- linux.vanilla/arch/i386/kernel/i387.c Thu Feb 22 09:05:35 2001
>> > +++ linux.ac/arch/i386/kernel/i387.c Sun Feb 4 10:58:36 2001
>> > @@ -179,7 +179,7 @@
>> >
>> > unsigned short get_fpu_mxcsr( struct task_struct *tsk )
>> > {
>> > - if ( cpu_has_fxsr ) {
>> > + if ( cpu_has_xmm ) {
>> > return tsk->thread.i387.fxsave.mxcsr;
>> > } else {
>> > return 0x1f80;
>> >
DL> As to the correctness, the mxcsr register really only exists
DL> if you have xmm, so the xmm is the correct test. However,...
DL> ... User space programmers should be checking for xmm
DL> capability themselves before ever paying attention to mxcsr
DL> anyway, so it's not an end of the world error.
If that is the case, wouldn't it be simpler to always return
tsk->thread.i387.fxsave.mxcsr from this function, and initialize
that field to 0x1f80 (whatever that magic number means) when
the structure is built?
------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/
Quim K Holland wrote:
>
> DL> As to the correctness, the mxcsr register really only exists
> DL> if you have xmm, so the xmm is the correct test. However,...
>
> DL> ... User space programmers should be checking for xmm
> DL> capability themselves before ever paying attention to mxcsr
> DL> anyway, so it's not an end of the world error.
>
> If that is the case, wouldn't it be simpler to always return
> tsk->thread.i387.fxsave.mxcsr from this function, and initialize
> that field to 0x1f80 (whatever that magic number means) when
> the structure is built?
>
No, because the CPU *may* overwrite it when you do an FXSAVE.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt