All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <fray@mvista.com>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>,
	linuxppc-dev@lists.linuxppc.org
Subject: Re: giving up the FPU, MSR[FE0], MSR[FE1], and the FPSCR
Date: Fri, 29 Jun 2001 16:03:12 -0500	[thread overview]
Message-ID: <3B3CED10.D05BBE56@mvista.com> (raw)
In-Reply-To: 3B3C9BC6.9AD7C208@mvista.com


>> Lazy FPU initialization IMHO is a good thing for single purpose
>> (embedded?) systems that are on a high end CPU, but do not need floating
>> point.  One example could be a signal processing system that uses
>> altivec and integer math heavily, but no floating point.

>Your non-FP code might seem a wee bit better, but your FP code
>ends up taking faults. Then with all the extra code, we end up
>with extra problems -- for example the original poster's trouble.

Maybe I missed something here, but my understanding is that if you in
SMP lazy initialization never happens.  And if you are single CPU you
take _ONE_ fault per process.

One FP fault per process seems very minor to me, (unless of course you
are spawning a hell of a lot of process, but most likely the process
spawn time would outweigh the single fault.)

>I suppose, if one does want lazy FP save/restore, that it ought
>to be done with a per-process flag to prevent frequent faults.
>When switching to an FP process, restore the registers. From time
>to time take away the FP registers to deal with processes that
>only use them once in a great while or only at startup. Maybe
>take away FP after 1, 2, 4, 8, 16... ticks of use.

That might be of some value, but I'd be concerned that instead of 1
fault per process we could run in to a lot of faults, or into a
situation where each process would need some type of a counter to detect
faults.  (Probably messy...)

--Mark Hatle
MontaVista Software, Inc.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  parent reply	other threads:[~2001-06-29 21:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-29 15:16 giving up the FPU, MSR[FE0], MSR[FE1], and the FPSCR Mark Hatle
2001-06-29 18:29 ` Albert D. Cahalan
2001-06-29 21:03 ` Mark Hatle [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-06-28 22:32 Albert D. Cahalan
2001-06-26 14:10 Gary Byers
2001-07-07  1:07 ` Paul Mackerras
2001-07-09 17:41   ` Dan Malek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B3CED10.D05BBE56@mvista.com \
    --to=fray@mvista.com \
    --cc=acahalan@cs.uml.edu \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.