C programming on ARM

OK, so I was a bit short on the explanation. I meant that pointers contain no magic bits or other info besides the bit pattern of the address. Therefore you can cast an integer to a pointer and back, or a pointer to any other pointer type and back and you do not lose a single bit of information. All this is guaranteed if you have a byte addressable architecture, ie. pointer casting is safe.

Dereferencing pointers is something entirely different altogether. Not all pointers can be dereferenced, think about the null pointer, or pointers that point just beyond a variable (something C permits). Also it is never a good idea to cast a pointer to a small object to a larger one as you will corrupt memory if you access beyond the original object. Natural alignment is just another thing to take into account (however many compilers support unaligned types).

Wilco

Reply to
Wilco Dijkstra
Loading thread data ...

It's a fair point that there is a difference what you can rely on for real, practical C and what the standards say. You can happily rely on things like 2's complement arithmetic, and data sizes being 8, 16, 32,

64 bits - if you are programming a dinosaur mainframe, you are probably aware of the fact!

And often when programming, you know exactly what compiler and target you are using, and can program accordingly rather than writing generic code.

However, you *can't* rely on pointers working like you describe in general - not in embedded programming. Aside from alignment problems (which may mean that using the pointer does not "just work", even if conversions back and forth do), there are many architectures with different pointer types and different memory spaces. These don't fit well with C (which expects a single memory space), but they are the reality we live with. On an AVR Mega256, a general flash pointer will

24 bits, while a ram pointer will be 16 bits. On some architectures you get "far" and "near" pointers. There are some that have a section of bit-addressable memory, with a different pointer type. You can't rely on these things having a consistent pointer size - you should not even rely on the C requirement of a "void *" supporting them all (embedded compilers don't always follow the standards if they conflict with generating good object code for real-world source code).
Reply to
David Brown

practical C and what the standards say.

being 8, 16, 32, 64 bits - if you are

Most programs also rely on signed arithmetic not trapping, signed right shifts working as expected, division rounding as expected, char being 8-bit and ASCII...

using, and can program accordingly

not in embedded programming. Aside from

work", even if conversions back and forth

As I said derefencing is another issue altogether. Casting is not always done in order to dereference, I often use pointer casts to allow comparisons between pointers (eg. range check), to align a pointer (to avoid alignment issues!) or add an integer to a pointer etc.

spaces. These don't fit well with C

On an AVR Mega256, a general flash

architectures you get "far" and "near" pointers.

pointer type. You can't rely on these

requirement of a "void *" supporting them

with generating good object code for

But as you say C doesn't map onto these architectures, so we're not talking about standard C. Most programs won't compile for these architectures (assuming the code would fit), and if they did still wouldn't run correctly - precisely because these architectures do not support the defacto assumptions that most C programs make.

The reverse is true as well, programs written for these C dialects do not work on standard C compilers. One case that comes up often is: unsigned char c = 255; if (~c == 0) ... This is always false in standard C, but there are compilers which think it is true...

Wilco

Reply to
Wilco Dijkstra

Ever used a strict harvard architecture device like say ... an Atmel AVR? In the AVR you'll find that pointers to Flash and pointers to RAM are two entirely separate creatures. And yet, both types are byte addressable.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

If they are in the same address space. "void*" (and therefore "char*") is guaranteed to be able to point at any data item, but there still are function pointers, which can live in a completely different address space. The simplest example is our beloved i386 architecture, where data pointers can be between 16 and 48 bits, code pointers too, but not necessarily the same size as the others.

Stefan

Reply to
Stefan Reuther

practical C and what the standards say.

being 8, 16, 32, 64 bits - if you are

All of this is reasonable enough in practice. Of course, some programs also rely on "char" being signed or unsigned, or "int" being 32-bit, and other things that may be true on one commonly used compiler/target but not others.

using, and can program accordingly

not in embedded programming. Aside from

work", even if conversions back and forth

memory spaces. These don't fit well with C

On an AVR Mega256, a general flash

architectures you get "far" and "near" pointers.

different pointer type. You can't rely on these

requirement of a "void *" supporting them

with generating good object code for

C doesn't map directly onto these architectures - but that does not stop people using C for them on a regular basis! Look at the AVR, for example - it has different address spaces for flash and ram data, so the pointers are incompatible. On the larger AVRs, a full flash pointer must be 24 bits, while ram pointers are only 16 bits. Yet somehow there are vast numbers of these devices in use, almost all of them programmed in C. You certainly can't take a random C program off the internet and expect it to compile and work on an AVR, but there is no problem writing portable code that works on the 8-bit AVR, 16-bit msp430, 32-bit big-endian ColdFire, 32-bit little-endian ARM, and even some of these horrible DSP architectures with their 16-bit chars. You just have to stick to assumptions that are appropriate for embedded programming, rather than thinking "big" C.

If code like that comes up "often", you have bigger problems than just bad assumptions - that code snippet is horrible. But it is certainly true that code written for small embedded C systems often has compiler/target specific features that don't work on larger systems - code for a compiler with an extra "flash" keyword for flash-based data will clearly not compile on anything else without some changes.

