From: matthieu castet <castet.matthieu@free.fr>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ubi: kill homegrown endian macros
Date: Fri, 18 May 2007 22:30:23 +0200 [thread overview]
Message-ID: <464E0CDF.3030703@free.fr> (raw)
In-Reply-To: <1179455959.2859.527.camel@shinybook.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]
Hi,
David Woodhouse wrote:
> On Thu, 2007-05-17 at 20:30 +0000, Matthieu CASTET wrote:
>> On arch that don't support aligned access, packed struct access will be
>> done byte per byte (but it could be the expected behavior if there
>> unaligned access).
>
> When I tested this on ARM, the output for je32_to_cpu et al was fine.
> For _other_ structures where I'd used __attribute__((packed)) to be
> safe, gcc would emit code to handle unaligned loads. But not in the
> simple case where the struct has only one member.
>
> Are you suggesting that this has changed since I did my testing?
>
here a small example I made and try with a sourcery 2006q3-27
/tmp/arm-2006q3/bin/arm-none-linux-gnueabi-gcc -S test.c -O3 -o
test.s.packed
/tmp/arm-2006q3/bin/arm-none-linux-gnueabi-gcc -S test.c -DNOP -O3 -o test.s
$diff test.s test.s.packed 19,23c19,34
< @ link register save eliminated.
< ldrh r2, [r1, #0]
< ldrh r1, [r0, #2]
< ldr r0, [r0, #4]
< @ lr needed for prologue
---
> stmfd sp!, {r4, r5, r6, lr}
> ldrb r2, [r0, #5] @ zero_extendqisi2
> ldrb r3, [r0, #4] @ zero_extendqisi2
> mov lr, r1
> ldrb r4, [r0, #6] @ zero_extendqisi2
> ldrb r5, [r0, #3] @ zero_extendqisi2
> ldrb r6, [r1, #1] @ zero_extendqisi2
> orr r3, r3, r2, asl #8
> ldrb r1, [r0, #2] @ zero_extendqisi2
> ldrb ip, [r0, #7] @ zero_extendqisi2
> ldrb r2, [lr, #0] @ zero_extendqisi2
> orr r3, r3, r4, asl #16
> orr r0, r3, ip, asl #24
> orr r1, r1, r5, asl #8
> orr r2, r2, r6, asl #8
> ldmfd sp!, {r4, r5, r6, lr}
Matthieu
[-- Attachment #2: test.c --]
[-- Type: text/x-csrc, Size: 820 bytes --]
#include <stdint.h>
#ifdef NOP
#define jint32_t uint32_t
#define jint16_t uint16_t
#define je16_to_cpu(x) ((x))
#define je32_to_cpu(x) ((x))
#else
typedef struct {
uint32_t v32;
} __attribute__((packed)) jint32_t;
typedef struct {
uint16_t v16;
} __attribute__((packed)) jint16_t;
#define je16_to_cpu(x) ((x).v16)
#define je32_to_cpu(x) ((x).v32)
#endif
struct jffs2_sum_unknown_flash
{
jint16_t nodetype; /* node type */
};
struct jffs2_unknown_node
{
/* All start like this */
jint16_t magic;
jint16_t nodetype;
jint32_t totlen; /* So we can skip over nodes we don't grok */
jint32_t hdr_crc;
};
int boo(struct jffs2_unknown_node *node, void *sp)
{
foo(je32_to_cpu(node->totlen), je16_to_cpu(node->nodetype), je16_to_cpu(((struct jffs2_sum_unknown_flash *)sp)->nodetype));
}
next prev parent reply other threads:[~2007-05-18 20:30 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-17 14:32 [PATCH] ubi: kill homegrown endian macros Christoph Hellwig
2007-05-17 14:50 ` Artem Bityutskiy
2007-05-17 14:56 ` Christoph Hellwig
2007-05-17 15:09 ` Artem Bityutskiy
2007-05-17 17:29 ` Andrew Morton
2007-05-17 17:46 ` Artem Bityutskiy
2007-05-17 18:18 ` Andrew Morton
2007-05-17 20:32 ` Artem Bityutskiy
2007-05-17 20:30 ` Matthieu CASTET
2007-05-18 2:39 ` David Woodhouse
2007-05-18 2:57 ` John Anthony Kazos Jr.
2007-05-18 3:17 ` David Woodhouse
2007-05-18 11:52 ` John Anthony Kazos Jr.
2007-05-18 14:52 ` David Woodhouse
2007-05-18 22:00 ` Segher Boessenkool
2007-05-19 2:07 ` David Woodhouse
2007-05-19 12:24 ` Segher Boessenkool
2007-05-20 11:29 ` David Woodhouse
2007-05-18 19:55 ` matthieu castet
2007-05-19 1:29 ` David Woodhouse
2007-05-18 20:30 ` matthieu castet [this message]
2007-05-17 20:42 ` Al Viro
2007-05-17 20:53 ` Al Viro
2007-05-18 6:58 ` Artem Bityutskiy
2007-05-18 8:38 ` Al Viro
2007-05-17 21:14 ` Dmitry Torokhov
2007-05-17 21:29 ` Al Viro
2007-05-17 21:33 ` David Miller
2007-05-17 21:47 ` Al Viro
2007-05-17 21:26 ` Al Viro
2007-05-17 20:56 ` David Miller
2007-05-17 21:03 ` Al Viro
2007-05-17 15:50 ` David Woodhouse
2007-05-17 18:12 ` Christoph Hellwig
2007-05-17 18:23 ` Sam Ravnborg
2007-05-17 18:36 ` Christoph Hellwig
2007-05-17 20:18 ` Jeremy Fitzhardinge
2007-05-17 20:27 ` Matthieu CASTET
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=464E0CDF.3030703@free.fr \
--to=castet.matthieu@free.fr \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.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.