From: Jens Gustedt <jens.gustedt@inria.fr>
To: musl@lists.openwall.com
Subject: stdatomic library implementation
Date: Mon, 27 Jul 2015 09:51:41 +0200 [thread overview]
Message-ID: <1437983501.757.4.camel@inria.fr> (raw)
[-- Attachment #1: Type: text/plain, Size: 4220 bytes --]
Hello,
in two follow up mails I will send you the first version of all of
this as a patch and a documentation of it as .org and .pdf files.
You might be most interested in the implementation issues, first, so I
copy that part of the documentation below.
Thanks for considering
Jens
* The implementation
** Requirements
*** Compilers
You should be able to compile this implementation with any version
of modern gcc and clang. (Versions are hard to tell, gcc should work
for 4.1) The quality of the resulting binary will depend on the
implementation of atomic support by the compiler.
There are three different implementations, for modern clang and gcc,
and one for those compilers that only support the =__sync_=
built-ins. They are only tested with clang and gcc, but might work
with other compilers that implement one of the sets of built-ins and
is otherwise compatible to some gcc extensions:
- compound expressions with =({ })=
- =__attribute__= with =__alias__= and =__unused__=
- =__builtin_choose_expr= for the =__sync= version as a precursor of
C11's =_Generic=
There are some heuristics in place to decide at compile time which
case applies, namely =__clang__= to detect clang, =__ATOMIC_...=
macros to detect the C11 versions of the built-ins.
*** OS or C library support
The library may work with different lock constructs. The musl
integration uses =LOCK= and =UNLOCK= internal macros.
** Caveats
*** Symbol renaming
There is one important difficulty when compiling this. The original
=__atomic= library interface was developed with C++ in mind and not
C. Therefore it freely uses function overloading for the built-ins
versus the library interface. Since we also use the library
functions as fallbacks in the implementation of some of the =_X=
variants this naming scheme is not supportable with a C compiler.
We get away with it by using internal names, prefixed with =__impl_=
for all functions. Then we rename symbols to the intended ones using
=objcopy=.
- The current integration into musl does this with a *script* that
you have to run *manually* after compilation.
- You then have to launch make a *second time* to do the final link.
This technique is certainly not ideal and subject to improvement.
*** Support of 16 byte atomic instructions
The main difference for modern processors that is relevant here is
if it supports 16 byte atomic instructions or not. There is no
difficulty to detect this at compile time, but if the library is
used with code that is compiled with a different compiler or just
different compiler options, incompatible binary code may be
produced.
My plan is to freeze that feature at compile time of the library
and reflect the capacity in the =<stdatomic.h>= that is
provided. This then may result in code that is a bit less
optimized than it could, but that is compatible.
- If the library is *not* compiled with direct 16 byte support the
application may not use it, and thus use a memory implementation
for such operations.
- If the library *is* compiled with direct 16 byte support but the
application compiler doesn't support it, the user code should
fallback to library calls, but which in turn use the atomic
instructions. So such a variant would have a call overhead and
would not be able to inline the atomics in the user binary.
All of this is not yet, done, though. Be careful when using this
preliminary version.
** Leftovers
There are some leftovers that will hopefully disappear. In
particular there are several hash functions and a instrumentation
infrastructure for the hashes. I didn't have enough test cases yet
to see what would be best, here.
--
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next reply other threads:[~2015-07-27 7:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 7:51 Jens Gustedt [this message]
2015-07-27 7:53 ` stdatomic library implementation, code Jens Gustedt
2015-07-27 10:36 ` Joakim Sindholt
2015-07-27 22:30 ` Jens Gustedt
2015-07-27 8:08 ` stdatomic library implementation, documentation Jens Gustedt
2015-08-03 11:47 ` stdatomic library, v2 Jens Gustedt
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=1437983501.757.4.camel@inria.fr \
--to=jens.gustedt@inria.fr \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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).