On Fri, 23 November 2007 00:15:53 +, Daniel Drake wrote:
>
> What's the definition of an unaligned access?
> =
>
> Unaligned memory accesses occur when you try to read N bytes of data starting
> from an address that is not evenly divisible by N (i.e
On Nov 23, 2007, at 5:43 AM, Heikki Orsila wrote:
On Fri, Nov 23, 2007 at 12:15:53AM +, Daniel Drake wrote:
Why unaligned access is bad
===
Most architectures are unable to perform unaligned memory accesses.
Any
unaligned access causes a processor exception.
"
Em Mon, Nov 26, 2007 at 03:47:06PM +0100, Johannes Berg escreveu:
>
> > Sidenote: in the above example, you may wish to reorder the fields in the
> > above structure so that the overall structure uses less memory. For example,
> > moving field3 to sit inbetween field1 and field2 (where the padding
On Fri, Nov 23, 2007 at 01:43:29PM +0200, Heikki Orsila wrote:
> On Fri, Nov 23, 2007 at 12:15:53AM +, Daniel Drake wrote:
> > Why unaligned access is bad
> > ===
> >
> > Most architectures are unable to perform unaligned memory accesses. Any
> > unaligned access causes
> Going back to an earlier example:
> void myfunc(u8 *data, u32 value)
> {
> [...]
> *((u16 *) data) = cpu_to_le32(value);
> [...]
typo? should it be a u32 cast?
> To avoid the unaligned memory access, you could rewrite it as follows:
>
>
> Sidenote: in the above example, you may wish to reorder the fields in the
> above structure so that the overall structure uses less memory. For example,
> moving field3 to sit inbetween field1 and field2 (where the padding is
> inserted) would shrink the overall structure by 1 byte:
>
> s
On Fri, 23 Nov 2007, Arne Georg Gleditsch wrote:
> dean gaudet <[EMAIL PROTECTED]> writes:
> > on AMD x86 pre-family 10h the boundary is 8 bytes, and on fam 10h it's 16
> > bytes. the penalty is a mere 3 cycles if an access crosses the specified
> > boundary.
>
> Worth noting though, is that a
On Nov 23, 2007 1:15 AM, Daniel Drake <[EMAIL PROTECTED]> wrote:
[...]
>
> Before I do so, any comments on the following?
>
[...]
> void myfunc(u8 *data, u32 value)
> {
> [...]
> value = cpu_to_le32(value);
> memcpy(data, value, sizeof
> mc68020+ No No
> (mc68000/010 No 2) (not for Linux)
Actually ucLinux has been persuaded to run on m68000.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://v
> Unaligned memory accesses occur when you try to read N bytes of data starting
> from an address that is not evenly divisible by N (i.e. addr % N != 0).
Should clarify that you mean "with power-of-two N" - even more
strictly this depends on the processor, but I'm pretty sure there is
none which s
On Sun, Nov 25, 2007 at 12:16:08PM +0100, Geert Uytterhoeven wrote:
> > ISA NeedNeed
> > natural alignment
> > alignment by x
> >
> > m68kNo 2
>
> `No' for >= 68020.
On Fri, 23 Nov 2007, Heikki Orsila wrote:
> On Fri, Nov 23, 2007 at 12:15:53AM +, Daniel Drake wrote:
> > Why unaligned access is bad
> > ===
> >
> > Most architectures are unable to perform unaligned memory accesses. Any
> > unaligned access causes a processor exceptio
On Thursday 22 November 2007 16:15, Daniel Drake wrote:
> In summary: if your code causes unaligned memory accesses to happen, your
> code will not work on some platforms, and will perform *very* badly on
> others.
Although understanding alignment is important, there is another
extreme - what I ca
On Sat, Nov 24, 2007 at 06:35:25PM +0100, Pierre Ossman wrote:
> On Sat, 24 Nov 2007 17:22:36 +
> Luciano Rocha <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
> > > It most certainly does not. gcc will assume that an int* has int
> > > alignmen
On Sat, 24 Nov 2007 17:22:36 +
Luciano Rocha <[EMAIL PROTECTED]> wrote:
> Nothing does, even memcpy doesn't check alignment of the source, or
> alignment at all in some assembly implementations (only word-copy,
> without checking if at word-boundary).
An out-of-line implementation can only do
On Sat, 24 Nov 2007 17:22:36 +
Luciano Rocha <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
> > It most certainly does not. gcc will assume that an int* has int alignment.
> > memcpy() is a builtin, which gcc can translate to pretty much anything.
On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
> On Sat, 24 Nov 2007 15:50:52 +
> Luciano Rocha <[EMAIL PROTECTED]> wrote:
>
> >
> > Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems
> > in any case. Intelligent ones, like the one provided in glibc, firs
On Sat, 24 Nov 2007 15:50:52 +
Luciano Rocha <[EMAIL PROTECTED]> wrote:
>
> Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems
> in any case. Intelligent ones, like the one provided in glibc, first copy
> bytes till output is aligned (C file) *or* size is a multiple (i68
On Sat, Nov 24, 2007 at 02:34:41PM +0100, Pierre Ossman wrote:
> On Fri, 23 Nov 2007 00:15:53 + (GMT)
> Daniel Drake <[EMAIL PROTECTED]> wrote:
>
> > Being spoilt by the luxuries of i386/x86_64 I've never really had a good
> > grasp on unaligned memory access problems on other architectures an
On Fri, 23 Nov 2007 00:15:53 + (GMT)
Daniel Drake <[EMAIL PROTECTED]> wrote:
> Being spoilt by the luxuries of i386/x86_64 I've never really had a good
> grasp on unaligned memory access problems on other architectures and decided
> it was time to figure it out. As a result I've written this d
Daniel Drake пишет:
> Being spoilt by the luxuries of i386/x86_64 I've never really had a good
> grasp on unaligned memory access problems on other architectures and decided
> it was time to figure it out. As a result I've written this documentation
> which I plan to submit for inclusion as
> Docum
On Thursday 22 November 2007 04:15:53 pm Daniel Drake wrote:
> Fortunately things are not too complex, as in most cases, the compiler
> ensures that things will work for you. For example, take the following
> structure:
>
> struct foo {
> u16 field1;
> u32 field2;
On Fri, Nov 23, 2007 at 12:15:53AM +, Daniel Drake wrote:
> Why unaligned access is bad
> ===
>
> Most architectures are unable to perform unaligned memory accesses. Any
> unaligned access causes a processor exception.
"Some architectures are unable to perform unaligne
On Nov 23 2007 00:15, Daniel Drake wrote:
>
>What's the definition of an unaligned access?
>=
>
>Unaligned memory accesses occur when you try to read N bytes of data starting
>from an address that is not evenly divisible by N (i.e. addr % N != 0).
>For e
dean gaudet <[EMAIL PROTECTED]> writes:
> on AMD x86 pre-family 10h the boundary is 8 bytes, and on fam 10h it's 16
> bytes. the penalty is a mere 3 cycles if an access crosses the specified
> boundary.
Worth noting though, is that atomic accesses that cross cache lines on
an Opteron system is
On Fri, 23 Nov 2007, Alan Cox wrote:
> Its usually faster if you don't misalign on x86 as well.
i'm not sure if i agree with "usually"... but i know you (alan) are
probably aware of the exact requirements of the hw.
for everyone else:
on intel x86 processors an access is unaligned only if it c
On Nov 22, 2007, at 20:29:11, Alan Cox wrote:
Most architectures are unable to perform unaligned memory
accesses. Any unaligned access causes a processor exception.
Not all. Some simply produce the wrong answer - thats oh so much
more exciting.
As one example, the MicroBlaze soft-core proc
Robert Hancock <[EMAIL PROTECTED]> writes:
>
> Also, x86 doesn't prohibit unaligned accesses,
That depends, e.g. for SSE2 they can be forbidden.
> but I believe they have
> a significant performance cost and are best avoided where possible.
On Opteron the typical cost of a misaligned access is a
> Most architectures are unable to perform unaligned memory accesses. Any
> unaligned access causes a processor exception.
Not all. Some simply produce the wrong answer - thats oh so much more
exciting.
> You may be wondering why you have never seen these problems on your own
> architecture. Some
Thanks you for working proactively on these problems.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Daniel Drake wrote:
Being spoilt by the luxuries of i386/x86_64 I've never really had a good
grasp on unaligned memory access problems on other architectures and decided
it was time to figure it out. As a result I've written this documentation
which I plan to submit for inclusion as
Documentation
On Nov 22, 2007 4:15 PM, Daniel Drake <[EMAIL PROTECTED]> wrote:
> Before I do so, any comments on the following?
>
< above case it would insert 2 bytes of padding inbetween field1 and field2.
> above case it would insert 2 bytes of padding in between field1 and field2.
< moving field3 to sit in
32 matches
Mail list logo
