From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:33578)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Paul_Brook@mentor.com>) id 1RzpOO-0006q3-RG
	for qemu-devel@nongnu.org; Tue, 21 Feb 2012 08:04:33 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Paul_Brook@mentor.com>) id 1RzpON-0001rX-Mu
	for qemu-devel@nongnu.org; Tue, 21 Feb 2012 08:04:28 -0500
Received: from relay1.mentorg.com ([192.94.38.131]:63935)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Paul_Brook@mentor.com>) id 1RzpON-0001r3-Fp
	for qemu-devel@nongnu.org; Tue, 21 Feb 2012 08:04:27 -0500
From: Paul Brook <paul@codesourcery.com>
Date: Tue, 21 Feb 2012 13:04:17 +0000
References: <cover.1329702076.git.peter.crosthwaite@petalogix.com>
	<4468eade8e51e235bc98a60b926e1e6a5657c5aa.1329702076.git.peter.crosthwaite@petalogix.com>
	<CAFEAcA94=MZxFhh3b-H8vMrcMOq2qsmiO_w2EjGT0vLpr3CjAQ@mail.gmail.com>
In-Reply-To: <CAFEAcA94=MZxFhh3b-H8vMrcMOq2qsmiO_w2EjGT0vLpr3CjAQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201202211304.18584.paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH v6 2/4] cadence_ttc: initial version of
	device model
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: monstr@monstr.eu, qemu-devel@nongnu.org, John Linn <john.linn@xilinx.com>, "Peter A. G. Crosthwaite" <peter.crosthwaite@petalogix.com>, duyl@xilinx.com, linnj@xilinx.com, edgar.iglesias@gmail.com, afaerber@suse.de, john.williams@petalogix.com

> > +static inline int64_t is_between(int64_t x, int64_t a, int64_t b)
> > +{
> > +    if (a < b) {
> > +        return x > a && x <= b;
> > +    }
> > +    return x < a && x >= b;
> > +}
> 
> This looks slightly odd -- should the boundary condition for whether
> a value equal to the max/min really change depending on :whether a
> or b is greater?

This is a ugly hack.  Instead of figuring out whether we have a count-up or 
count-down timer the code checks for both, and have the "in_between" function 
magically DTRT.  I haven't followed the paths through in enough detail to 
figure out whether it gets all the corner cases right.

Paul