From: Artem Bityutskiy <dedekind1@gmail.com>
To: Timur Tabi <timur.tabi@gmail.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
Zang Roy-R61911 <r61911@freescale.com>,
Lan Chunhe-B25806 <B25806@freescale.com>,
linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
Anton Vorontsov <cbouatmailru@gmail.com>,
akpm@linux-foundation.org, dwmw2@infradead.org,
Gala Kumar-B11780 <B11780@freescale.com>
Subject: Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
Date: Mon, 13 Sep 2010 17:27:55 +0300 [thread overview]
Message-ID: <1284388075.10955.51.camel@localhost> (raw)
In-Reply-To: <AANLkTimfKwdw+nLAjDjxf52dbZKLF-3aES+bT7CHskAS@mail.gmail.com>
On Mon, 2010-09-13 at 09:10 -0500, Timur Tabi wrote:
> On Mon, Sep 13, 2010 at 2:30 AM, Zang Roy-R61911 <r61911@freescale.com> wrote:
>
> > What is the different for unsigned int and u32? I think they are same.
>
> Roy, please don't ever write code that assumes that sizeof(int) == 4.
> There's a reason why we have unsized integer types (like int, long,
> and short) and sized integer types (like u8, u16, u32). If you want
> an integer of a specific size, you should use a sized integer type.
Yes, sizeof(int) == 4 assumption is not good.
But sizeof(int) >= 4 is perfectly fine.
It is OK to rely on the fact that unsigned int is _at least_ 32-bit, not
less. And if you know 32 bits is enough, and you are fine with more, it
is _better_ to avoid u32. Simply because with unsigned int you do not
limit the compiler and CPU and let them use native integers, rather than
strictly 32-bit. This potentially gives the compiler and CPU more room
for optimization.
I see people use u32 and the friends too much. It is safe and better to
use native types, unless you really have to make the variable to be
strictly u32.
I did not follow this particular conversation and do not judge which
type is better in this case. I am talking in general. :-)
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Timur Tabi <timur.tabi@gmail.com>
Cc: Wood Scott-B07421 <B07421@freescale.com>,
Zang Roy-R61911 <r61911@freescale.com>,
Lan Chunhe-B25806 <B25806@freescale.com>,
linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
akpm@linux-foundation.org, dwmw2@infradead.org,
Gala Kumar-B11780 <B11780@freescale.com>
Subject: Re: [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode
Date: Mon, 13 Sep 2010 17:27:55 +0300 [thread overview]
Message-ID: <1284388075.10955.51.camel@localhost> (raw)
In-Reply-To: <AANLkTimfKwdw+nLAjDjxf52dbZKLF-3aES+bT7CHskAS@mail.gmail.com>
On Mon, 2010-09-13 at 09:10 -0500, Timur Tabi wrote:
> On Mon, Sep 13, 2010 at 2:30 AM, Zang Roy-R61911 <r61911@freescale.com> wrote:
>
> > What is the different for unsigned int and u32? I think they are same.
>
> Roy, please don't ever write code that assumes that sizeof(int) == 4.
> There's a reason why we have unsized integer types (like int, long,
> and short) and sized integer types (like u8, u16, u32). If you want
> an integer of a specific size, you should use a sized integer type.
Yes, sizeof(int) == 4 assumption is not good.
But sizeof(int) >= 4 is perfectly fine.
It is OK to rely on the fact that unsigned int is _at least_ 32-bit, not
less. And if you know 32 bits is enough, and you are fine with more, it
is _better_ to avoid u32. Simply because with unsigned int you do not
limit the compiler and CPU and let them use native integers, rather than
strictly 32-bit. This potentially gives the compiler and CPU more room
for optimization.
I see people use u32 and the friends too much. It is safe and better to
use native types, unless you really have to make the variable to be
strictly u32.
I did not follow this particular conversation and do not judge which
type is better in this case. I am talking in general. :-)
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2010-09-13 14:29 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-09 10:20 [PATCH 1/3 v2][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices Roy Zang
2010-09-09 10:20 ` Roy Zang
2010-09-09 10:20 ` [PATCH 2/3 v2][MTD] P4080/mtd: Only make elbc nand driver detect nand flash partitions Roy Zang
2010-09-09 10:20 ` Roy Zang
2010-09-09 10:20 ` [PATCH v2 3/3][MTD] P4080/mtd: Fix the freescale lbc issue with 36bit mode Roy Zang
2010-09-09 10:20 ` Roy Zang
2010-09-09 11:06 ` Geert Uytterhoeven
2010-09-09 11:06 ` Geert Uytterhoeven
2010-09-13 7:22 ` Zang Roy-R61911
2010-09-13 7:22 ` Zang Roy-R61911
2010-09-13 16:27 ` Scott Wood
2010-09-13 16:27 ` Scott Wood
2010-09-14 4:09 ` Zang Roy-R61911
2010-09-14 4:09 ` Zang Roy-R61911
2010-09-14 11:56 ` Timur Tabi
2010-09-14 11:56 ` Timur Tabi
2010-09-09 11:41 ` Anton Vorontsov
2010-09-13 7:30 ` Zang Roy-R61911
2010-09-13 7:30 ` Zang Roy-R61911
2010-09-13 14:10 ` Timur Tabi
2010-09-13 14:10 ` Timur Tabi
2010-09-13 14:27 ` Artem Bityutskiy [this message]
2010-09-13 14:27 ` Artem Bityutskiy
2010-09-13 14:35 ` Timur Tabi
2010-09-13 14:35 ` Timur Tabi
2010-09-13 16:45 ` Artem Bityutskiy
2010-09-13 16:45 ` Artem Bityutskiy
2010-09-13 18:36 ` Timur Tabi
2010-09-13 18:36 ` Timur Tabi
2010-09-13 18:46 ` Artem Bityutskiy
2010-09-13 18:46 ` Artem Bityutskiy
2010-09-13 20:04 ` Scott Wood
2010-09-13 20:04 ` Scott Wood
2010-09-14 6:20 ` Zang Roy-R61911
2010-09-14 6:20 ` Zang Roy-R61911
2010-09-09 11:23 ` [PATCH 2/3 v2][MTD] P4080/mtd: Only make elbc nand driver detect nand flash partitions Anton Vorontsov
2010-09-09 11:53 ` [PATCH 1/3 v2][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices Anton Vorontsov
2010-09-10 6:58 ` Zang Roy-R61911
2010-09-10 6:58 ` Zang Roy-R61911
2010-09-10 9:31 ` Anton Vorontsov
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=1284388075.10955.51.camel@localhost \
--to=dedekind1@gmail.com \
--cc=B07421@freescale.com \
--cc=B11780@freescale.com \
--cc=B25806@freescale.com \
--cc=akpm@linux-foundation.org \
--cc=cbouatmailru@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=r61911@freescale.com \
--cc=timur.tabi@gmail.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.
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.