Using unsigned char instead of int?
Jeffrey P. Bakke
bakke at plains.NoDak.edu
Wed Dec 26 17:37:58 AEST 1990
In article <1990Dec25.220800.7543 at umiami.ir.miami.edu> devebw9f at miavax.ir.miami.edu writes:
> From: Bimal (devebw9f at miavax.ir.miami.edu)
>
> In one of my applications, most of my integer numbers are small in
> magnitude and positive. I am considering using unsigned char in
> order to conserve memory space.
>
> Consider the following code fragments:
>[... deleted to save space ...]
>
> 1. In example A above, is the use of unsigned char any faster compared to
> using short or int? Any drawbacks? (Incidentally, I will be using
> either the gcc compiler or the turboc compiler for this).
Ok, under GCC, I wouldn't know... it would dependent on the system you
are compiling for. Under turboC in can depend on a number of things.
If, under turbo C you are compiling and plan to be running on a 8088
based machine (not 8086 notice) and you turn the option that allows
word alignment for speedup on, there should still be no improvement in speed.
If you use word alignment on any machine with a 16-bit bus, it will
speed up some operations; but then everything gets aligned on word boundaries
that wastes space if you're real critical on memory usage.
In either case, it seems to be just as fast to use integers over chars...
Under Turbo C, the only time that char instead of int seems to make much
sense is when you are working with actual character data. As far as using
a char over an int for a counter loop or something, there will be no
improvement since the 80x86 cpu has 16-bit (word size) registers anyway
for storing and manipulating data. (I know, I know, but I'm assuming
non-protected mode programming).
Under GCC, you might have similar situations but it would be dependent
on your host machine architecture.
In my opinion using char over int is only really helpful when you have
a large amount of data to store. It really shouldn't make any
difference in processing time though. The only time that chars might
be useful in a loop over integers is that if the loop carries too far,
the character counter will rollover instead of 'overflow' past your
boundaries of characters unlike type 'int'
--
Jeffrey P. Bakke | There are a finite number of
INTERNET: bakke at plains.NoDak.edu | jokes in the world...
UUCP : ...!uunet!plains!bakke | The overflow began
BITNET : bakke at plains.bitnet | decades ago.
"I am not a number, I am a free man!" - The Prisoner
More information about the Comp.lang.c
mailing list