Re: C programming on ARM


"David Brown" <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:47a1a46d$0$14996$8404b019@xxxxxxxxxxxxxxxxxx
Wilco Dijkstra wrote:
"CBFalconer" <cbfalconer@xxxxxxxxx> wrote in message news:47A11649.3D617492@xxxxxxxxxxxx
Wilco Dijkstra wrote:
... snip ...
My point was that the bitpatterns of all pointer types are the
same for all addresses in the address space.
Not necessarily so. void* carries all the information, apart from
the object type. void* bitpattern is identical with the char*
bitpattern, but after that there are no limits.

You're talking about what the C language standards guarantee.
I'm talking about how compilers implement the language. On a
byte addressable architecture you can rely on the one I mentioned
above. The fact is most programs rely on this whether the standard
permits it or not...


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!

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...

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),

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.

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).

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


.

Relevant Pages

  • Re: C programming on ARM
    ... It's a fair point that there is a difference what you can rely on for real, practical C and what the standards say. ... right shifts working as expected, division rounding as expected, char ... Aside from alignment problems (which may mean that using the pointer does not "just work", even if conversions back and forth do), ... 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). ...
    (comp.arch.embedded)
  • Re: subroutine stack and C machine model
    ... the most fundamental facts about C right, *why should I listen to you*? ... Firstly he was not the only person on the standards committee, secondly he probably was not the most influential person on it, and thirdly it is only you who thinks a lot of the things you pick on should be changed. ... The programmers I know all have more sense than to rely on order of evaluation within an expression *whatever* language they are programming in, since it makes it harder for *people* to follow what is going on. ... but most compilers don't seem to prevent it. ...
    (comp.lang.c)
  • Re: (FAQ details:) malloc(), void * and casts
    ... My understanding is that recommended practice is to not cast the ... Its like recommending that you ... Many C++ compilers have vastly superior warnings ... a pointer to any other type. ...
    (comp.lang.c)
  • Re: Total order on floating point numbers
    ... I know of who has tried out overflow trapping for C signed integers. ... I don't know if they have C compilers. ... a C pointer on either a read or write operation. ... including their size, as system dependent. ...
    (comp.arch.arithmetic)
  • Re: struct initilization via memset
    ... >>will all initialize the pointer to a null pointer. ... By the time of the first ANSI C standard, C had been around for well ... over 10 years and C compilers were developed for quite a few different ... expression with a value of 0 cast to pointer to void. ...
    (alt.comp.lang.learn.c-cpp)