Re: [MiNT] libgem16: vs_color

[Eero Tamminen <oak@helsinkinet.fi>]

Hi,

On Tuesday 19 January 2010, Helmut Karlowski wrote:
> > I would not consider allowing for odd stack addresses a fix. If
> > anything, such should cause a crash early and hard.
>
> Why do 020+ allow them then at all?  The people of motorola seem to
> have different views.

The reasons why CPUs support non-aligned access is that you may have data
format that isn't aligned (like some audio/video formats).  Then it's faster
for CPU to do the alignment than you to have code that does the aligning
of the data.

That's about the only reason to do unaligned data accesses.  Otherwise
it doesn't make any sense as it's slower than aligned access.

E.g. on newer ARM CPUs (and Linux kernel running on them), you can configure
whether CPU generates exceptions about alignment issues and whether
kernel will terminate the process when that happens, outputs a warning,
and/or silently fixups[1] the non-aligned accessed data.  This can help in
finding out & checking whether code does buggy or useful unaligned accesses.

Unaligned data accesses have also some other problems than performance,
e.g. on systems that have MMUs.  AFAIK if your unaligned data crosses memory
page border and generates MMU page fault, the access cannot be atomic
(if your code needs the accesses to be atomic).


	- Eero

[1] Upstream Linux kernel has had bugs in this though for several ARM CPU
versions, resulting usually in the buggy code using 100% CPU and draining
the battery.