All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Endianness macros capitalization
Date: Sun, 20 Jul 2008 19:31:50 -0400	[thread overview]
Message-ID: <1216596710.14762.29.camel@dv> (raw)
In-Reply-To: <48834166.7050906@t-online.de>

On Sun, 2008-07-20 at 15:45 +0200, Christian Franke wrote:
> Christian Franke wrote:

> > But the function call in the 32-bit case requires only 5 bytes :-)
> >   
> 
> Sorry, I was wrong here. The assumption about function call size was 
> only true for module-local calls. If a module calls a function in 
> kernel, each 5 byte call requires another 8 bytes for the ELF relocation 
> table entry.

Actually, the new versions of gcc have __builtin_bswap32 and
__builtin_bswap64, which are optimized even better.  There is no
__builtin_bswap16 because it is said that any correct implementation
will be optimized anyway:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00079.html

gcc 4.3.0 from Fedora is working fine with them.  I'm not sure about gcc
4.2.  There is only one bug.  Suppose I use this:

#define grub_swap_bytes32(x) __builtin_bswap32(x)
#define grub_swap_bytes64(x) __builtin_bswap64(x)

Then I get this warning:

partmap/apple.c: In function 'apple_partition_map_iterate':
partmap/apple.c:133: warning: format '%x' expects type 'unsigned int',
but argument 8 has type 'unsigned int'
partmap/apple.c:133: warning: format '%x' expects type 'unsigned int',
but argument 9 has type 'unsigned int'

Those arguments are produced by grub_swap_bytes32().  But if I use
wrapper functions, then there are no warnings, and the code side is
approximately the same.  We'll need wrappers to support sparse.

-- 
Regards,
Pavel Roskin



      reply	other threads:[~2008-07-20 23:31 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
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 [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=1216596710.14762.29.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.