Re: [PATCH] ubi: kill homegrown endian macros

["John Anthony Kazos Jr." <jakj@j-a-k-j.com>]

On Fri, 18 May 2007, David Woodhouse wrote:
> On Thu, 2007-05-17 at 22:57 -0400, John Anthony Kazos Jr. wrote:
> > Wouldn't the appropriate test be to demonstrate that the same program text 
> > opcodes are generated in both cases for all architectures? 
> 
> No, empirical testing with the compiler is never the _correct_ thing to
> do. It's just expedient.
> 
> > If that's not the case, even if the generation isn't -worse-, it shows
> > that the compiler is doing different things with each, which means
> > different versions of the compiler could do different things with it,
> 
> Well yes, but even it _is_ generating precisely the same output today,
> there's no reason why the compiler shouldn't behave differently under a
> different phase of the moon.
> 
> The _correct_ thing to do is act upon my mutterings at the time I
> removed the '__attribute__((packed))' from various JFFS2 structures to
> improve the generated code on ARM -- actually implement an attribute for
> GCC which has the same "don't insert any padding" meaning, but without
> the unwanted "assume arbitrary alignment" implications.

Out of curiosity, why would a compiler ever insert padding in a structure 
that has all its elements properly-aligned?

> It'd actually be nice if GCC knew about endianness too. I don't want to
> have to do:
> 
>    *x = le32_to_cpu(cpu_to_le32(*x) + 5);
> 
> I just want 
> 
>   uint32_t __attribute__((littleendian)) *x;
> 
>   *x += 5;
> 
> I know we can hack around it for masks, with '*x |= cpu_to_le32(X_BAR);'
> and such like, and we can load it into local native-endian variables and
> then copy it back again later -- but it's better just to let the
> compiler know what's going on and do its own optimisation. Especially on
> architectures which have 'load-and-swap' or 'store-and-swap'
> instructions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/