Misaligned Access Clarification

最新推荐文章于 2024-04-27 15:52:09 发布

weixin_33704234

最新推荐文章于 2024-04-27 15:52:09 发布

阅读量164

点赞数

文章标签： python

原文链接：https://my.oschina.net/mavericsoung/blog/132990

版权

2019独角兽企业重金招聘Python工程师标准>>>

misaligned access clarification

P: n/a

ramasubramanian.rahul

hi
i was doing some tinkering and wrote the following code on a HPUX
#include<stdio.h>
2 int main(){
3 char *buf = malloc( 100 );
4 int a = * ( int * ) ( buf + 13 );
5 }

this thing prompyly gave a bus error
i know that this is an example of misaligned access .. i believe that
the compiler expects to get an aligned address ( 4 bytes in this case )
....and since the address is odd its flaunders.
on Intel machine it works fine
my doubt is :
why does the compiler expect to get an aligned address... why can it
not take a misaligned address? what is main reason for alignment... and
slightly digressing... why is alignment of stack necessary ( gcc
compiler keep doing that some how ).......
a detailed answer will be highly appriciated
thanks in advance
kind egards
rahul

Oct 11 '06 # 1

Post Reply

Share this Question

2 Replies

Ads by Google

Fast Reporting components

www.fast-report.com

for Delphi 7, 2007, 2009, XE1-3 Royalty-free end-user report design

P: n/a

Chris Dollin

ramasubramanian.rahul @gmail.com wrote:

hi
i was doing some tinkering and wrote the following code on a HPUX
#include<stdio.h>
2 int main(){
3 char *buf = malloc( 100 );
4 int a = * ( int * ) ( buf + 13 );
5 }

(I don't know about anyone else, but I hate hate hate those line
numbers. They're visually distracting and get in the way if I
want to cutnpaste code into an editor. I'd cut back just a bit
on the whitespace, too.)

this thing prompyly gave a bus error

Promptly? You didn't even need to run it? That's some environment
you have there ...

i know that this is an example of misaligned access .. i believe that
the compiler expects to get an aligned address ( 4 bytes in this case )

C expects you to know what you're doing. If you take an address and
cast it to int* and dereference it, it's expected to be the adddress
of an int. If I remember PA-RISC correctly (I'm assuming that's what
you're running HPUX on) then ints are aligned on 4-byte boundaries
and misaligned addresses fault. Since the result of malloc is int-aligned,
and 13 isn't a multiple of 4, `buf+13` isn't an int address. BOOM.

...and since the address is odd its flaunders.

I expect the machine is just swauning around.

on Intel machine it works fine

For values of `work` that are not guaranteed by C.

my doubt is :
why does the compiler expect to get an aligned address... why can it
not take a misaligned address?

Let's be clear. The compiler isn't "taking" any address at all: the
compiler isn't there when the fault happens. It's the /machine/
that doesn't like the address. You promised the compiler that the
address `buf + 13` would be int-aligned, and the compiler, being
both stupid and trusting, believed you.

what is main reason for alignment...

Speed. As a consequence of hardware design, an 4-byte value that
is split over interesting hardware boundaries can be slower
to access. (EG it may require multiple reads.) It may be a /lot/
slower to access. So some machine designs disallow it. C isn't
prejudiced against those machines.

Note that there are other machines with a different treatement
of misaligned adresses. Under RISC OS on the Archimedes and
RSIC PCs, if I remember correctly a word access to a misaligned
address resulted in an int value being read from the aligned
(ie & ~3) address and then being /rotated/ so that the low
byte was the byte at the original address. (I think this was
just a consequence of the way the byte-reading hardware worked.)

As far as C is concerned, this is just another allowed
implementation of undefined behaviour. Seems like a more useful
one to me (fx:innocence).

and
slightly digressing... why is alignment of stack necessary ( gcc
compiler keep doing that some how ).......

Speed.

--
Chris "Essen -8 and counting" Dollin
"I'm still here and I'm holding the answers" - Karnataka, /Love and Affection/

Oct 11 '06 # 2

P: n/a

Gordon Burditt

>i was doing some tinkering and wrote the following code on a HPUX

>#include<stdio.h>
2 int main(){
3 char *buf = malloc( 100 );
4 int a = * ( int * ) ( buf + 13 );
5 }

this thing prompyly gave a bus error
i know that this is an example of misaligned access .. i believe that
the compiler expects to get an aligned address ( 4 bytes in this case )
...and since the address is odd its flaunders.
on Intel machine it works fine
my doubt is :
why does the compiler expect to get an aligned address... why can it

Because the *HARDWARE* expects to get an aligned address (for some
processor types). You saw what happened when it didn't. Another
possibility is that you quietly get the wrong bytes (the low-order few
bits of the address may be just *ignored*).

>not take a misaligned address? what is main reason for alignment... and
slightly digressing...

There doesn't have to be a single main reason for alignment. An
important reason is that if your hardware requires it, your program
will crash or you'll fetch the wrong data if you don't align
correctly. Another issue is that even if your hardware doesn't
actually require it, aligned accesses may be faster (it doesn't
require multiple memory fetches to get a single value).