A question about the data type of rtems
joel.sherrill at OARcorp.com
Mon Oct 13 15:39:05 UTC 2008
Ralf Corsepius wrote:
> On Mon, 2008-10-13 at 15:09 +0200, Thomas Doerfler wrote:
>> PowerMan wrote:
>>> 3. If so, I found some driver uses "int",
>>> Would that make some problems to portability?
>> It depends. "int" should the the integral data type that the target CPU
>> can process as fast as possible (more or less). So it makes sense to use
>> the type "int" for "small" counter loops and similar things.
> Not necessarily:
> - there are cases when counter loops need to have different sizes than
> "ints", e.g. "unsigned ints" or iterations over array indexes (These
> internally are size_t or ssize_t).
> - there are cases when using smaller types than int's can provide faster
> iterations/better code (Nowadays, GCC often does this kind of
> optimization by itself)
> - All [u]int<size>_t types are typedefs to ordinal types. I.e. compiler
> optimization-wise using them instead of "ordinal types" rarely make a
In general terms, it is better to be stronger typed so your code
uses types that are the required size independent of the target
architecture. Sometimes this might pay a slight penalty but
the compiler will do its best and often surprises you with the
quality of the code generated.
I am in the middle of a (as an unpaid hobby) port to the M32C. It has
native 16-bit ints and 24-bit pointers. I am seeing both sides
of the issue. Some code uses int which is not as wide on
this architecture. Other code uses int32_t and uint32_t when
you really needed only 8 or 16 bit values. This causes inefficiency.
It is better to use the strict type and let the compiler worry.
>> E.g: PowerPC has 32 bit internal registers. there are no arithmetic
>> operations for smaller portions than 32 bit.
> Conversely on the SHes. Some variants of them have very fast 8bit and/or
> 16bit operations, which take less cpu-cycles than 32bit operations.
> Fortunately, in many cases (e.g. loops with constant bounds) GCC is able
> to optimize them to efficient asm.
> rtems-users mailing list
> rtems-users at rtems.com
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users