Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > 3-byte ints

Reply
Thread Tools

3-byte ints

 
 
Jack Klein
Guest
Posts: n/a
 
      09-24-2003
On Tue, 23 Sep 2003 09:19:37 -0500, Ed Morton
<(E-Mail Removed)> wrote in comp.lang.c:

> I have 2 counters - one is required to be a 2-byte variable while the


That would 32 bits on one compiler I use, and 64 bits on another.

> other is required to be 3 bytes (not my choice, but I'm stuck with it!).


This would be 48 bits on one compiler I use, and 96 bits on another.

Since a byte in C must have at least 8 bits but may have more, and
does on some architectures, if you mean "16 bits" and "24 bits", say
that. 2 bytes means "at least 16 bits, but possibly more" and 3 bytes
means "at least 24 bits, but possible more".

If you mean 16 bits and 24 bits, say so. There are architectures I
work with where both would fit into a byte.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
 
Reply With Quote
 
 
 
 
Jack Klein
Guest
Posts: n/a
 
      09-24-2003
On Wed, 24 Sep 2003 13:45:53 +1000, "Simon Biber"
<(E-Mail Removed)> wrote in comp.lang.c:

> "Ed Morton" <(E-Mail Removed)> wrote:
> > So, if I use:
> >
> > unsigned long large: 24;

>
> It's not portable to use 'unsigned long' as the base type for a bitfield; the
> only portable types are 'int' and 'unsigned int'.
>
> > then the code may not work on my original platform and, even if it does, it
> > isn't portable, right? What kind of problems could I expect to see? Is there
> > any way to test whether or not I actually have a problem?

>
> You need to know the exact binary format expected, then conform to it.
>
> A 24-bit bitfield will probably still take up four bytes, and you have no
> control over exactly where and in what order the 24 bits are stored.


On a Motorola 56000 it will fit perfectly in 1 byte, which happens to
have exactly 24 bits.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
 
Reply With Quote
 
 
 
 
Jack Klein
Guest
Posts: n/a
 
      09-24-2003
On 23 Sep 2003 17:40:50 -0700, http://www.velocityreviews.com/forums/(E-Mail Removed) (Peter Nilsson) wrote
in comp.lang.c:

> "Simon Biber" <(E-Mail Removed)> wrote in message news:<3f708588$0$4189$(E-Mail Removed) u>...
> > "Ed Morton" <(E-Mail Removed)> wrote:
> > > I have to pass this structure to some other code that's expecting
> > > several fields each to be exactly 3 bytes.

> >
> > Most C implementations do not support exact 3 byte integer types.

>
> Do any?
>
> > If it needs to be laid out exactly so in memory, you can create
> > an array of unsigned characters.
> >
> > void pack(unsigned char *three, unsigned long value)
> > {
> > assert(value < (1UL << 24));
> > three[0] = value & 0xFF;
> > three[1] = value >> 8 & 0xFF;
> > three[2] = value >> 16 & 0xFF;
> > }
> >
> > unsigned long unpack(unsigned char *three)
> > {
> > return (unsigned long)three[0]
> > | (unsigned long)three[1] << 8
> > | (unsigned long)three[2] << 16;
> > }
> >
> > These functions assume you will be packing 8 bits into each byte,

>
> Why? I know we live in an octet world, but you can do this portably
> with CHAR_BIT and UCHAR_MAX.
>
> > and using a little-endian packing layout.


Actually even when an implementation has CHAR_BIT > 8, it is quite
easy and useful to write code using just 8 bits in an unsigned char,
and far more portable. Also, living in a octet-oriented world of
communications standards, it is often necessary to handle individual 8
bit quantities as individual items.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
 
Reply With Quote
 
R Pradeep Chandran
Guest
Posts: n/a
 
      09-24-2003
On Wed, 24 Sep 2003 04:14:05 GMT, in comp.lang.c, Jack Klein wrote:
:On Tue, 23 Sep 2003 09:19:37 -0500, Ed Morton
:<(E-Mail Removed)> wrote in comp.lang.c:
:
:> I have 2 counters - one is required to be a 2-byte variable while the
:
:That would 32 bits on one compiler I use, and 64 bits on another.
:
:> other is required to be 3 bytes (not my choice, but I'm stuck with it!).
:
:This would be 48 bits on one compiler I use, and 96 bits on another.

<snip>

Which are those compilers and their corresponding target platforms?
Could you please post some details of them? It is not that I don't
believe you. But, A lot of my colleagues and friends don't believe in
CHAR_BIT != 8 and I would really like to point out these cases to them.

Have a nice day,
Pradeep
--
R Pradeep Chandran pradeep DOT chandran AT sisl.co.in
All opinions are mine and do not represent those of my employer.
 
Reply With Quote
 
Ed Morton
Guest
Posts: n/a
 
      09-24-2003
Based on the feedback, I'll declare my variables without bitfields and
test them for overflow as Mark suggested, and then pack then into an
array of unsigned chars as Simon suggested when I need to send them to
the code I interface with.

Unsigned short and unsigned long are guaranteed to be 16 bits and 32
bits respectively on this and any future platform this code will run on
as it's adding to a large existing base that depends on those sizes.

Thanks to all who replied.

Ed.



 
Reply With Quote
 
Mark Gordon
Guest
Posts: n/a
 
      09-24-2003
On Wed, 24 Sep 2003 13:05:29 +1000
"Simon Biber" <(E-Mail Removed)> wrote:

> "Peter Nilsson" <(E-Mail Removed)> wrote:
> > "Simon Biber" <(E-Mail Removed)> wrote:
> > > Most C implementations do not support exact 3 byte integer types.

> >
> > Do any?

>
> I don't know of any, but I've learnt not to make generalisations on
> comp.lang.c as someone inevitably provides an example to the contrary.


I know of (but have not used) a 24 bit processor which has a C compiler
available for it. Specifically the Motorola DSP56000. I would assume
that int is 24 bits and it is even possible that char could be 24 bits!
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
 
Reply With Quote
 
Jack Klein
Guest
Posts: n/a
 
      09-26-2003
On Wed, 24 Sep 2003 16:20:13 +0530, R Pradeep Chandran <(E-Mail Removed)>
wrote in comp.lang.c:

> On Wed, 24 Sep 2003 04:14:05 GMT, in comp.lang.c, Jack Klein wrote:
> :On Tue, 23 Sep 2003 09:19:37 -0500, Ed Morton
> :<(E-Mail Removed)> wrote in comp.lang.c:
> :
> :> I have 2 counters - one is required to be a 2-byte variable while the
> :
> :That would 32 bits on one compiler I use, and 64 bits on another.
> :
> :> other is required to be 3 bytes (not my choice, but I'm stuck with it!).
> :
> :This would be 48 bits on one compiler I use, and 96 bits on another.
>
> <snip>
>
> Which are those compilers and their corresponding target platforms?
> Could you please post some details of them? It is not that I don't
> believe you. But, A lot of my colleagues and friends don't believe in
> CHAR_BIT != 8 and I would really like to point out these cases to them.
>
> Have a nice day,
> Pradeep


I happen to have my laptop home with me, which has one of the
compilers installed, here is a copy and paste of a part of the
limits.h file...

========
/************************************************** ******************/
/* limits.h v3.09 */
/* Copyright (c) 1996-2003 Texas Instruments Incorporated */
/************************************************** ******************/

#ifndef _LIMITS
#define _LIMITS

#define CHAR_BIT 16 /* NUMBER OF BITS IN TYPE CHAR */
#define SCHAR_MAX 32767 /* MAX VALUE FOR SIGNED CHAR */
#define SCHAR_MIN (-SCHAR_MAX-1) /* MIN VALUE FOR SIGNED CHAR */
#define UCHAR_MAX 65535u /* MAX VALUE FOR UNSIGNED CHAR */
========

This is from Texas Instruments Code Composer Studio for the
TMS320C2810 and TMS320C2812 Digital Signal Processors.

I don't have a copy of the other compiler handy here at home to copy
and paste, so you will have to take my word for it. It is for an
Analog Devices SHARC 32-bit DSP. All the integer types are 32 bits,
and CHAR_BIT is 16.

Mind you, you won't find these sort of architectures anywhere else but
on DSPs anymore, but a lot of DSP programming is being done in C and
even C++ these days.

These are pretty much all free-standing environments, it is not really
possible to provide all the features of a hosted environment on a
platform where char and int have the same representation. It is
impossible to provide a getchar() function which complies with the
standard, namely that it returns all possible values of char and also
EOF, which is an int different from any possible char value.

There are also the early members of the Motorola 56000 DSP family,
which had a 24-bit word size. char, short, and int were all 24 bits,
and long was 64 bits. Many of the new 56000 family members are either
16 bit or 32 bit, but I believe some of the 24 bit versions are still
produced today.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
 
Reply With Quote
 
Kevin Easton
Guest
Posts: n/a
 
      09-26-2003
Jack Klein <(E-Mail Removed)> wrote:
[...]
> Mind you, you won't find these sort of architectures anywhere else but
> on DSPs anymore, but a lot of DSP programming is being done in C and
> even C++ these days.
>
> These are pretty much all free-standing environments, it is not really
> possible to provide all the features of a hosted environment on a
> platform where char and int have the same representation. It is
> impossible to provide a getchar() function which complies with the
> standard, namely that it returns all possible values of char and also
> EOF, which is an int different from any possible char value.


(It's actually an unsigned char converted to int, not plain char).

However, are you sure it has to be able to return all possible unsigned
chars? Isn't it possible for unsigned char to have 65536 possible
values, but there be only, say, 140 distinct _characters_ which the
string, input and output functions deal with? Does every possible
unsigned char value have to represent a character?

- Kevin.

 
Reply With Quote
 
Micah Cowan
Guest
Posts: n/a
 
      09-27-2003
Kevin Easton <(E-Mail Removed)> writes:

> Jack Klein <(E-Mail Removed)> wrote:
> [...]
> > Mind you, you won't find these sort of architectures anywhere else but
> > on DSPs anymore, but a lot of DSP programming is being done in C and
> > even C++ these days.
> >
> > These are pretty much all free-standing environments, it is not really
> > possible to provide all the features of a hosted environment on a
> > platform where char and int have the same representation. It is
> > impossible to provide a getchar() function which complies with the
> > standard, namely that it returns all possible values of char and also
> > EOF, which is an int different from any possible char value.

>
> (It's actually an unsigned char converted to int, not plain char).


I assume you mean the "all possible values" bit, not EOF.

> However, are you sure it has to be able to return all possible unsigned
> chars? Isn't it possible for unsigned char to have 65536 possible
> values, but there be only, say, 140 distinct _characters_ which the
> string, input and output functions deal with? Does every possible
> unsigned char value have to represent a character?


Doesn't matter. Consider the case when you are reading binary files.

-Micah
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      09-27-2003
"Simon Biber" <(E-Mail Removed)> writes:
> "Ed Morton" <(E-Mail Removed)> wrote:
> > So, if I use:
> >
> > unsigned long large: 24;

>
> It's not portable to use 'unsigned long' as the base type for a bitfield; the
> only portable types are 'int' and 'unsigned int'.


And 'signed int'. For a bit field, it's implementation-defined
whether plain 'int' is signed or unsigned.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
hashCode for 4 ints? Jeff Java 5 06-22-2005 03:00 AM
Iterator Question for map of ints to set of ints uclamathguy@gmail.com C++ 3 04-03-2005 03:26 AM
ints ints ints and ints Skybuck Flying C Programming 24 07-10-2004 04:48 AM
Java2D: not possible to set 32bpp ints? Timo Nentwig Java 6 05-08-2004 12:22 AM
Why constant ints in switch case expressions? Brian J. Sayatovic Java 22 07-09-2003 09:39 PM



Advertisments