Re: [PATCH] ubi: kill homegrown endian macros

[David Woodhouse <dwmw2@infradead.org>]

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.

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.

-- 
dwmw2

-
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/