From: Randy Dunlap <rdunlap@xenotime.net>
To: Josh Triplett <josh@joshtriplett.org>
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Joe Perches <joe@perches.com>
Subject: Re: [PATCH] Documentation/CodingStyle: Add guidelines for inline assembly
Date: Tue, 20 Mar 2012 13:46:00 -0700 [thread overview]
Message-ID: <4F68EC88.7080607@xenotime.net> (raw)
In-Reply-To: <20120202223304.GA13069@leaf>
On 02/02/2012 02:33 PM, Josh Triplett wrote:
> Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Applied. Thanks.
> ---
> Documentation/CodingStyle | 29 +++++++++++++++++++++++++++++
> 1 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
> index 2b90d32..c58b236 100644
> --- a/Documentation/CodingStyle
> +++ b/Documentation/CodingStyle
> @@ -793,6 +793,35 @@ own custom mode, or may have some other magic method for making indentation
> work correctly.
>
>
> + Chapter 19: Inline assembly
> +
> +In architecture-specific code, you may need to use inline assembly to interface
> +with CPU or platform functionality. Don't hesitate to do so when necessary.
> +However, don't use inline assembly gratuitously when C can do the job. You can
> +and should poke hardware from C when possible.
> +
> +Consider writing simple helper functions that wrap common bits of inline
> +assembly, rather than repeatedly writing them with slight variations. Remember
> +that inline assembly can use C parameters.
> +
> +Large, non-trivial assembly functions should go in .S files, with corresponding
> +C prototypes defined in C header files. The C prototypes for assembly
> +functions should use "asmlinkage".
> +
> +You may need to mark your asm statement as volatile, to prevent GCC from
> +removing it if GCC doesn't notice any side effects. You don't always need to
> +do so, though, and doing so unnecessarily can limit optimization.
> +
> +When writing a single inline assembly statement containing multiple
> +instructions, put each instruction on a separate line in a separate quoted
> +string, and end each string except the last with \n\t to properly indent the
> +next instruction in the assembly output:
> +
> + asm ("magic %reg1, #42\n\t"
> + "more_magic %reg2, %reg3"
> + : /* outputs */ : /* inputs */ : /* clobbers */);
> +
> +
>
> Appendix I: References
>
--
~Randy
prev parent reply other threads:[~2012-03-20 20:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-02 22:33 [PATCH] Documentation/CodingStyle: Add guidelines for inline assembly Josh Triplett
2012-03-20 20:46 ` Randy Dunlap [this message]
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=4F68EC88.7080607@xenotime.net \
--to=rdunlap@xenotime.net \
--cc=joe@perches.com \
--cc=josh@joshtriplett.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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.