Hi all,

I am having really strange behavior, which I could not explain to
myself.
When I do a copy from 0x20208A10 to 0x20487382, all the content is
copied.
And at the memory is:

0x20487382: 0x02
0x20487383: 0x00
0x20487384: 0x08
0x20487385: 0x00

Which shows it is perfectly copied. But if try to read from 0x20487382 a
double word (4byte), what I see in it is 0x00000002 instead of
0x00080002.
Would I get this behavior any time I work on double-words that are
misaligned in such a way?

Regards,
Bekir



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

This is a compiler question, not processor specific.
Ask in another forum.
On Mon, Jun 2, 2008 at 12:40 AM, ICLI, Bekir (EXT) <
b...@siemens.com> wrote:

> Hi all,
>
> I am having really strange behavior, which I could not explain to myself.
> When I do a copy from 0x20208A10 to 0x20487382, all the content is copied.
> And at the memory is:
>
> 0x20487382: 0x02
> 0x20487383: 0x00
> 0x20487384: 0x08
> 0x20487385: 0x00
>
> Which shows it is perfectly copied. But if try to read from 0x20487382 a
> double word (4byte), what I see in it is 0x00000002 instead of 0x00080002.
>
> Would I get this behavior any time I work on double-words that are
> misaligned in such a way?
>
> Regards,
> Bekir
>
>



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

The ARM processor can only operate on 32 bit words properly aligned in 4-by=
te boundaries.
Try : 0x20208A10 to 0x20487380/0x20487384 etc.

________________________________________
From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of=
ICLI, Bekir (EXT)
Sent: Monday, 2 June 2008 2:40 PM
To: A...@yahoogroups.com
Subject: {Disarmed} [AT91SAM] Byte/Word/Double-Word alignment in ATSAM9RL64

Hi all,=20
I am having really strange behavior, which I could not explain to myself.=20
When I do a copy from 0x20208A10 to 0x20487382, all the content is copied.=
=20
And at the memory is:=20
0x20487382: 0x02=20
0x20487383: 0x00=A0=A0=A0=A0=A0=A0=A0=20
0x20487384: 0x08=20
0x20487385: 0x00=20
Which shows it is perfectly copied. But if try to read from 0x20487382 a do=
uble word (4byte), what
I see in it is 0x00000002 instead of 0x00080002.
Would I get this behavior any time I work on double-words that are misalign=
ed in such a way?=20
Regards,=20
Bekir=20
=20
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

It is processor specific =85.. (ARM that is)

________________________________________
From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of=
Eric Haver
Sent: Monday, 2 June 2008 2:57 PM
To: A...@yahoogroups.com
Subject: {Disarmed} Re: [AT91SAM] Byte/Word/Double-Word alignment in ATSAM9=
RL64

This is a compiler question, not processor specific.
Ask in another forum.

On Mon, Jun 2, 2008 at 12:40 AM, ICLI, Bekir (EXT) com> wrote:
Hi all,=20
I am having really strange behavior, which I could not explain to myself.=20
When I do a copy from 0x20208A10 to 0x20487382, all the content is copied.=
=20
And at the memory is:=20
0x20487382: 0x02=20
0x20487383: 0x00=A0=A0=A0=A0=A0=A0=A0=20
0x20487384: 0x08=20
0x20487385: 0x00=20
Which shows it is perfectly copied. But if try to read from 0x20487382 a do=
uble word (4byte), what
I see in it is 0x00000002 instead of 0x00080002.
Would I get this behavior any time I work on double-words that are misalign=
ed in such a way?=20
Regards,=20
Bekir=20

=20
------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Actually, I do not believe it is a compiler question, I believe it's a valid
ARM implementation question.

Mis-aligned word reads will not read what you expect and on the SAM7 you
will not get an exception. On a SAM9 you will get an exception (dabort
IIRC) which you can then fix up in software.

Regards,

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
Eric Haver
Sent: 02 June 2008 05:57
To: A...@yahoogroups.com
Subject: Re: [AT91SAM] Byte/Word/Double-Word alignment in ATSAM9RL64

This is a compiler question, not processor specific.
Ask in another forum.

On Mon, Jun 2, 2008 at 12:40 AM, ICLI, Bekir (EXT)
wrote:

Hi all,

I am having really strange behavior, which I could not explain to myself.
When I do a copy from 0x20208A10 to 0x20487382, all the content is copied.
And at the memory is:

0x20487382: 0x02
0x20487383: 0x00
0x20487384: 0x08
0x20487385: 0x00

Which shows it is perfectly copied. But if try to read from 0x20487382 a
double word (4byte), what I see in it is 0x00000002 instead of 0x00080002.

Would I get this behavior any time I work on double-words that are
misaligned in such a way?

Regards,
Bekir



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Thanks for the answer microbit,

Therefore I enabled the alignment checks on addresses.
But I still do not understand why there is such a thing in ARM.
Why wouldn't I wanna read a double word (32bit) from the address
0x12943391 for example?
Is this really necessary? Doesn't it limit the capabilities of the
processor?

________________________________

