This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]