I was observing the machine code created for the "int" type of C
and see that only compare one position of memory, and for a "long int",
only compare two positions of memory! Was this problem resolved?
> I was observing the machine code created for the "int" type of C
> and see that only compare one position of memory, and for a "long int",
> only compare two positions of memory! Was this problem resolved?
>
> My compiler is a 1995 version!
I personally find it offensive that most C compilers for the PIC (the only
exception I know of is HiTech's) regard "int" as an 8-bit type and "long" as
a 16-bit type. Both of these definitions are clearly contrary to the C stan-
dard (nb: a compiler I use on a different chip has both "char" and "int" as
16-bit types, and sizeof(char)==1, but _that_ is _allowable_ by the C stan-
dard).
I too find it awkward, but in fact, the length of an int is always platform
dependent, we have just gotten (God, I hate that word) used to 16 bit ints
on Intel platforms. Normally an int is the same length as the predominant
register length, which on a PIC, is clearly 8 bits. A 16 bit int is not
part of the C standard.
> I was observing the machine code created for the "int" type of C
> and see that only compare one position of memory, and for a "long int",
> only compare two positions of memory! Was this problem resolved?
>
> My compiler is a 1995 version!
I personally find it offensive that most C compilers for the PIC (the only
exception I know of is HiTech's) regard "int" as an 8-bit type and "long"
as
a 16-bit type. Both of these definitions are clearly contrary to the C
stan-
dard (nb: a compiler I use on a different chip has both "char" and "int" as
16-bit types, and sizeof(char)==1, but _that_ is _allowable_ by the C stan-
dard).
>I personally find it offensive that most C compilers for the PIC (the only
>exception I know of is HiTech's) regard "int" as an 8-bit type and "long" as
>a 16-bit type. Both of these definitions are clearly contrary to the C stan-
AAAAAA MMMMMMM EEEEEEE NNNNNN!!!!!!
Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
Hardware & Software for Industry & R/C Hobbies
"Go fast, turn right, and keep the wet side down!"
==================================================================
> >I personally find it offensive that most C compilers for the PIC (the only
> >exception I know of is HiTech's) regard "int" as an 8-bit type and "long" as
> >a 16-bit type. Both of these definitions are clearly contrary to the C stan-
>
> AAAAAA MMMMMMM EEEEEEE NNNNNN!!!!!!
>
> Andy
>
As someone else has already pointed out, the "C standard" does NOT define any
particular sizes for ANY integral data types; they are platform-dependent. All
the standard says is (from Section A4.2 in K&R Second Edition):
"Besides the 'char' types, up to three sizes of integer, declared 'short int',
'int',
and 'long int', are available. Plain 'int' objects have the natural size
suggested by
the host machine architecture; the other sizes are provided to meet special
needs.
Longer integers provide at least as much storage as shorter ones, but the
implementation
may make plain integers equivalent to either short integers, or long integers.
The 'int'
types all represent signed values unless specified otherwise."
Terms in single quotes ('') are in bold type in the book. Thus, since the size
of a PIC's
registers is 8 bits, this would be the "reasonable" size of an 'int', as
dictated by the
above K&R section. Short's and long's are then up to the compiler writer.
> I too find it awkward, but in fact, the length of an int is always platform
> dependent, we have just gotten (God, I hate that word) used to 16 bit ints
> on Intel platforms. Normally an int is the same length as the predominant
> register length, which on a PIC, is clearly 8 bits. A 16 bit int is not
> part of the C standard.
The C standard does not specify the size nor the representation of any
numeric types (e.g. a machine that used 5 10-state tubes to store an INT
would be perfectly fine) except for the following requirements:
[1] A signed char must support values from -127 to 127
[2] A signed int or short must support values from -32767 to 32767
[3] A signed long must support values from -(2^31-1) to (2^31-1)
[4] An unsigned char must support values from 0 to 255
[5] An unsigned int or short must support values from 0 to 65535
[6] An unsigned long must support values from 0 to (2^32-1)
[7] A char [with default signed-ness] must be capable of storing all of the
characters in the standard C character set as positive integers (this
latter requirement primarily means that on 8-bit machines which use the
EBCDIC character set, characters must be unsigned).
[8] sizeof(long) >= sizeof(int) >= sizeof(short) >= sizeof(char) == 1
I think, though I'm not positive, that the following also apply:
[A] Any value that can be stored in a signed type must fit in all "larger"
signed types.
[B] Any value that can be stored in an unsigned type must fit in all "larger"
unsigned types.
[C] Any non-negative value that fits in a signed type must fit in the
corresponding unsigned type.
It's perfectly acceptable for machines to have sizeof(int)==1 if a char
can hold suitably-large values. For example, on the TI 3205x, ALL inst-
ructions to read/write memory use 16-bit values. While it's not terribly
difficult to parse out the two halves of a word, the compiler instead
just defines "char" to be a 16-bit word--the same size as a short or an
int. A bit wasteful of data space, perhaps, but a major saver of time and
codespace.
Unfortunately, the common PIC compiler's notion that an int is 8 bits and
a long is 16 bits fails under tests 2, 3, 5, and 6 above.
Alan G. Smith wrote:
>
> Where in the world do you get the requirements from ????
>
> Also, can you do anything to stop all of your messages from coming across as
> attachments?
>
> Thanks,
>
> Alan G. Smith
>
> +---------------------------------------------------------
> | Alan G. Smith
> | RemoveMEagsTakeThisOuTpoboxes.com
> | http://www.innovatus.com/ags
>
>above K&R section. Short's and long's are then up to the compiler writer.
K&R is the problem, then, I suppose. Most of us have progressed beyond
that stage, and insist upon uniformity.
As I understand it, ANSI and K&R are _NOT_ the same thing.
I, for one, utterly ENJOY being able to test modules on my PC using MS
VC++, then, without changing anything, cut and paste into my HiTech C and
still have functioning code.
Andy
==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
Hardware & Software for Industry & R/C Hobbies
"Go fast, turn right, and keep the wet side down!"
==================================================================
> >above K&R section. Short's and long's are then up to the compiler writer.
>
> K&R is the problem, then, I suppose. Most of us have progressed beyond
> that stage, and insist upon uniformity.
>
> As I understand it, ANSI and K&R are _NOT_ the same thing.
So it is said.
> I, for one, utterly ENJOY being able to test modules on my PC using MS
> VC++, then, without changing anything, cut and paste into my HiTech C and
> still have functioning code.
Yes, we implemented multidrop communications and the protocol layer
code is linked in by TurboC, C++ or HiTechC with only minor changes
to some hardware dependant header information.
Certainly makes it easier to debug code on a PC and then know that
it works the same on the PIC.
bigfoot.com
