This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: eCos integral types
- From: "Steve Simpson" <s dot simpson at genesysdesign dot com dot au>
- To: "ecos-discuss at sourceware dot org" <ecos-discuss at sourceware dot org>
- Date: Thu, 19 Oct 2006 09:37:42 +1000
- Subject: [ECOS] RE: eCos integral types
Thanks Bart,
So summarising from your comments below:
- The *countn* series SHOULD be used for general arithemetic and masking operations where all that is required is a type of width at least n.
- The *intn* series SHALL be used where the width of the type must be n. ie. pointer / memory / register oriented operations
I'm still puzzling about the comments in the source regarding the use of the *countn* series with registers.
The full comment is
"
// -------------------------------------------------------------------------
// Define types for ****** using integers in registers ****** for looping and the like;
// depends on CPU type, choose what it is most comfortable with, with at
// least the range required.
typedef unsigned cyg_halcount8 cyg_ucount8 ;
typedef signed cyg_halcount8 cyg_count8 ;
typedef unsigned cyg_halcount16 cyg_ucount16 ;
typedef signed cyg_halcount16 cyg_count16 ;
typedef unsigned cyg_halcount32 cyg_ucount32 ;
typedef signed cyg_halcount32 cyg_count32 ;
typedef unsigned cyg_halcount64 cyg_ucount64 ;
typedef signed cyg_halcount64 cyg_count64 ;
"
Maybe the wording is unclear??
Cheers,
Steve
>> >>>>> "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
--
----------------------------------------------------
Steve Simpson
Genesys Design Pty Ltd
Unit 5, 33 Ryde Road
Pymble NSW 2073
AUSTRALIA
ph: +61 2 9499 7677
fax: +61 2 9499 7877
email: s.simpson@genesysdesign.com.au
www: http://www.genesysdesign.com.au/
----------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss