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
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
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
> 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:
>
>
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
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,
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(value));
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 atomic
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:
struct
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:
void
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 a
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 is
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.
> 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
> 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
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
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
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 call
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 exception.
Some
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.
`Yes' for
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
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
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
> > >
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
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,
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
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
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
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
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 and
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 (i686 asm
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, first copy
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. And
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, 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
alignment. memcpy()
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
>
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
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
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 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;
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
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
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, 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 unaligned
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
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
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
> 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.
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
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
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
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
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
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
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
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
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
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
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/
66 matches
Mail list logo
