From: Pavel Roskin <proski@gnu.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Endianness macros capitalization
Date: Sat, 05 Jul 2008 19:14:05 -0400 [thread overview]
Message-ID: <1215299645.17114.25.camel@dv> (raw)
In-Reply-To: <1215298499.26019.192.camel@localhost>
On Sun, 2008-07-06 at 00:54 +0200, Javier Martín wrote:
> El sáb, 05-07-2008 a las 17:30 -0400, Pavel Roskin escribió:
> > They probably should be functions. We may want to sparse annotate GRUB
> > one day, and then inline functions in the only way to go.
> Hmm... you mean changing this
>
> #define grub_swap_bytes16(x) \
> ({ \
> grub_uint16_t _x = (x); \
> (grub_uint16_t) ((_x << 8) | (_x >> 8)); \
> })
>
> ...for this
>
> inline grub_uint16_t grub_swap_bytes16(uint16_t x)
> {
> return (x << 8) | (x >> 8);
> }
>
> and such?
Actually, grub_swap_bytes16 should be avoided in the general code. We
need to convert macros like grub_cpu_to_le16() to functions.
> The pro is that we get rid of the ugly hack in the macro
> version that ensures single evaluation, but a con is that we cannot
> _force_ any random compiler to inline anything, so we might end up with
> gross numbers of function calls.
We can force inlining in gcc with always_inline. But we don't need to
force anything. Modern versions of gcc can decide for us, but we can
influence the choice by using optimization flags, such as -O2 and -Os.
In come cases, function calls would take less space than the actual code
for byte swapping.
> By the way, what is "sparse annotate"?
There is a utility called sparse:
git://git.kernel.org/pub/scm/linux/kernel/git/josh/sparse.git
It acts like a compiler, but it only produces warnings. It can
distinguish bitwise types that cannot be treated like normal integers
for arithmetic operations like addition.
If we mark little-endian and big-endian variables as bitwise, sparse
will warn if such variables are used without byte swapping. Linux uses
it a lot. Sparse is really a very good checker for that purpose.
Sparse does other checks too.
--
Regards,
Pavel Roskin
next prev parent reply other threads:[~2008-07-05 23:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-05 13:27 Endianness macros capitalization Javier Martín
2008-07-05 21:30 ` Pavel Roskin
2008-07-05 22:54 ` Javier Martín
2008-07-05 23:14 ` Pavel Roskin [this message]
2008-07-06 18:30 ` Robert Millan
2008-07-06 20:02 ` Javier Martín
2008-07-07 19:25 ` Christian Franke
2008-07-08 18:04 ` Christian Franke
2008-07-09 6:47 ` Pavel Roskin
2008-07-09 12:50 ` Christian Franke
2008-07-09 17:57 ` Pavel Roskin
2008-07-10 19:25 ` Christian Franke
2008-07-10 19:59 ` Pavel Roskin
2008-07-11 7:06 ` Jordi Mallach
2008-07-11 8:53 ` Pavel Roskin
2008-07-11 9:07 ` Pavel Roskin
2008-07-11 13:21 ` Christian Franke
2008-07-11 18:33 ` Pavel Roskin
2008-07-20 13:45 ` Christian Franke
2008-07-20 23:31 ` Pavel Roskin
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=1215299645.17114.25.camel@dv \
--to=proski@gnu.org \
--cc=grub-devel@gnu.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.