Von: A...@yahoogroups.com [mailto:A...@yahoogroups.com] Im Auftrag
von microbit
Gesendet: Montag, 2. Juni 2008 08:26
An: A...@yahoogroups.com
Betreff: RE: {Disarmed} Re: [AT91SAM] Byte/Word/Double-Word alignment in
ATSAM9RL64

It is processor specific ..... (ARM that is)

________________________________________
From: A...@yahoogroups.com
[mailto:A...@yahoogroups.com ] On
Behalf Of Eric Haver
Sent: Monday, 2 June 2008 2:57 PM
To: A...@yahoogroups.com
Subject: {Disarmed} Re: [AT91SAM] Byte/Word/Double-Word alignment in
ATSAM9RL64

This is a compiler question, not processor specific.
Ask in another forum.

On Mon, Jun 2, 2008 at 12:40 AM, ICLI, Bekir (EXT)
>
wrote:
Hi all,
I am having really strange behavior, which I could not explain to
myself.
When I do a copy from 0x20208A10 to 0x20487382, all the content is
copied.
And at the memory is:
0x20487382: 0x02
0x20487383: 0x00
0x20487384: 0x08
0x20487385: 0x00
Which shows it is perfectly copied. But if try to read from 0x20487382 a
double word (4byte), what
I see in it is 0x00000002 instead of 0x00080002.
Would I get this behavior any time I work on double-words that are
misaligned in such a way?
Regards,
Bekir



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Hi,

From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of
ICLI, Bekir (EXT)
Sent: 02 June 2008 07:30
To: A...@yahoogroups.com
Subject: AW: {Disarmed} Re: [AT91SAM] Byte/Word/Double-Word alignment in
ATSAM9RL64

Thanks for the answer microbit,

Therefore I enabled the alignment checks on addresses.

But I still do not understand why there is such a thing in ARM.

Why wouldn't I wanna read a double word (32bit) from the address 0x12943391
for example?

You might *want* to.

Is this really necessary? Doesn't it limit the capabilities of the
processor?

I assume, to keep the ARM core small and fast, mis-aligned loads may not be
implemented. It is fairly common for RISC cores to require word-aligned
data. This is the cause of porting problems when dealing with code that
comes from an 8-bit background or x86 background, and especially when
dealing with communication protocols mapped to structs.

-- Paul.


(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

> Is this really necessary?=20
> Doesn't it limit the capabilities of the processor?

Yes and no.
It's in the hardwiring to the ALU. To read 4 bytes in go, you need the lowe=
st 2 bits
to address byte 0/1/2/3. So, you can therefore only address 32 bit words in=
the same cycle
on 4 byte boundaries, naturally.
There are processors that allow misalignment (such as 68K) but you lose bus=
cycles anyway
to re-align the bus.

HTH
B rgds
Kris
________________________________________
From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of=
ICLI, Bekir (EXT)
Sent: Monday, 2 June 2008 4:30 PM
To: A...@yahoogroups.com
Subject: {Disarmed} AW: {Disarmed} Re: [AT91SAM] Byte/Word/Double-Word alig=
nment in ATSAM9RL64

Thanks for the answer microbit,
=A0
Therefore I enabled the alignment checks on addresses.
But I still do not understand why there is such a thing in ARM.
Why wouldn't I wanna read a double word (32bit) from the address 0x12943391=
for example?
Is this really necessary? Doesn't it limit the capabilities of the processo=
r?

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Kris,

> Yes and no.
> It's in the hardwiring to the ALU. To read 4 bytes in go, you need the
> lowest 2 bits
> to address byte 0/1/2/3. So, you can therefore only address 32 bit
> words in the same cycle
> on 4 byte boundaries, naturally.
> There are processors that allow misalignment (such as 68K) but you lose
> bus cycles anyway to re-align the bus.

Only 68020 had this, 68000 and 68010 didn't, you just got an Address Error.
The 030 was an 020 with an MMU and tolerated misaligned loads. The 040 and
060 dropped misaligned addresses again, IIRC.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )

Thanks Paul, too long ago..

-----Original Message-----
From: A...@yahoogroups.com [mailto:A...@yahoogroups.com] On Behalf Of Paul Curtis
Sent: Monday, 2 June 2008 8:07 PM
To: A...@yahoogroups.com
Subject: RE: {Disarmed} AW: {Disarmed} Re: [AT91SAM] Byte/Word/Double-Word alignment in ATSAM9RL64

Kris,

> Yes and no.
> It's in the hardwiring to the ALU. To read 4 bytes in go, you need the
> lowest 2 bits
> to address byte 0/1/2/3. So, you can therefore only address 32 bit
> words in the same cycle
> on 4 byte boundaries, naturally.
> There are processors that allow misalignment (such as 68K) but you lose
> bus cycles anyway to re-align the bus.

Only 68020 had this, 68000 and 68010 didn't, you just got an Address Error.
The 030 was an 020 with an MMU and tolerated misaligned loads. The 040 and
060 dropped misaligned addresses again, IIRC.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of AT91SAM -- send a blank email to AT91SAM-subscribe@yahoogroups.com )