9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] extern register
Date: Fri, 18 Jul 2014 22:19:11 -0400	[thread overview]
Message-ID: <a817c7f6718828e579da97b023a0dba8@ladd.quanstro.net> (raw)
In-Reply-To: <3e0dba73883c8b291a66366c9ebe150d@ladd.quanstro.net>

On Fri Jul 18 22:05:32 EDT 2014, quanstro@quanstro.net wrote:
> On Fri Jul 18 21:58:37 EDT 2014, cinap_lenrek@felloff.net wrote:
> > the amd64 compiler reserves R14 and R15 for extern register
> > declarations. these are used by the kernel for the mach
> > and up pointers, but currently are not preserved during
> > system calls.
> >
> > would it make sense to save and restore the two registers
> > on syscall entry/exit, so userspace programs could make use
> > of them for per process data?
>
> i think after some experience (i.e. mistakes) the answer is probablly, no.
>
> the compiler needs to know for the kernel that r14 and r15 are special and
> not allocate them for the kernel, but what about userland?  what about libraries
> that are shared between them? ....
>
> one can work around these problems by compiling all libraries twice, etc.
> but these are painful compromises.
>
> in reality, there is only one place in the code that i know of that chews
> through 15 or more registers, and that's the alpha drawing code in
> libmemdraw.  so the solution of just limiting the compiler to r0-r13
> seems to be pretty effective for what we're doing.

i realize i didn't quite answer the question as asked.  restoring
the registers is independent of the compiler.  so yes, you're right!  the registers
should be restored.  but at least you know why it's not a disaster that
they are not.

- erik



  reply	other threads:[~2014-07-19  2:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-19  1:57 cinap_lenrek
2014-07-19  2:04 ` erik quanstrom
2014-07-19  2:19   ` erik quanstrom [this message]
2014-07-19  2:33     ` cinap_lenrek
2014-07-19  2:37       ` erik quanstrom
2014-07-19  2:27   ` cinap_lenrek
2014-07-19  2:41     ` erik quanstrom
2014-07-19 12:29 ` Aram Hăvărneanu
2014-07-19 12:42 ` Charles Forsyth
2014-07-19 14:38   ` Aram Hăvărneanu
2014-07-19 14:55     ` erik quanstrom
2014-07-19 15:53       ` Aram Hăvărneanu
2014-07-20  1:42   ` cinap_lenrek
2014-07-20 10:12     ` Aram Hăvărneanu
2014-07-20 16:35       ` cinap_lenrek

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=a817c7f6718828e579da97b023a0dba8@ladd.quanstro.net \
    --to=quanstro@quanstro.net \
    --cc=9fans@9fans.net \
    /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).