CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Fixed Point Integers with Nested Unions and Structures

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
grifcj



Joined: 12 Oct 2009
Posts: 4

View user's profile Send private message

Fixed Point Integers with Nested Unions and Structures
PostPosted: Thu Nov 12, 2009 12:48 am     Reply with quote

I'm trying to code 8.8 fixed point integers. Yes, I think I read somewhere that CCS has intrinsic support for this data type, but I'm doing this for a class, so I'd like to learn a method that will be portable.

My problem is that CCS doesn't seem to be handling the bit fields in my structure correctly. In fact, it looks like the generated assembly is faulty. My compiler version is 4.041.

Here's my nested union/struct definition. You may recognize it from an embedded.com article.
Code:

// Signed fixed point integer.
// Range -128 to (127 - 2^8)
// Granularity 1/2^8 = .0039
union SFIXED8_8tag {

   int16_t full;
   struct spart8_8tag {
      int16_t decimal:8;
      int16_t integer:8;
   } part;
};
typedef union SFIXED8_8tag int8_8_t;

Here's the generated assembly listing for one of these unions in action. Variable nDegrees is of type int8_8_t (the above union) at addresses 0x18:0x19. wAccX is just some uin16_t variable located at 0x4B:0x4c.

For the first C line, it functions as expected, copying two bytes. For the second and third lines of C code, it seems to mess up. You'll notice from the definition that the bitfields are 8 bits long, so it shouldn't be moving 2 bytes for the assignment. Also, for the second C line, it grabs data from a completely different variable at address 0x1A.
Code:

....................    wAccX = nDegrees.full;
0162:  MOVFF  19,4C
0166:  MOVFF  18,4B
....................    wAccX = nDegrees.part.integer;
016A:  MOVFF  1A,4C
016E:  MOVFF  19,4B
....................    wAccX = nDegrees.part.decimal;
0172:  MOVFF  19,4C
0176:  MOVFF  18,4B

I suppose I might be able to come up with some workarounds, but I would like to know what's going here.
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Thu Nov 12, 2009 3:57 am     Reply with quote

I agree, that the PCH handling of the int16 xx:8 bitfields isn't according to the C standard. You can even do worse by coding
Code:
nDegrees.part.integer = wAccX;

It's writing out of bounds, which is a severe bug that must never happen to a C compiler, whatever possibly incompatible types have been assigned by the programmer. The bug is still present in V4.099, by the way.

Apart from this inacceptable bug, the below definition should work for your purpose
Code:
   struct {
      int8 decimal;
      int8 integer;
   } part8;
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group