Sign in

Not a member? | Forgot your Password?

Search Comp.Arch.Embedded

Search tips

Free PDF Downloads

Advanced Linux Programming

What Every Programmer Should Know About Memory

Introduction to Embedded Systems

C++ Tutorial

Embedded Systems - Theory and Design Methodology

Microcontroller Programming and Interfacing

Introduction to Microcontrollers


More Free PDF Downloads

Recent Blogs on EmbeddedRelated

Optimizing Optoisolators, and Other Stories of Making Do With Less
posted by Jason Sachs


Coding - Step 0: Setting Up a Development Environment
posted by Stephen Friederichs


Ada - 7 Segments and Catching Errors
posted by Mike Silva


OOKLONE: a cheap RF 433.92MHz OOK frame cloner
posted by Fabien Le Mentec


Practical protection against dust and water (i.e. IP protection)
posted by Dr Cagri Tanriover


Introduction to Microcontrollers

1 - Beginnings

2 - Further Beginnings

3 - Hello World

4 - More On GPIO

5 - Interrupts

6 - More On Interrupts

7 - Timers

8 - Adding Some Real-World Hardware

9 - More Timers and Displays

10 - Buttons and Bouncing

11 - Button Matrix & Auto Repeating

12 - Driving WS2812 RGB LEDs

13 - 7-segment displays & Multiplexing

See Also

ElectronicsDSPFPGA

Discussion Groups | Comp.Arch.Embedded | gcc compiler and byte / word alignment

There are 13 messages in this thread.

You are currently looking at messages 1 to 10.


So far in December, you have voted 0 times ou of a total of 5 votes by the community.
Please help us clean the archives from unuseful discussion threads by using the voting system! Details here.

gcc compiler and byte / word alignment - Fred - 2005-10-17 05:25:00

A newbie question I'm afraid.

LPC2294 ARM

I am trying to read a word, ie a short int, from an ethernet controller. 
It's in 8 but mode and can't do much about it at the moment.

    unsigned short *ptr
//say read from device
    *(ptr + OFFSET)

The BCFG2 is set up 8 bit mode.

When compiled, the value of "OFFSET" is doubled, and the data fetch command 
is "ldrh r3, [r3]".

Why does gcc double "OFFSET"?  There's no need for this even in word 
fetches!

Does "ldrh" expect a word aligned peripheral?  Would there normally be 2 - 
byte fetches or a single erroneous word fetch?

Sorry if this has an obvious answer. 



Re: gcc compiler and byte / word alignment - Paul Black - 2005-10-17 05:39:00

Fred wrote:
> A newbie question I'm afraid.
> 
> LPC2294 ARM
> 
> I am trying to read a word, ie a short int, from an ethernet controller. 
> It's in 8 but mode and can't do much about it at the moment.
> 
>     unsigned short *ptr
> //say read from device
>     *(ptr + OFFSET)
> 
> The BCFG2 is set up 8 bit mode.
> 
> When compiled, the value of "OFFSET" is doubled, and the data fetch command 
> is "ldrh r3, [r3]".
> 
> Why does gcc double "OFFSET"?  There's no need for this even in word 
> fetches!

Because it's treating ptr as an array of unsigned shorts.

Suppose ptr is 0x1234.
If OFFSET is 0, addresses 0x1234 and 0x1235 are accessed for the short.
If OFFSET is 1, addresses 0x1236 and 0x1237 are accessed.
If OFFSET is 2, addresses 0x1238 and 0x1239 are accessed.

