Skip site navigation (1)Skip section navigation (2)
Date:      04 Apr 98 13:31:31 +0330
From:      "Muthu" <MOLAGAPP.IN.oracle.com.ofcmail@in.oracle.com>
To:        hackers@FreeBSD.ORG
Subject:   Re: bcopy implementation
Message-ID:  <199804040943.EAA12300@dwarpal.in.oracle.com>

next in thread | raw e-mail | index | archive | help

--=_ORCL_2860996_0_11919804041414580
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="us-ascii"

Hi, 
 
    I looked into code of saving the fpu resigers during context switch.  A 
variable npxproc is used for comparision with curproc. If two variables are 
equal, the saving of fpu resiters happens in context switch. Assume, process A 
uses fpu instructions, hence it generates dna interrupt since TS bit is set. 
The ISR routine npxdna() sets the npxproc to curproc. Now if the process A 
does a context switch, it compares the npxproc with curproc and since it is 
equal, the saving of fpu happens. Thus no delayed saving happens in current 
implementation. 
 
    I am thinking like saving fpu registers in npxdna() code. Here check if 
npxproc is equal to curproc, then save the fpu registers in npxproc pcb 
structures. This also saves storing and restoring of fpu registers if no other 
process except process A (just one more process) uses fpu registers. 
 
    Please comment on this kind of implementation. I think this will certainly 
save the time in context switch also. 
 
 
Regards, 
 
Muthu. O.L.

--=_ORCL_2860996_0_11919804041414580
Content-Type:message/rfc822

Date: 04 Apr 98 03:41:45
From:"Terry Lambert <tlambert@primenet.com>" <owner-freebsd-hackers@FreeBSD.ORG>
To:sbabkin@dcn.att.com
Subject:Re: bcopy implementation
Cc:karpen@ocean.campus.luth.se,nate@mt.sri.com,marquard@zilker.net,freebsd-hackers@FreeBSD.ORG
Received:from inet-user-gw-1.us.oracle.com by insun023 with ESMTP (SMI-8.6/37.8) id TAA13118; Fri, 3 Apr 1998 19:33:23 -0500
Received:from smyrno.sol.net (mail@smyrno.sol.net [206.55.64.117]) by inet-user-gw-1.us.oracle.com (8.8.5/8.8.5) with ESMTP id QAA23280 for <MOLAGAPP.IN.oracle.com.ofcmail@in.oracle.com>; Fri, 3 Apr 1998 16:38:09 -0800 (PST)
Received:from hub.freebsd.org (hub.FreeBSD.ORG [204.216.27.18]) by smyrno.sol.net (8.8.8/8.8.8/SNNS-1.02) with ESMTP id SAA02521; Fri, 3 Apr 1998 18:15:26 -0600 (CST)
Received:from localhost (daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA03502; Fri, 3 Apr 1998 16:15:25 -0800 (PST) (envelope-from owner-freebsd-hackers)
Received:by hub.freebsd.org (bulk_mailer v1.6); Fri, 3 Apr 1998 16:12:04 -0800
Received:(from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02834 for freebsd-hackers-outgoing; Fri, 3 Apr 1998 16:12:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received:from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA02796 for <freebsd-hackers@FreeBSD.ORG>; Fri, 3 Apr 1998 16:11:58 -0800 (PST) (envelope-from tlambert@usr06.primenet.com)
Received:(from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA21897; Fri, 3 Apr 1998 17:11:57 -0700 (MST)
Received:from usr06.primenet.com(206.165.6.206) via SMTP by smtp01.primenet.com, id smtpd021861; Fri Apr  3 17:11:49 1998
Received:(from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id RAA12763; Fri, 3 Apr 1998 17:11:45 -0700 (MST)
Message-Id:<199804040011.RAA12763@usr06.primenet.com>
In-Reply-To:<C50B6FBA632FD111AF0F0000C0AD71EEACDE91@dcn71.dcn.att.com> from "sbabkin@dcn.att.com" at Apr 3, 98 11:27:37 am
X-Mailer:ELM [version 2.4 PL25]
Sender:owner-freebsd-hackers@FreeBSD.ORG
X-Loop:FreeBSD.ORG
MIME-Version: 1.0
Content-Transfer-Encoding:7bit
Content-Type:text/plain; charset="us-ascii"

> > People seem to be forgetting that since bcopy isn't a system call,
> > it's
> > possible to royally screw yourself up with it, since it uses the FP
> > registers.
> > 
> > So, one program could be in the middle of doing a bcopy, and a second
> > program could interrupt it, and spam the registers of the previous
> > program, so that when the first was resume it's results are totally
> > bogus.
> > 
> Huh ? The floating point registers must be saved as part of
> context or else no program using them will work properly.

However, they need not be switched at context switch time.

Specifically, the reason for saving FP context is for exception
signalling.

You can "lasy bind" the FP context, such that you only unload the
registers if another guy wants to use them.  This is, in fact,
what FreeBSD does.

This saves overhead on context switches.  Only those apps using
the registers have to take the hit.

Signals do not save FP registers at all.

You should also look at the setjmp/longjmp manual pages; there are
FP saving equivalents.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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

--=_ORCL_2860996_0_11919804041414580--


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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804040943.EAA12300>