Date: Fri, 3 Nov 1995 07:41:19 +1100 From: Bruce Evans <bde@zeta.org.au> To: current@FreeBSD.ORG, uhclem%nemesis@fw.ast.com Subject: Re: Time problems Message-ID: <199511022041.HAA02262@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>[3]Perhaps the 8254 clock is being accessed too fast. Try adding some delays >[3]before each inb() and outb() in clock.c:getit(). Count to 100 or so to >[3]get at least 1 usec delay. >Uh, I don't think this will work as you expect on a Pentium or a P6. It is >too easy for the parallel integer unit(s) to execute the inb/outbs in one >unit and do the nice delay loop in the other, thus wrecking your timing delay. >On the Pentium and up you must force these types of "timed" instruction >sequences to be done sequentially. It worked :-). Perhaps the compiler allocated the same register for the loop counter as for the inb. But even if the same register is, used, there's nothing to stop the following optimization: movl $1000,%eax 1: decl %eax jne 1b inb $0x43,%al to: unit 1 unit 2 ------ ------ movl $1000000,%eax inb $0x43,%hiddenreg 1: decl %eax /* stall */ jne 1b /* stall */ movl %hiddenreg,%al except that a lot of code might break. >I am chasing a bug in the printer driver (-STROBE pulse timing is out of spec) >as we write that is probably caused by someone assuming that *all* the >instructions would execute in the order they were coded. Not anymore. I/O instructions must be executed sequentially. Someone assumed that back to back i/o instructions take longer than than 0.5 usec. They do take much longer than that for 8MHz ISA buses, and code to check whether a further delay is necessary would make ISA systems even slower. >In *general* you are guaranteed that IN and OUT instructions will generate >-IOR and -IOW cycles in the order they were coded, but any code that has no >dependencies/effects on the IN/OUT opcodes can be executed out of order in >relation to the IN/OUT opcodes. So if the purpose of that code is to I think ordering is guaranteed for i/o to uncached memory too. >If the inbs and outbs were actually calls to inbs and outbs rather >than being inline, the serialization problems tend to go away. At least >on the Pentium. This may not be the case on the P6 and other processors >with multiple execution units. Perhaps both jmp and call synchronize everything? Then the loop would work. I'm also depending on the gcc feature of not optimizing away delay loops. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511022041.HAA02262>