From: Zach Brown <zab@zabbo.net>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Greg KH <greg@kroah.com>,
Kristen Accardi <kristen.c.accardi@intel.com>,
linux-pci@atrey.karlin.mff.cuni.cz, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 6700/6702PXH quirk
Date: Mon, 08 Aug 2005 10:42:37 -0700 [thread overview]
Message-ID: <42F7998D.8030606@zabbo.net> (raw)
In-Reply-To: <20050806033455.GA23679@havoc.gtf.org>
Jeff Garzik wrote:
> <pedantic>
>
> FWIW, compilers generate AWFUL code for bitfields. Bitfields are
> really tough to do optimally, whereas bit flags ["unsigned int flags &
> bitmask"] are the familiar ints and longs that the compiler is well
> tuned to optimize.
I wouldn't have chosen the micro-optimization argument against bitfields
because people who use them as booleans will be more than willing to
trade minuscule performance degredation in non-critical paths for
heaping piles of legibility:
if (!foo->enabled)
if (!(foo->flags & FOO_FLAG_ENABLED)
No, I would have chosen the maintenance risk of forgetting that they're
really 1 bit wide scalars which truncate on assignment.
struct foo {
unsigned enabled:1;
};
int some_thing_is_enabled(thing) {
return thing->whatever & some_high_bit;
}
foo->enabled = some_thing_is_enabled()
Requiring people to remember that they want !!() around assignments
seems much more dangerous. They'll get left out to "optimize" current
behaviour, leaving land mines in the tree for future maintainers.
- z
next prev parent reply other threads:[~2005-08-08 17:42 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-05 16:27 [PATCH] 6700/6702PXH quirk Kristen Accardi
2005-08-05 17:12 ` Bjorn Helgaas
2005-08-05 17:20 ` Kristen Accardi
2005-08-05 18:35 ` Greg KH
2005-08-05 19:10 ` Kristen Accardi
2005-08-05 22:05 ` Kristen Accardi
2005-08-05 22:26 ` Andrew Morton
2005-08-05 22:40 ` Kristen Accardi
2005-08-05 22:51 ` Andrew Morton
2005-08-05 22:57 ` Greg KH
2005-08-06 3:34 ` Jeff Garzik
2005-08-06 8:50 ` Matthew Wilcox
2005-08-06 15:57 ` Jeff Garzik
2005-08-07 15:46 ` Denis Vlasenko
2005-08-08 17:42 ` Zach Brown [this message]
2005-08-08 17:45 ` David S. Miller
2005-08-08 17:53 ` Zach Brown
2005-08-05 22:50 ` Jeff Garzik
2005-08-05 23:51 ` Kristen Accardi
2005-08-08 16:36 ` Bjorn Helgaas
2005-08-08 17:57 ` Kristen Accardi
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=42F7998D.8030606@zabbo.net \
--to=zab@zabbo.net \
--cc=greg@kroah.com \
--cc=jgarzik@pobox.com \
--cc=kristen.c.accardi@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
/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