>
> I'd ask especially the udelay people to verify that this actually _does_
> make a difference on those machines where udelay used to fluctuate - I
> haven't got access to any such machine.
looks good (just compiling, so testing will take some time).
if the kernel is compiled for i386 (e.g. for binary distributions)
ENTRY() gets aligned to 4 bytes. this can result in different BogoMips ratings
for different i386 kernels for these CPUs.
while this is no technical problem since all all delays within one
kernel image are consistent and exact, this disturb some users.
what about adding an explixit alignment to avoid these worries using
--- linux/arch/i386/lib/delay.S~ Tue Sep 23 11:41:39 1997
+++ linux/arch/i386/lib/delay.S Tue Sep 23 12:12:23 1997
@@ -5,6 +5,7 @@
* varying results depending on the exact alignment.
*/
+ .align 16,0x90
ENTRY(__do_delay)
1: decl %eax
jns 1b
btw: what are the exact rules for consecutive .align's ?
when trying what happens for the above code I noticed that
using gcc-2.7.2.1 the following two routines generate
different object code:
ENTRY(foo)
decl %eax
.align 4,0x90
.align 16,0x90
decl %ebx
ret
ENTRY(bar)
decl %eax
.align 16,0x90
.align 4,0x90
decl %ebx
ret
which results in
<foo>: decl %eax
<foo+1>: leal 0x0(%esi),%esi
<foo+4>: leal 0x0(%esi),%esi
<foo+10>: leal 0x0(%edi),%edi
<foo+16>: decl %ebx
<foo+17>: ret
and
<bar>: decl %eax
<bar+1>: jmp 0x40 <bar+16>
<bar+3>: nop
<bar+4>: nop
<bar+5>: nop
<bar+6>: nop
<bar+7>: nop
<bar+8>: nop
<bar+9>: nop
<bar+10>: nop
<bar+11>: nop
<bar+12>: nop
<bar+13>: nop
<bar+14>: nop
<bar+15>: nop
<bar+16>: decl %ebx
<bar+17>: ret
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^