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/