[coyotos-dev] Optional floating state
Timothy Roscoe
timothy.roscoe at intel.com
Wed Jan 25 12:27:53 EST 2006
Nemesis did this - it was a fairly commonplace technique on Alpha,
where you could turn the FP unit on and off fairly easily, and the
trap on first use is only a PALcall. I think we got the idea from the
OSF/1 PAL code.
It's almost certainly no-lose, but I'd be interested to see whether it
buys you anything significant these days on real workloads. FP is
used for all sorts of things that used to use fixed-point or integer
arithmetic, since it's simply faster - you can retire a lot more
floating point multiplies than integer multiplies these days on most
processors.
-- Mothy
At Wed, 25 Jan 2006 02:28:27 -0800, Coyotos development discussions <coyotos-dev at coyotos.org> wrote:
> Shap and I were talking on the phone about an idea that did not get
> into the Keykos kernel but is described at <http://cap-lore.com/
> CapTheory/KK/float.html>. (The 370 couldn't use it.)
> I described it as omitting floating state (and such other optional
> user state such as vector registers) from domains that didn't need them.
> He objected that it was difficult to know if that state was used and
> testing could not prove that it was unused.
> It is better than that.
> Include the state in each domain and code the kernel as described in
> the link above.
> Then the overhead of loading or saving that state is paid only when
> and if the domain actually uses that state.
> Indeed the optional state is not even swapped into RAM until when and
> if it is used.
> Further if a period of time occurs where the domain is running but
> temporarily not using the state, the overhead is avoided.
> In a period of time where only one domain is using the state, the
> overhead is also avoided, even while time sharing with other domains.
>
> I can''t see a single pattern where you loose!
> That's a rare optimization!
> _______________________________________________
> coyotos-dev mailing list
> coyotos-dev at coyotos.org
> http://www.coyotos.org/mailman/listinfo/coyotos-dev
>
>
>
More information about the coyotos-dev
mailing list