Wilco Dijkstra wrote:> "CBFalconer" <cbfalconer@yahoo.com> wrote in message news:47A11649.3D617492@yahoo.com... >> 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! 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).
C programming on ARM
Started by ●January 30, 2008
Reply by ●January 31, 20082008-01-31
Reply by ●January 31, 20082008-01-31
"Grant Edwards" <grante@visi.com> wrote in message news:13q263sdle28k54@corp.supernews.com...> On 2008-01-31, Wilco Dijkstra <Wilco_dot_Dijkstra@ntlworld.com> wrote: >> >> "Grant Edwards" <grante@visi.com> wrote in message news:13q21msqkij3dbb@corp.supernews.com... >>> On 2008-01-30, Wilco Dijkstra <Wilco_dot_Dijkstra@ntlworld.com> wrote: >>> >>>> Actually most architectures are byte addressable, including ARM, >>> >>> True, but many of them (ARM, SPARC, MSP430, ...) have alignment >>> requirements for objects larger than 1 byte in size. >> >> Byte addressability refers to the smallest unit of >> addressability, not to the coursest. > > I know. > >>>> so casting pointers just works. > > I think the disconnect is in what you meant by "just works". We > assumed you meant it resulted in a pointer that could be > dereferences. Apparently you meant that it could be cast to > someother type, then cast back to the original type and result > in the same pointer?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 by ●January 31, 20082008-01-31
"David Brown" <david@westcontrol.removethisbit.com> wrote in message news:47a1a46d$0$14996$8404b019@news.wineasy.se...> Wilco Dijkstra wrote: >> "CBFalconer" <cbfalconer@yahoo.com> wrote in message news:47A11649.3D617492@yahoo.com... >>> 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
Reply by ●January 31, 20082008-01-31
Paul Keinanen wrote:> With any byte addressable architecture, a pointer is just > a pointer.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 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." "Already Gone" by Jack Tempchin (recorded by The Eagles) The Beatles were wrong: 1 & 1 & 1 is 1
Reply by ●January 31, 20082008-01-31
Wilco Dijkstra wrote:> "Grant Edwards" <grante@visi.com> wrote in message news:13q21msqkij3dbb@corp.supernews.com... >>>so casting pointers just works. >> >>Unless the resulting pointer is misaligned. > > Or the pointer is aligned but points to the wrong place, or invalid memory, > or a peripheral, or ... If you don't know what you're doing then pointer > casting is likely the least of your problems. > > My point was that the bitpatterns of all pointer types are the same for > all addresses in the address space.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 by ●January 31, 20082008-01-31
Wilco Dijkstra wrote:> "David Brown" <david@westcontrol.removethisbit.com> wrote in message news:47a1a46d$0$14996$8404b019@news.wineasy.se... >> Wilco Dijkstra wrote: >>> "CBFalconer" <cbfalconer@yahoo.com> wrote in message news:47A11649.3D617492@yahoo.com... >>>> 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... >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.>> 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. >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.> 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... >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 by ●January 31, 20082008-01-31
Wilco Dijkstra wrote:> "David Brown" <david@westcontrol.removethisbit.com> wrote: >... snip ...> >> 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...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]: <http://cbfalconer.home.att.net> Try the download section. -- Posted via a free Usenet account from http://www.teranews.com
Reply by ●February 1, 20082008-02-01
Wilco Dijkstra wrote:> > 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...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 http://www.bytecraft.com walter@bytecraft.com
Reply by ●February 1, 20082008-02-01
Walter Banks wrote:>... snip ...> > 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.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]: <http://cbfalconer.home.att.net> Try the download section. -- Posted via a free Usenet account from http://www.teranews.com
Reply by ●February 4, 20082008-02-04
Hi all, The problem is solved using proper type casting. thanks> >"Hans-Bernhard Br?" <HBBroeker@t-online.de> wrote in messagenews:fnqrev$3ei$01$1@news.t-online.com...>> Paul Keinanen wrote: >> >>> In which case would an arbitrary pointer casting be a problem ? >> >> Roughly all of them. The real question is how violently the problemwill show itself. Some of them can lie dormant>> for a decade before a platform change exposes them as totalshow-stoppers.>> >>> With any byte addressable architecture, a pointer is just a pointer. >> >> But there are quite a few non-byte addressable architectures outthere.>> Including ARM, last I checked. > >Actually most architectures are byte addressable, including ARM, so >casting pointers just works. Of course it's essential to know whatyou're>doing - well written programs rarely need pointer casts. > >Wilco > > >