From owner-freebsd-arch  Thu Jan  4  9: 9: 1 2001
From owner-freebsd-arch@FreeBSD.ORG  Thu Jan  4 09:08:59 2001
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from beastie.mckusick.com (beastie.mckusick.com [209.31.233.184])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9474C37B400; Thu,  4 Jan 2001 09:08:58 -0800 (PST)
Received: from beastie.mckusick.com (localhost [127.0.0.1])
	by beastie.mckusick.com (8.9.3/8.9.3) with ESMTP id JAA05731;
	Thu, 4 Jan 2001 09:08:47 -0800 (PST)
	(envelope-from mckusick@beastie.mckusick.com)
Message-Id: <200101041708.JAA05731@beastie.mckusick.com>
To: Alfred Perlstein <bright@wintelcom.net>
Subject: Re: Reinstatement of CIRCLEQ 
Cc: Will Andrews <will@physics.purdue.edu>,
	Peter Wemm <peter@netplex.com.au>,
	Stephen McKay <mckay@thehub.com.au>, phk@FreeBSD.ORG,
	arch@FreeBSD.ORG
In-Reply-To: Your message of "Thu, 04 Jan 2001 00:19:43 PST."
             <20010104001943.T292@fw.wintelcom.net> 
Date: Thu, 04 Jan 2001 09:08:47 -0800
From: Kirk McKusick <mckusick@mckusick.com>
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

	Date: Thu, 4 Jan 2001 00:19:43 -0800
	From: Alfred Perlstein <bright@wintelcom.net>
	To: Kirk McKusick <mckusick@mckusick.com>
	Subject: Re: Reinstatement of CIRCLEQ
	In-Reply-To: <200101040719.XAA04872@beastie.mckusick.com>;
	    from mckusick@mckusick.com on Wed, Jan 03, 2001 at 11:19:02PM -0800

	You're right, I'm wondering though, would it be possible
	to change TAILQ_PREV(elm, headname, field) to TAILQ_PREV(elm,
	field) by using the offset of 'field' into the struct?
	You could subtract the offset of 'field' from the tqe_prev
	of the next struct right?

	This would also reduce it by one memory access.

	Or is this the unportability/headache you were trying to avoid?

	-Alfred

You are correct that your suggested change is exactly the
unportability/headache that I am trying to avoid. Further,
the current code detects the end-condition (reaching the 
head of the list in the case of TAILQ_PREV or an empty list
in the case of TAILQ_LAST) with no conditional code. That is,
after the two indirections, the pointer will be null in the
above cases; it is not necessary to put in a check for the
end condition in the above macros. Using your technique
would require adding a condition. On our increasingly
pipelined machines these days, avoiding conditional code
is generally a win. Note that the lower performance of
CIRCLEQ's was that they needed conditional tests in the
traversal macros to detect end conditions.

	Kirk McKusick


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message