Reply to
David Brown

... snip ...

True, as long as you keep it in mind. Also, bear in mind that things written to the specification of standard C will generally work everywhere. You don't need to rewrite it when porting. If you get in the habit of writing standard code, and add peculiar interface files as needed, you will avoid much rewriting in future. If nothing else well selected functions are portable to completely new applications.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

memory spaces. These don't fit well with C

with. On an AVR Mega256, a general flash

architectures you get "far" and "near" pointers.

different pointer type. You can't rely on these

requirement of a "void *" supporting them

with generating good object code for

Portability comes in two forms. In one case portability is transferring programs from one target to another. Applications that run on the desktop PC are unlikely to port to small processors like the RS08, AVR and the microchip PIC. Individual functions however might port easily with no or minimal changes.

There is another definition of portability that is not talked about enough and that is the ability to have a common language to describe a problem on a wide range of targets. The language offers portability of expression independent of the features and limitations of the target.

A lot of C99 saw that portability of expression is as important as portability of the applications. MISRA did a lot to point this out in several areas and many of their concerns were adopted. (Sorry Chris but C will steal good idea's whatever the source) One of these that we have found makes a difference is the size specific data types in addition to the natural data sizes of the processor.

Regards,

-- Walter Banks Byte Craft Limited Tel. (519) 888-6911 Fax (519) 746 6751

formatting link
snipped-for-privacy@bytecraft.com

Reply to
Walter Banks

... snip ...

While there may well be cases where those specific types are useful, I firmly believe that the first requirement is to avoid them. They usually limit portability, and the C standard guarantees for the values storable in char, short, int, long, (and even long long for C99) will usually suffice. If your source uses only these (and derived, such as struct) types portability is enhanced.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

Hi all,

The problem is solved using proper type casting.

thanks

news:fnqrev$3ei$01$ snipped-for-privacy@news.t->>

will show itself. Some of them can lie dormant

show-stoppers.

there.

you're

Reply to
aamer

memory spaces. These don't fit well with C

with. On an AVR Mega256, a general flash

architectures you get "far" and "near" pointers.

different pointer type. You can't rely on

the C requirement of a "void *"

they conflict with generating good

people using C for them on a regular basis!

ram data, so the pointers are

ram pointers are only 16 bits. Yet

programmed in C. You certainly can't take

AVR, but there is no problem writing

ColdFire, 32-bit little-endian ARM, and

just have to stick to assumptions that are

There are indeed architectures which can't fully support standard C. You can indeed write standard conforming programs on these if you avoid any of the default assumptions (casting pointers being one of them) and use macros to map the differences (assuming you know all of them).

However this illustrates the difference between "it just works" and putting a lot of effort into making it work. Most software isn't specifically written to be portable, and yet porting is surprisingly easy. You can download random source code from the internet and expect it to compile and work on ARM, MIPS, PPC, ColdFire, AVR32 or any other modern embedded architecture with minimal effort.

assumptions - that code snippet is

systems often has compiler/target specific

"flash" keyword for flash-based data

It was an example of what goes wrong when people try to port applications when moving to a different architecture, and find that their code doesn't work any more. Some 8-bit compilers apparently don't apply the standard integer promotion rules, which makes porting of all but the most trivial programs rather tricky.

Wilco

Reply to
Wilco Dijkstra

memory spaces. These don't fit well with C

with. On an AVR Mega256, a general flash

architectures you get "far" and "near" pointers.

different pointer type. You can't rely on

the C requirement of a "void *"

if they conflict with generating good

people using C for them on a regular basis!

ram data, so the pointers are

while ram pointers are only 16 bits. Yet

programmed in C. You certainly can't take

AVR, but there is no problem writing

ColdFire, 32-bit little-endian ARM, and

just have to stick to assumptions that are

It depends on how much the target differs from being a good C target, and what kind of code you are writing. For example, the AVR cannot access flash data using the same kind of pointer as ram data. If you are writing code that uses a constant table, you have three possible choices - you can waste large amounts of precious ram keeping a copy of the table, so that normal ram data pointers can be used, you can write compiler/target specific code, or you can write code that includes special wrapper functions/macros for all table access, with these being defined according to the compiler/target combination in use. None of these are practical - in reality, such code will be written using the "flash" keyword if you are using IAR, a slightly non-standard abuse of "const" if you are using ImageCraft, and "progmem" and assorted macros if you are using avr-gcc.

to

In the context of embedded development, all of these processors listed are fairly "big". They are all 32-bit processors with good support for C, and thus you can expect that code "just works". Portability issues (for general code that is not interfacing directly with hardware) come to light when using smaller or more specialised processors.

assumptions - that code snippet is

systems often has compiler/target specific

extra "flash" keyword for flash-based data

I've more often had issues with 8-bit compilers producing correct but inefficient code due to C's promotion rules, but I get the point.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.