On Jul 3, 2012, at 3:27 PM, Dave McGuire wrote:
On 07/03/2012 02:29 PM, Jochen Kunz wrote:
On every
platform I work on, and indeed every platform I've
*ever* worked on, unsigned short has been 16 bits, and unsigned int has
been 32. That includes the 8-bitters as well.
No. avr-gcc uses 16 bits / 2 bytes
for int / unsigned int.
I am looking at this very moment to a LCD connected to a ATmega168 that
printed sizeof( unsigned int) on said LCD.
I just went and looked, and I must apologize, you are absolutely
correct! I don't know what I was thinking when I mentioned AVR the
other day. I'm hip-deep in firmware and it's hot in here; that's my excuse.
However, and I maintain that this is the more salient point, the code
still works. ;) But see below.
The bright side is that going *up* in bit size (like you're doing from
AVR to ARM) usually works. The big counter-example is when someone
has done something too-clever-by-half like using integer overflow to
perform an automatic modulo in order to save cycles. In cases like
that, you absolutely need to know the bit width of your variables, and
the not-knowing can produce sneaky bugs that are very difficult to
track down.
I absolutely agree that it's important to know the salient features
of your architecture, such as native bit-widths. "Salient" for me for
the AVR architecture includes the fact that it's an 8-bit architecture
and that 16-bit math is actually not so cheap on it (the only 16-bit
native ALU instructions are for moving and adding/subtracting
immediates, and I would hazard a guess that you only get them because
they are leftover "bonuses" in the ALU for the X, Y and Z regs). So
when I'm writing code I know will be targeted for the AVR, I tend to
use uint8_t a lot more (and yes, I use it because the name carries
the semantics for the reader that I am not necessarily using this as
a character string).
I guess that brings up another reason I happen to like those stdint.h
typedefs: they give semantics to the reader ("I REALLY WANT this to be
16 bits") that "unsigned short" does not. It's proven useful to me
when porting other people's code.
- Dave