Re: Delay Routine: Fully-portable C89 if possible

Hans-Bernhard Bröker wrote:
Martin Wells wrote:
John:

For example, in C99 I could define a 32 bit hardware register like
this:

#include <stdint.h>
#define PORT (*(volatile uint32_t *)(0x1FFF0000))

This will only work on implementations that actually have an unsigned
integer type that has exactly 32 value representational bits.

I suspect you'll find this hard to believe, but: that's actually a good thing. A platform that has no such type can't run that code as designed, so there's no point for it to compile on that platform. It should fail.

On other implementations, it won't compile. Best to use
uint_least32_t (at least 32-Bits).

Not in this particular case. If the platform doesn't have 32-bit integers, it can't have 32-bit hardware registers, so it shouldn't compile this code.


It's perhaps more accurate to talk about the platform "supporting" 32-bit integers - it's not clear whether you are trying to say that the cpu in question must be at least 32 bits (which is of course not the case - your code would work perfectly well on an 8-bit cpu, which regularly have 16-bit hardware registers and perhaps also 32-bit hardware registers) or just that it can work with 32-bit data (as distinct from, say, a 36-bit machine).

unsigned long is guaranteed to be atleast 32-Bit, so that's fine. If
you wanted to go easy on space consumption, you could still use C89
and use macros:

#if VALUE_BITS(char unsigned) >= 32
typedef char unsigned uint_least32_t;

It would be rather nice if a VALUE_BITS like that were a C89 standard functionality, wouldn't it? Well, sorry, it's not. And not only that: it can't even be implemented in C89. There's only CHAR_BIT (in <limits.h>), and sizeof() --- but the latter doesn't work in preprocessor instructions.

There are reasons <stdint.h> was made part of the standard. One of them is that it's quite hard to implement its functionality unless you're the compiler implementor.
.

Relevant Pages

  • Re: Delay Routine: Fully-portable C89 if possible
    ... integer type that has exactly 32 value representational bits. ... A platform that has no such type can't run that code as designed, so there's no point for it to compile on that platform. ... One of them is that it's quite hard to implement its functionality unless you're the compiler implementor. ...
    (comp.arch.embedded)
  • Re: Delay Routine: Fully-portable C89 if possible
    ... It's perhaps more accurate to talk about the platform "supporting" 32-bit integers - it's not clear whether you are trying to say that the cpu in question must be at least 32 bits (which is of course not the case - your code would work perfectly well on an 8-bit cpu, which regularly have 16-bit hardware registers and perhaps also 32-bit hardware registers) or just that it can work with 32-bit data. ... I.e. it shouldn't even compile. ... C has no way to describe an atomic access - all "volatile" gives you is a promise to read from or write to the memory system when asked, ...
    (comp.arch.embedded)
  • Re: Moving from C++ to VC++
    ... > have been bad to constrain fseek to 16 bit int offsets, so they used long, ... > for a standard type like long, ... general-purpose integer type on the platform. ...
    (microsoft.public.vc.language)
  • Re: Problem Cloning PUBLIC directory
    ... you must remove the feature from your platform and ... rebuild, otherwise, the binaries from the old PUBLIC atadisk driver still ... >I fixed the SOURCES file and now everything compiles correctly. ... >>> PlatformBuilder 5.0 and having some problems getting it to compile. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: how to detect the compile is 32 bits or 64 bits?
    ... determined by whether you have a 32- or 64-bit platform. ... Suppose I have an algorithm, such as a cryptography algorithm, that ... but the chunk size differs for the two cases. ... available at compile time increases compiler optimization opportunities ...
    (comp.lang.c)