mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ben Dooks <ben@fluff.org>
To: Heikki Orsila <shdl@zakalwe.fi>
Cc: Daniel Drake <dsd@gentoo.org>,
	linux-kernel@vger.kernel.org, davem@davemloft.net,
	kune@deine-taler.de, johannes@sipsolutions.net
Subject: Re: [RFC] Documentation about unaligned memory access
Date: Mon, 26 Nov 2007 17:12:23 +0000	[thread overview]
Message-ID: <20071126171223.GB7855@fluff.org.uk> (raw)
In-Reply-To: <20071123114329.GG7681@zakalwe.fi>

On Fri, Nov 23, 2007 at 01:43:29PM +0200, Heikki Orsila wrote:
> On Fri, Nov 23, 2007 at 12:15:53AM +0000, 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 memory accesses, 
> either an exception is generated, or the data 
> access is silently invalid. In architectures that allow unaligned 
> access, natural aligned accesses are usually faster than non-aligned."
> 
> > 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.
> 
> *very* -> *slower*
> 
> > Natural alignment
> > =================
> 
> Please move this definition before "Why unaligned access is bad".
> 
> Also, it would be nice to have a table of ISAs:
> 
> ISA		Need		Need
> 		natural		alignment
> 		alignment	by x
> --------------------------------------------
> m68k		No		2
> powerpc/ppc	Yes		Word size
> x86		No		No
> x86_64		No		No
arm32		Yes		2 for 16bit data, 4 for 32bit

Note, if the unaligned handler is running, the alignment will be fixed
by the fault handler (at the cost of taking a fault). If the unaligned
handler is turned off, you get a "free" shift of the data instead.

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

  parent reply	other threads:[~2007-11-26 17:12 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-23  0:15 Daniel Drake
2007-11-23  0:27 ` Avuton Olrich
2007-11-23  1:29 ` Alan Cox
2007-11-23  3:04   ` Kyle Moffett
2007-11-23  6:18   ` dean gaudet
2007-11-23  9:46     ` Arne Georg Gleditsch
2007-11-26 14:50       ` dean gaudet
2007-11-23  1:29 ` David Miller
2007-11-23 10:06 ` Jan Engelhardt
2007-11-23 11:43 ` Heikki Orsila
2007-11-25 11:16   ` Geert Uytterhoeven
2007-11-25 11:24     ` Heikki Orsila
2007-11-26  0:48       ` Alan Cox
2007-11-26 17:12   ` Ben Dooks [this message]
2007-11-27  7:51   ` Kumar Gala
2007-11-23 22:02 ` Vadim Lobanov
2007-11-23 22:52 ` Dmitri Vorobiev
2007-11-24 13:34 ` Pierre Ossman
2007-11-24 15:50   ` Luciano Rocha
2007-11-24 16:19     ` Pierre Ossman
2007-11-24 17:22       ` Luciano Rocha
2007-11-24 17:35         ` Pierre Ossman
2007-11-24 18:28           ` Luciano Rocha
2007-11-24 17:53         ` Haavard Skinnemoen
2007-11-25  8:27 ` Denys Vlasenko
2007-11-25 14:13 ` Olaf Titz
2007-11-26  9:14 ` DM
2007-11-26 14:47 ` Johannes Berg
2007-11-27  0:40   ` Arnaldo Carvalho de Melo
2007-11-26 14:51 ` Johannes Berg
2007-11-30  8:18 ` Jörn Engel
     [not found] <fa.U+CIv4JClOmn6KppLkEOSk7RW0Y@ifi.uio.no>
2007-11-23  1:24 ` Robert Hancock
2007-11-23  2:07   ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071126171223.GB7855@fluff.org.uk \
    --to=ben@fluff.org \
    --cc=davem@davemloft.net \
    --cc=dsd@gentoo.org \
    --cc=johannes@sipsolutions.net \
    --cc=kune@deine-taler.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shdl@zakalwe.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome