Re: APIC, AMD-K6/2 -mcpu=586...
> "JAM" == J A Magallon <[EMAIL PROTECTED]> writes: JAM> That is not the problem. The problem is that the registers have JAM> to lay in a defined way, transcribed to a C struct, and that JAM> pgcc lays badly that struct. WJP> Yes, I understand that. I was showing a way to find the value WJP> of padding needed to align the register store in the structure. WJP> Perhaps I should have shown a mod to asm/processor.h, [snip] WJP> I was describing a way to make things independent of the WJP> compiler layout of the structs. However, this complicates the WJP> build process, and people might not like the padding due to WJP> cache alignment details. Sorry, they would obviously declare it as such if the kernel developers wanted to. /* floating point info */ unsigned char fpAlign[0] __attribute__ ((aligned (16))); union i387_unioni387; This is a much simpler way of achieving what I was trying to explain previously. I think that this syntax has been in the GCC extensions for some time. regards, Bill Pringlemeir. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC, AMD-K6/2 -mcpu=586...
On 05.18 Bill Pringlemeir wrote: >> Why don't the build scripts run a dummy file to determine where >> the floating point registers should be placed? >> >> ... const int value = offsetof(struct task_struct, >> thread.i387.fxsave) & 15; ... > "JAM" == J A Magallon <[EMAIL PROTECTED]> writes: JAM> That is not the problem. The problem is that the registers have JAM> to lay in a defined way, transcribed to a C struct, and that JAM> pgcc lays badly that struct. Yes, I understand that. I was showing a way to find the value of padding needed to align the register store in the structure. Perhaps I should have shown a mod to asm/processor.h, ... /* floating point info */ #if PAD_SIZE /* not needed if gcc accepts zero size arrays? */ unsigned char fpAlign[PAD_SIZE]; #endif union i387_unioni387; ... Before compiling the `real source', the dummy file would be compiled with PAD_SIZE set to zero. Then objdump (or some other tool) can find out what the value is. Then when the task_struct is compiled in the kernel, PAD_SIZE is set to the appropriate value to align the structure. I was describing a way to make things independent of the compiler layout of the structs. However, this complicates the build process, and people might not like the padding due to cache alignment details. I am pretty sure what I am saying works... It might not be right though. regards, Bill Pringlemeir. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC, AMD-K6/2 -mcpu=586...
On 05.18 Bill Pringlemeir wrote: > > Why don't the build scripts run a dummy file to determine where the > floating point registers should be placed? > > ... > const int value = offsetof(struct task_struct, thread.i387.fxsave) & 15; > ... > That is not the problem. The problem is that the registers have to lay in a defined way, transcribed to a C struct, and that pgcc lays badly that struct. -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.4-ac11 #2 SMP Fri May 18 12:27:06 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC, AMD-K6/2 -mcpu=586...
> "WJP" == Bill Pringlemeir <[EMAIL PROTECTED]> writes:
[snip]
WJP> I have the 2.4.4 distribution from kernel.org.
WJP> "http://www.kernel.org/pub/linux/kernel/v2.4/;
WJP> I have a Mandrake system and selected the AMD processors and
WJP> APIC option. The egcs-2.91.66 compiler with -mcpu=586. It
WJP> appears that the structure alignment of the floating point
Sorry,
I compiled from a user account and `/usr/bin' was before
`/usr/local/bin' on my path. I had actually installed the tools as
per Documentation/Changes, honest! I was compiling with the
pgcc-2.91.66 and not egcs-2.91.66. The root account was set up to use
egcs-2.91.66.
Why don't the build scripts run a dummy file to determine where the
floating point registers should be placed?
...
const int value = offsetof(struct task_struct, thread.i387.fxsave) & 15;
...
VAL = objdump --all-headers foo.o | grep value | cut -c 48-57
PAD_SIZE = objdump --start-address=$VAL --disassemble-all foo.o | cut...
Or perhaps some better method for determining the offset on the host,
Compiling and execute won't work in cross development mode...
int main(){return offsetof(struct task_struct, thread.i387.fxsave) & 15;}
Perhaps this is a bit much to demand, instead of having a specific
compiler.
fwiw,
Bill Pringlemeir.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
APIC, AMD-K6/2 -mcpu=586...
Hello,
I have the 2.4.4 distribution from kernel.org.
"http://www.kernel.org/pub/linux/kernel/v2.4/;
I have a Mandrake system and selected the AMD processors and APIC
option. The egcs-2.91.66 compiler with -mcpu=586. It appears that
the structure alignment of the floating point registers was not
correct under this configuration. This code was being compiled and
a linker error produced.
if (offsetof(struct task_struct, thread.i387.fxsave) & 15) {
/* printk("WJP: value is %x.\n",
offsetof(struct task_struct, thread.i387.fxsave) & 15); */
/*while(1); */
extern void __buggy_fxsr_alignment(void);
__buggy_fxsr_alignment();
}
The alignment was to 8 bytes instead of 16. I added some padding to
the thread structure to produce an alignment of 16 and the code
compiled and seemed to work fine; I used it for a few days.
[in processor.h]
/* floating point info */
/* unsigned char wjpDummy[8]; */
union i387_unioni387;
I did not see any mention of this in the archives [but the volume of
mailings is large... which I may be contributing to]. I recompiled
without the padding and APIC support and everything seems to be fine,
but _VERY_ slow. Is this change ok locally? Has it been addressed
in a patch?
regards,
Bill Pringlemeir.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
APIC, AMD-K6/2 -mcpu=586...
Hello,
I have the 2.4.4 distribution from kernel.org.
http://www.kernel.org/pub/linux/kernel/v2.4/;
I have a Mandrake system and selected the AMD processors and APIC
option. The egcs-2.91.66 compiler with -mcpu=586. It appears that
the structure alignment of the floating point registers was not
correct under this configuration. This code was being compiled and
a linker error produced.
if (offsetof(struct task_struct, thread.i387.fxsave) 15) {
/* printk(WJP: value is %x.\n,
offsetof(struct task_struct, thread.i387.fxsave) 15); */
/*while(1); */
extern void __buggy_fxsr_alignment(void);
__buggy_fxsr_alignment();
}
The alignment was to 8 bytes instead of 16. I added some padding to
the thread structure to produce an alignment of 16 and the code
compiled and seemed to work fine; I used it for a few days.
[in processor.h]
/* floating point info */
/* unsigned char wjpDummy[8]; */
union i387_unioni387;
I did not see any mention of this in the archives [but the volume of
mailings is large... which I may be contributing to]. I recompiled
without the padding and APIC support and everything seems to be fine,
but _VERY_ slow. Is this change ok locally? Has it been addressed
in a patch?
regards,
Bill Pringlemeir.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: APIC, AMD-K6/2 -mcpu=586...
WJP == Bill Pringlemeir [EMAIL PROTECTED] writes:
[snip]
WJP I have the 2.4.4 distribution from kernel.org.
WJP http://www.kernel.org/pub/linux/kernel/v2.4/;
WJP I have a Mandrake system and selected the AMD processors and
WJP APIC option. The egcs-2.91.66 compiler with -mcpu=586. It
WJP appears that the structure alignment of the floating point
Sorry,
I compiled from a user account and `/usr/bin' was before
`/usr/local/bin' on my path. I had actually installed the tools as
per Documentation/Changes, honest! I was compiling with the
pgcc-2.91.66 and not egcs-2.91.66. The root account was set up to use
egcs-2.91.66.
Why don't the build scripts run a dummy file to determine where the
floating point registers should be placed?
...
const int value = offsetof(struct task_struct, thread.i387.fxsave) 15;
...
VAL = objdump --all-headers foo.o | grep value | cut -c 48-57
PAD_SIZE = objdump --start-address=$VAL --disassemble-all foo.o | cut...
Or perhaps some better method for determining the offset on the host,
Compiling and execute won't work in cross development mode...
int main(){return offsetof(struct task_struct, thread.i387.fxsave) 15;}
Perhaps this is a bit much to demand, instead of having a specific
compiler.
fwiw,
Bill Pringlemeir.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: APIC, AMD-K6/2 -mcpu=586...
On 05.18 Bill Pringlemeir wrote: Why don't the build scripts run a dummy file to determine where the floating point registers should be placed? ... const int value = offsetof(struct task_struct, thread.i387.fxsave) 15; ... That is not the problem. The problem is that the registers have to lay in a defined way, transcribed to a C struct, and that pgcc lays badly that struct. -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.4-ac11 #2 SMP Fri May 18 12:27:06 CEST 2001 i686 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC, AMD-K6/2 -mcpu=586...
On 05.18 Bill Pringlemeir wrote: Why don't the build scripts run a dummy file to determine where the floating point registers should be placed? ... const int value = offsetof(struct task_struct, thread.i387.fxsave) 15; ... JAM == J A Magallon [EMAIL PROTECTED] writes: JAM That is not the problem. The problem is that the registers have JAM to lay in a defined way, transcribed to a C struct, and that JAM pgcc lays badly that struct. Yes, I understand that. I was showing a way to find the value of padding needed to align the register store in the structure. Perhaps I should have shown a mod to asm/processor.h, ... /* floating point info */ #if PAD_SIZE /* not needed if gcc accepts zero size arrays? */ unsigned char fpAlign[PAD_SIZE]; #endif union i387_unioni387; ... Before compiling the `real source', the dummy file would be compiled with PAD_SIZE set to zero. Then objdump (or some other tool) can find out what the value is. Then when the task_struct is compiled in the kernel, PAD_SIZE is set to the appropriate value to align the structure. I was describing a way to make things independent of the compiler layout of the structs. However, this complicates the build process, and people might not like the padding due to cache alignment details. I am pretty sure what I am saying works... It might not be right though. regards, Bill Pringlemeir. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC, AMD-K6/2 -mcpu=586...
JAM == J A Magallon [EMAIL PROTECTED] writes: JAM That is not the problem. The problem is that the registers have JAM to lay in a defined way, transcribed to a C struct, and that JAM pgcc lays badly that struct. WJP Yes, I understand that. I was showing a way to find the value WJP of padding needed to align the register store in the structure. WJP Perhaps I should have shown a mod to asm/processor.h, [snip] WJP I was describing a way to make things independent of the WJP compiler layout of the structs. However, this complicates the WJP build process, and people might not like the padding due to WJP cache alignment details. Sorry, they would obviously declare it as such if the kernel developers wanted to. /* floating point info */ unsigned char fpAlign[0] __attribute__ ((aligned (16))); union i387_unioni387; This is a much simpler way of achieving what I was trying to explain previously. I think that this syntax has been in the GCC extensions for some time. regards, Bill Pringlemeir. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
