From owner-freebsd-hackers Fri Mar 17 09:42:15 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA00368 for hackers-outgoing; Fri, 17 Mar 1995 09:42:15 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA00362 for ; Fri, 17 Mar 1995 09:42:14 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA29024; Fri, 17 Mar 95 10:36:05 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503171736.AA29024@cs.weber.edu> Subject: Re: DELAY() To: gibbs@estienne.CS.Berkeley.EDU (Justin T. Gibbs) Date: Fri, 17 Mar 95 10:36:04 MST Cc: hackers@FreeBSD.org In-Reply-To: <199503171033.CAA14976@estienne.cs.berkeley.edu> from "Justin T. Gibbs" at Mar 17, 95 02:33:34 am X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > Does anyone have an alternate implementation idea for DELAY so that it > is cpu/bus independant? I think this is relatively impossible without using timers to do the work. The ability to do this is limited by your timer resolution and the firing/rescheduling overhead, so it would not be suitable for spins below a certain (TBD) duration. This will probably become more of an issue in porting to non-strictly PC architectures. SMP will cause it to be a big issue, as will the use of spins on some bus architectures intefering with the ability to deliver interrupts (message passing buses... ie: Sequent, Nothern Telecom). This is a "bite the bullet later" issue. As a workaround for non-complex (PC) architectures, you may want to look at calibrated delay loops. These are discussed in "The Undocumented PC" in implementing reliable keyboard I/O not using the BIOS. The Linux kernel uses a calibrated loop for its DELAY mechanism (it even spits out a calibration message while booting). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.