Because GCC knows how big a short is (in this case it's two bytes), it
will know that the bytes accessed in the C construct "*(ptr + OFFSET)"
are located at addresses
"ptr + OFFSET * 2" and "ptr + OFFSET * 2 + 1".


-- 
Paul Black                        mailto:p...@oxsemi.com
Oxford Semiconductor Ltd          http://www.oxsemi.com
25 Milton Park, Abingdon,         Tel: +44 (0) 1235 824 909
Oxfordshire.    OX14 4SH          Fax: +44 (0) 1235 821 141

Re: gcc compiler and byte / word alignment - Fred - 2005-10-17 08:13:00

"Paul Black" <n...@nospam.oxsemi.com> wrote in message 
news:divrf2$65f$1...@jupiter.oxsemi.com...
> Fred wrote:
>> A newbie question I'm afraid.
>>
>> LPC2294 ARM
>>
>> I am trying to read a word, ie a short int, from an ethernet controller.
>> It's in 8 but mode and can't do much about it at the moment.
>>
>>     unsigned short *ptr
>> //say read from device
>>     *(ptr + OFFSET)
>>
>> The BCFG2 is set up 8 bit mode.
>>
>> When compiled, the value of "OFFSET" is doubled, and the data fetch 
>> command
>> is "ldrh r3, [r3]".
>>
>> Why does gcc double "OFFSET"?  There's no need for this even in word
>> fetches!
>
> Because it's treating ptr as an array of unsigned shorts.
>
> Suppose ptr is 0x1234.
> If OFFSET is 0, addresses 0x1234 and 0x1235 are accessed for the short.
> If OFFSET is 1, addresses 0x1236 and 0x1237 are accessed.
> If OFFSET is 2, addresses 0x1238 and 0x1239 are accessed.
>
> Because GCC knows how big a short is (in this case it's two bytes), it
> will know that the bytes accessed in the C construct "*(ptr + OFFSET)"
> are located at addresses
> "ptr + OFFSET * 2" and "ptr + OFFSET * 2 + 1".
>
>
> -- 

I see - yes.  Thought I might have been a little dense.

Can this ARM processor fetch a word in two byte-wide fetches?  Just that I 
know of others which do.  Or must word fetches be from word or 32bit wide 
sources?

Conversely, it has byte lanes which can write a single byte in a 32bit wide 
memory configuration. 



Re: gcc compiler and byte / word alignment - Andrew Jackson - 2005-10-17 08:52:00

> Can this ARM processor fetch a word in two byte-wide fetches?  Just
> that I know of others which do.  Or must word fetches be from word or
> 32bit wide sources?

If you disable half-word accesses then the ARM will fetch a half-word as two
bytes. Whether you *want* this behaviour is another matter!

You want to declare your pointers to hardware registers as volatile too to
avoid the compiler optimising away accesses.

    Andrew




Re: gcc compiler and byte / word alignment - 2005-10-17 10:39:00

Yep, there are variety of subtle punishments in store for treating the
C compiler as a macro assembler...  at times it can be downright
stubborn about insisting that you don't know the architecture better
than it does - convincing it that you do, to the point of making all
the warnings go away, takes just the right declarations.


Re: gcc compiler and byte / word alignment - Wilco Dijkstra - 2005-10-17 17:23:00

"Fred" <f...@nowhere.com> wrote in message 
news:4353956a$0$323$d...@news.zen.co.uk...
>
> "Paul Black" <n...@nospam.oxsemi.com> wrote in message 
> news:divrf2$65f$1...@jupiter.oxsemi.com...
>> Fred wrote:

> Can this ARM processor fetch a word in two byte-wide fetches?  Just that I 
> know of others which do.  Or must word fetches be from word or 32bit wide 
> sources?

A word is 32 bits in the ARM world and must be word-aligned. A half-word
is 16 bits and must be half-word aligned. The LPC2294 is an ARM7tdmi
MCU and thus doesn't support unaligned accesses in hardware.

Compilers for ARM typically support unaligned (or packed) pointers which
have no alignment requirement. If a CPU doesn't support unaligned accesses
directly in hardware, they are split up into a sequence of reads/writes,
shifts and masking operations - this is obviously slow and so should avoided
as much as possible. Note there is no guarantee compilers produce exactly
2 byte reads for an unaligned half-word access (in the order you wanted) -
this means that it is incorrect to use packed pointers on peripherals.

So if your peripheral doesn't support aligned halfword accesses the only way
to read 2 bytes is to use 2 volatile byte reads and do the masking yourself.
However I would be surprised if any peripheral on the LPC was like that...

Wilco 



Re: gcc compiler and byte / word alignment - Grant Edwards - 2005-10-17 23:04:00

On 2005-10-17, Wilco Dijkstra <W...@ntlworld.com> wrote:

>> Can this ARM processor fetch a word in two byte-wide fetches?
>> Just that I know of others which do.  Or must word fetches be
>> from word or 32bit wide sources?
>
> A word is 32 bits in the ARM world and must be word-aligned. A
> half-word is 16 bits and must be half-word aligned. The
> LPC2294 is an ARM7tdmi MCU and thus doesn't support unaligned
> accesses in hardware.
>
> Compilers for ARM typically support unaligned (or packed)
> pointers which have no alignment requirement. If a CPU doesn't
> support unaligned accesses directly in hardware, they are
> split up into a sequence of reads/writes, shifts and masking
> operations - this is obviously slow and so should avoided as
> much as possible.

And remember that this only works when the compiler _knows_ the
pointer is misaligned.  If you pass a misaligned pointer to a
function that was declared as taking a word or half-word
pointer, it's not going to work.  

Been there, done that.  :/

-- 
Grant Edwards                   grante             Yow!  I would like to
                                  at               urinate in an OVULAR,
                               visi.com            porcelain pool --

Re: gcc compiler and byte / word alignment - Fred - 2005-10-18 06:33:00

"Andrew Jackson" <a...@nospam.com> wrote in message 
news:H...@eclipse.net.uk...
>> Can this ARM processor fetch a word in two byte-wide fetches?  Just
>> that I know of others which do.  Or must word fetches be from word or
>> 32bit wide sources?
>
> If you disable half-word accesses then the ARM will fetch a half-word as 
> two
> bytes. Whether you *want* this behaviour is another matter!
>
> You want to declare your pointers to hardware registers as volatile too to
> avoid the compiler optimising away accesses.
>
>    Andrew
>
>

Many thanks.

Yes I forgot about volatile variables etc.

I would have thought setting the BCFG register to be 8 bit memory width 
would have inherently forced byte access.  What you're suggesting is to use 
the switch for all half-word accesses, something I really don't want to do. 
Where is this switch? 



Re: gcc compiler and byte / word alignment - Fred - 2005-10-18 06:42:00

"Wilco Dijkstra" <W...@ntlworld.com> wrote in message 
news:iDU4f.2669$W...@newsfe4-gui.ntli.net...
>
> "Fred" <f...@nowhere.com> wrote in message 
> news:4353956a$0$323$d...@news.zen.co.uk...
>>
>> "Paul Black" <n...@nospam.oxsemi.com> wrote in message 
>> news:divrf2$65f$1...@jupiter.oxsemi.com...
>>> Fred wrote:
>
>> Can this ARM processor fetch a word in two byte-wide fetches?  Just that 
>> I know of others which do.  Or must word fetches be from word or 32bit 
>> wide sources?
>
> A word is 32 bits in the ARM world and must be word-aligned. A half-word
> is 16 bits and must be half-word aligned. The LPC2294 is an ARM7tdmi
> MCU and thus doesn't support unaligned accesses in hardware.
>
The half-word is half-word aligned albeit on an 8 bit bus.

> Compilers for ARM typically support unaligned (or packed) pointers which
> have no alignment requirement. If a CPU doesn't support unaligned accesses
> directly in hardware, they are split up into a sequence of reads/writes,
> shifts and masking operations - this is obviously slow and so should 
> avoided
> as much as possible. Note there is no guarantee compilers produce exactly
> 2 byte reads for an unaligned half-word access (in the order you wanted) -
> this means that it is incorrect to use packed pointers on peripherals.
>
> So if your peripheral doesn't support aligned halfword accesses the only 
> way
> to read 2 bytes is to use 2 volatile byte reads and do the masking 
> yourself.
> However I would be surprised if any peripheral on the LPC was like that...
>

Temporarily I have used byte access and concatenated the bytes.  However 
this really isn't an ideal and is a slow solution.  I've been looking 
through the datasheets and can't see any proviso that a half-word read won't 
access a variable on an 8 bit bus. 



Re: gcc compiler and byte / word alignment - Fred - 2005-10-18 06:43:00

"Grant Edwards" <g...@visi.com> wrote in message 
news:1...@corp.supernews.com...
> On 2005-10-17, Wilco Dijkstra <W...@ntlworld.com> wrote:
>
>>> Can this ARM processor fetch a word in two byte-wide fetches?
>>> Just that I know of others which do.  Or must word fetches be
>>> from word or 32bit wide sources?
>>
>> A word is 32 bits in the ARM world and must be word-aligned. A
>> half-word is 16 bits and must be half-word aligned. The
>> LPC2294 is an ARM7tdmi MCU and thus doesn't support unaligned
>> accesses in hardware.
>>
>> Compilers for ARM typically support unaligned (or packed)
>> pointers which have no alignment requirement. If a CPU doesn't
>> support unaligned accesses directly in hardware, they are
>> split up into a sequence of reads/writes, shifts and masking
>> operations - this is obviously slow and so should avoided as
>> much as possible.
>
> And remember that this only works when the compiler _knows_ the
> pointer is misaligned.  If you pass a misaligned pointer to a
> function that was declared as taking a word or half-word
> pointer, it's not going to work.
>
> Been there, done that.  :/
>
> -- 

The pointer is definitely half-word aligned.



| 1 | |