[ECOS] newbie qn about eCos integral types
Bart Veer
bartv@ecoscentric.com
Thu Oct 19 10:02:00 GMT 2006
>>>>> "Paul" == Paul D DeRocco <pderocco@ix.netcom.com> writes:
>> for (i = 0; i < 32768; i++) {
>> ...
>> }
>>
>> If i has type cyg_uint16 then that would be optimal on the 16-bit
>> processor but not on the 32-bit one. If i has type cyg_uint32 then
>> that would be optimal on the 32-bit processor but not the 16-bit one.
>> If i has type cyg_ucount16 then that would be optimal on both
>> processors.
Paul> Sounds like a good application for "int" or "unsigned int".
Paul> Having a type alias for a 32-bit integer with "16" in its
Paul> name is pretty confusing, leading to questions like this.
Strictly cyg_count16 and cyg_ucount16 are redundant since the standard
defines int and unsigned int to be at least 16 bits. cyg_ucount32 is
necessary since depending on the processor an int may not be 32 bits
or a long may be > 32 bits. cyg_ucount64 is also needed, it may be
mapped to either a long or a long long. cyg_ucount8 copes with the
theoretical case where a processor can perform 8-bit arithmetic faster
than 16-bit so there is a more efficient data type than int. Defining
cyg_ucount8, cyg_ucount32, and cyg_ucount64 but not cyg_ucount16 would
be inconsistent.
It can also be argued that using cyg_ucount16 rather than unsigned int
shows that the programmer has thought about the issues and has decided
that 16 bits of precision suffice. That kind of information can be
useful when maintaining code.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
More information about the Ecos-discuss
mailing list