[ECOS] newbie qn about eCos integral types
Bart Veer
bartv@ecoscentric.com
Wed Oct 18 21:42:00 GMT 2006
>>>>> "Steve" == Steve Simpson <s.simpson@genesysdesign.com.au> writes:
Steve> I'm trying to understand the intended application of the
Steve> two different styles of eCos integral types Basically how /
Steve> when should I use the cyg_(u)intXX series of definitions,
Steve> and how / when should I use the cyg_(u)countXX series of
Steve> definitions.
Steve> eg. when should I use cyg_uint8 instead of cyg_ucount8 and
Steve> vice-versa?
Steve> The notes surrounding the defintions in cyg_type.h say that
Steve> the cyg_(u)intXX series are for use with "memory and
Steve> strutures". Ok that makes sense when you look at the
Steve> typedef, but..
Steve> The comments for the cyg_(u)countXX series are that they
Steve> are for "using integers in registers for looping and the
Steve> like" The part regarding registers confuses me, since I
Steve> would have thought that a fixed width integer (aka) the
Steve> cyg_(u)intXX series are the most appropriate for accessing
Steve> *fixed width* registers.
Steve> Can anyone add a little more ligth here?
These types date back to the very early days of eCos, and were
intended to allow the system to run on 16-bit and 64-bit processors as
well as 32-bit ones. Consider two processors: a 16-bit one where both
short and int are 2 bytes, a long is 4 bytes, and 16-bit operations
are more efficient than 32-bit ones; and a 32-bit processor where a
short is two bytes, both int and long are 4 bytes, and 32-bit
arithmetic is more efficient than 16-bit.
On the 16-bit processor we will have:
typedef unsigned int cyg_uint16;
typedef unsigned int cyg_ucount16;
typedef unsigned long cyg_uint32;
typedef unsigned long cyg_ucount32;
On the 32-bit processor we will have:
typedef unsigned short cyg_uint16;
typedef unsigned int cyg_ucount16;
typedef unsigned int cyg_uint32;
typedef unsigned int cyg_ucount32;
On both processors cyg_uint16 is exactly 16 bits and cyg_uint32 is
exactly 32 bits. Hence those data types can be used reliably for
describing hardware, for defining network protocols, etc.
However cyg_ucount16 is 16 bits on the 16-bit processor and 32 bits on
the 32-bit processor. In both cases cyg_ucount16 is the most efficient
data type that provides at least the specified number of bits. In the
context of a loop:
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.
Unfortunately all of the initial eCos ports were to 32-bit processors.
Hence a lot of existing eCos code and APIs uses cyg_uint32 when it
should really be using cyg_ucount16 or cyg_ucount32.
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