On Tue, 18 Nov 2008, [email protected] wrote:
> Subject: unaligned: introduce common header
> From: Harvey Harrison <[email protected]>
>
> There are two common cases in the kernel, one where unaligned access is OK
> for an arch and one where the arch uses a packed-struct for the native
> endianness and opencoded C byteshifting for the other endianness.
> Consolidate these two implementations in asm-generic/unaligned.h
>
> Arches that require no special handling of unaligned access can define
> _UNALIGNED_ACCESS_OK in their asm/unaligned.h before including the generic
> version.
>
> +static inline void __put_le32_noalign(u8 *p, u32 val)
> +{
> + __put_le16_noalign(p + 2, val >> 16);
> + __put_le16_noalign(p, val);
Isn't it more logical to reverse the order, to store in increasing memory
locations:
__put_le16_noalign(p, val);
__put_le16_noalign(p + 2, val >> 16);
> +}
> +
> +static inline void __put_le64_noalign(u8 *p, u64 val)
> +{
> + __put_le32_noalign(p + 4, val >> 32);
> + __put_le32_noalign(p, val);
Same here:
__put_le32_noalign(p, val);
__put_le32_noalign(p + 4, val >> 32);
> +}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, 2008-11-19 at 09:21 +0100, Geert Uytterhoeven wrote:
> On Tue, 18 Nov 2008, [email protected] wrote:
> > Subject: unaligned: introduce common header
> > From: Harvey Harrison <[email protected]>
> >
> > There are two common cases in the kernel, one where unaligned access is OK
> > for an arch and one where the arch uses a packed-struct for the native
> > endianness and opencoded C byteshifting for the other endianness.
> > Consolidate these two implementations in asm-generic/unaligned.h
> >
> > Arches that require no special handling of unaligned access can define
> > _UNALIGNED_ACCESS_OK in their asm/unaligned.h before including the generic
> > version.
> >
> > +static inline void __put_le32_noalign(u8 *p, u32 val)
> > +{
> > + __put_le16_noalign(p + 2, val >> 16);
> > + __put_le16_noalign(p, val);
>
> Isn't it more logical to reverse the order, to store in increasing memory
> locations:
>
> __put_le16_noalign(p, val);
> __put_le16_noalign(p + 2, val >> 16);
>
All of the byteshifting versions were cribbed from the ARM implementation.
I'm not sure if there was a particular reason for doing it in this order, but
a lot of work seems to have gone in to minimize register usage.
See include/asm-arm/unaligned.h circa 2.6.25.
Harvey