From owner-freebsd-current  Wed Nov  1 19:09:35 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id TAA08699
          for current-outgoing; Wed, 1 Nov 1995 19:09:35 -0800
Received: from ast.com (irvine.ast.com [165.164.128.2])
          by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id TAA08693
          for <current@FreeBSD.org>; Wed, 1 Nov 1995 19:09:30 -0800
Received: from fw.ast.com by ast.com with SMTP id AA21092
  (5.67b/IDA-1.5 for <current@FreeBSD.org>); Wed, 1 Nov 1995 19:10:40 -0800
Received: from nemesis by fw.ast.com with uucp
	(Smail3.1.29.1 #4) id m0tApXu-00008GC; Wed, 1 Nov 95 20:38 CST
Received: by nemesis.lonestar.org (Smail3.1.27.1 #19)
	id m0tApWM-000IvyC; Wed, 1 Nov 95 20:36 WET
Message-Id: <m0tApWM-000IvyC@nemesis.lonestar.org>
Date: Wed, 1 Nov 95 20:36 WET
To: current@FreeBSD.org
From: uhclem%nemesis@fw.ast.com (Frank Durda IV)
Sent: Wed Nov  1 1995, 20:36:50 CST
Subject: Re: Time problems
Sender: owner-current@FreeBSD.org
Precedence: bulk

[3]Bruce Evans <bde@zeta.org.au> writes:
[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.

Execution Time is no longer linear....   :-)

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.

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
place a timing delta between IN/OUT instructions, it probably won't do
the job *consistently*.  It can vary on a given processor depending
on which IU was available on entry to the routine at a given instant.  Yucky.

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.


See the Pentium songbook for less information on how to deal with this
issue.

Frank Durda IV <uhclem@nemesis.lonestar.org>|"The Knights who say "LETNi"
or uhclem%nemesis@fw.ast.com (Fastest Route)| demand...  A SEGMENT REGISTER!!!"
...letni!rwsys!nemesis!uhclem               |"A what?"
...decvax!fw.ast.com!nemesis!uhclem         |"LETNi! LETNi! LETNi!"  - 1983