Re: Delay Routine: Fully-portable C89 if possible



John Devereux wrote:
David Brown <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:

[...]

Secondly, I was suggesting that if you want portable code, you have to
use size-specific integer types. Using <stdint.h> is an easy way to
get that - otherwise, a common format header file that is adapted for
the compiler/target in question is a useful method. It doesn't really
matter whether you use "uint32_t" from <stdint.h>, or have a "typedef
unsigned long int uint32_t" in a common header file - nor does it
matter if you give the type your own name. But it *does* matter that
you have such types available in your code.

Certainly many of the situations where size specifics are important
are in hardware dependant and non-portable - and thus the only issue
is that the code in question is clear.

But there are many cases where you need a minimum range which may not
be satisfied by "int" on every platform, and also where you want the
fastest implementation. If you have a function
delayMicrosecs(unsigned int n), then the useful range is wildly
different on a 32-bit target and a 16-bit (or 8-bit, with 16-bit int)
target. On the other hand, if it is declared with "uint32_t n", it is
portable from 8-bit to 64-bit processors. Since the OP was asking for
portable code in an embedded newsgroup, there's no way he can make
assumptions about the size of "int".

If I wanted a minimum range of 32 bits, I would use "unsigned
long". As you know this is already guaranteed to be at least 32 bits
on all platforms, so I don't think there is any portability problem
with 8,16 and 32 bit processors.


"unsigned long int" will, as you say, work for when you need at least 32 bits, and "unsigned int" will work for when you need at least 16 bits. I prefer to be more specific and explicit - I find I often want my types to be of a given width, neither more nor less than I specify. I'll grant you that this is somewhat a matter of style - but I am not alone in this (it takes a big demand to get something like <stdint.h> into the standards).

Now I admit that these are the only cases I think about when writing
my own embedded code. But I suppose you could argue that on some
hypothetical 64 bit embedded processor, I would then be using values
that were longer than needed. But,


The 64-bit MIPs processors are non-hypothetical embedded processors (although they are not common in this newsgroup).

- with 64 bit CPUs, is it not true that the compilers still tend to
have 32 bit longs, and use "long long" for 64 bits?


That varies. "long long int" is always at least 64 bits, but there are different models for whether "long int" is 32-bit or 64-bit. In particular, 64-bit Windows uses 32-bit long ints, while 64-bit Linux uses 64-bit long ints. It is also perfectly possible for both "int" and "long int" to be 64-bit, but I think that is uncommon.

- If longs *are* 64 bits, it could be because 32 bit operations are
*slower* on that processor. Strictly, I think there might not even
*be* a 32 bit type - unlikely, I agree.


As you say, possible but unlikely. I don't agree with your thoughts as to why "long int" might be 32-bit or 64-bit - the trouble is, different implementations of the same instruction set might have different balances (the first Intel chips to support amd64 instructions were, IIRC, quite a bit slower at 64-bit arithmetic, while the AMD chips were faster in 64-bit mode).

- On a 64 bit system, it is very likely that I would want to take
advantage of the greater word size and use 64 bit arguments in any
case.


For most of my work, I use 8 and 16 bit systems, but I sometimes use 32-bit cpus (some with 16-bit external buses, making 16-bit ints faster for some purposes) - thus I have the same situation when using 32-bit cpus as you describe for 64-bit cpus.
.



Relevant Pages

  • Re: changeable structures
    ... This is a common issue and relates to message handling. ... Many message formats have a header field which identifies ... int aa; ... C++ Faq: http://www.parashift.com/c++-faq-lite ...
    (comp.programming)
  • Re: A question
    ... even though that is the most common size of integer in my ... C standard is not the only text in the world, ... I do not see why you are so afraid of assuming that what I called "integer" is in fact "int" in C, even though I DID make a connection to the actual declaration of that int * in the part of my message you snipped out. ... "It is easy in the world to live after the world's opinion; it easy in solitude to live after our own; but the great man is he who in the midst of the crowd keeps with perfect sweetness the independence of solitude." ...
    (comp.lang.c)
  • Re: Common misconceptions about C (C95)
    ... a variadic functions are subject to "the default argument ... In a normal language you need to convert the index at compile or at ... And today, an int has 32 bits because today, 64 bits are in common use ...
    (comp.lang.c)
  • Re: Natural size: int
    ... the following setup is common: ... "char" is commonly used to store text characters. ... "int" is commonly used to store an integer. ...
    (comp.lang.c)
  • Re: Date problem
    ... in the database there is stored the year (as int) and the month. ... Now, when retrieving datasets from the database, of course, '1' means 'JANUARY'. ... When I want to print a notification/bill, I want to say "The dues have to be paid until 15 of January 2007". ... the common '0' makes as much sense as defining JANUARY as something other that the common '1'. ...
    (comp.lang.java.programmer)