Re: A89: dumb question
[Prev][Next][Index][Thread]
Re: A89: dumb question
> So basically we do not have to worry about where in memory certain
> byte/work/longword objects lie because the assembler "alligns" the objects in
> memory to some even address (2 or 4)??? I do not understand how you can get
> an error when writing to an odd address if all the objects are already set to
> some even address...please explain...
It's easy.
On one hand, the assembler does not align objects on its own, it
aligns if you tell it to do so. If you write this:
foo ds.b 1
bar ds.l 1
then, if you start at say 0x1000, bar will be at 0x1001 which is
an odd address even though bar is a long object. Therefore, if you
refer to bar with a .l or .w instruction, you get the address error.
On top of that you often use calculated addresses. If your calculations
(or assumptions about the objects that participate in the calculations)
are incorrect, you can easily end up with an odd address.
An frequent problem with C programmers who came from a non-picky
processor to the 68k world is to declare a general buffer (which
customarily is a char array, thus byte-aligned) and cast a pointer
to this array, something like this:
char buffer[ 100 ];
int data;
...
data = *((int *) buffer);
and whoops, here comes the boogeyman. The C compiler will compile
this:
buffer ds.b 100 ; reserve 100 bytes of space, not aligned
align 2 ; 'data' is an int so it must be aligned to word boundary
data ds.l 1 ; reserve space for data
...
move.l buffer,data ; this is the same as the C expr. above
Of course, if buffer was not aligned, the move will blow up.
In assembler, you often do something like this:
move.w 12(a0,d4),d3
then if either a0 or d4 (but not both) contain an odd number, you will
get the exception. The assembler does not (because it can not) try to
figure out what's in the different registers so there's no real
protection against misaliged access.
Regards,
Zoltan
References: