From owner-freebsd-current Wed Jun 10 23:29:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA03249 for freebsd-current-outgoing; Wed, 10 Jun 1998 23:29:40 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles69.castles.com [208.214.165.69]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA03244 for ; Wed, 10 Jun 1998 23:29:38 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id WAA01035; Wed, 10 Jun 1998 22:24:47 -0700 (PDT) Message-Id: <199806110524.WAA01035@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Luigi Rizzo cc: mike@smith.net.au (Mike Smith), current@FreeBSD.ORG Subject: Re: floating point usage within the kernel - howto ? In-reply-to: Your message of "Thu, 11 Jun 1998 06:43:08 +0200." <199806110443.GAA21849@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Jun 1998 22:24:46 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > a local user has a need to do some Floating Point computations within > > > the kernel. I think this is not possible without explicitly > .... > > The simple answer is "don't do it". You might try '-msoft-float' as a > > compiler option, but it'd be better just to come up with a fixed-point > > or manually-coded floating point implementation. > > > > What do they want to do FP in the kernel for anyway? > > they want to run a P-I-D controller (and more generic controllers > if this goes well) to control a few motors, for didactical purposes. > > The used to do the same thing under DOS, by hooking this 'real-time' > task to the timer interrupt. I am trying to push them to use FreeBSD > (and an LKM for this module) so that they can easily access the > controller across the network or via the web, use high level stuff > for visualization, etc. A worthy goal. They're not interested in using a "real" motor controller card? > For sure they can do fixed point, but if i can find a solution for > 'save_fp_regs()/restore_fp_regs()' this might have other uses as well. The problem is mostly just one of dealing with the FP context switch; at the moment it's done in a lazy fashion taking advantage of the trap handler. You'd have to ensure there was an FP context to save into all the time, and deal with taking a fault in the kernel to swap contexts. IMHO, you'd be better of with them using rtprio() and running the control applicaton in user-space, especially if they were previously using the 18Hz timer resolution. It doesn't sound like anything other than the hardware access needs to be in the kernel at all. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message