From: Vitaly Oratovsky <vitaly_oratovsky@ne.mediaone.net>
To: linuxppc-dev@lists.linuxppc.org
Subject: Re: altivec
Date: Fri, 10 Sep 1999 18:02:18 +0000 [thread overview]
Message-ID: <37D947AA.85EE4650@ne.mediaone.net> (raw)
In-Reply-To: Pine.LNX.4.10.9909101030100.31612-100000@web1.turbolinux.com
Brad Midgley wrote:
> the kernel needs to know how & when to stack and unstack the altivec
> registers.
To really do Altivec vector regs save/restore efficiently will require
cooperation between kernel and compiler. Altivec architecture defines
a VRSAVE register, which is just a general purpose 32-bit wide bitmask.
The intention is for compiler to record usage of altivec registers in
the prologue of every function which uses them. Likewise, the epilogue
is supposed to restore VRSAVE to the caller's state. Of course, hand-
written assembly routines have to play by the same rules.
This approach permits saving/restoring the absolute minimum number of
vector unit regs, and [perhaps more importantly] only when the
interrupted
thread was truly using them.
A less ambitious approach which doesn't require the compiler to mock
with
VRSAVE would be to allow the kernel to discover whether a particular
process
uses the vector unit by "faulting" in the vector unit enable bit in MSR
for
each process individually.
Cheers, Vitaly.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~1999-09-10 18:02 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-10 10:32 altivec Sacha Varma
1999-09-10 11:59 ` altivec Benjamin Herrenschmidt
1999-09-10 12:27 ` altivec Sacha Varma
1999-09-10 17:43 ` altivec Brad Midgley
1999-09-10 17:51 ` altivec Brad Midgley
1999-09-10 18:02 ` Vitaly Oratovsky [this message]
1999-09-10 17:39 ` altivec David Edelsohn
-- strict thread matches above, loose matches on Subject: below --
1999-07-20 17:04 altivec David DeHaven
1999-07-20 17:04 altivec David DeHaven
1999-07-20 17:04 altivec David DeHaven
[not found] <Pine.PMDF.3.96.990715091130.538970498B-100000@uni.edu>
1999-07-15 16:11 ` altivec Matt Porter
1999-07-15 16:22 ` altivec Jason Haas
1999-07-15 16:29 ` altivec Josh Huber
1999-07-15 12:14 ` altivec sean o'malley
1999-07-15 17:36 ` altivec Matt Porter
1999-07-16 6:29 ` altivec Geert Uytterhoeven
1999-07-16 14:47 ` altivec Matt Porter
1999-07-09 11:29 altivec Sacha Varma
1999-07-09 12:14 ` altivec Holger Bettag
1999-07-09 13:04 ` altivec Mike DeSimone
1999-07-09 15:33 ` altivec Holger Bettag
1999-07-10 0:41 ` altivec Mike DeSimone
1999-07-14 10:17 ` altivec sean o'malley
1999-07-14 21:04 ` altivec Matt Porter
1999-07-14 21:42 ` altivec Josh Huber
1999-06-21 14:34 Altivec sean o'malley
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=37D947AA.85EE4650@ne.mediaone.net \
--to=vitaly_oratovsky@ne.mediaone.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).