Avr microcontrollers still have 16bit ints, probably 8051 and pic too, but I don't use those. Lots of people do though. TI dsp uses 48 bit long, so don't count on int and long being the same either.
FWIW, I've actually used a really silly chip once that had a horrible-tastic toolchain that it came with, where char and int were the same size, and both either 16 or 32 bits (I forgot whether it was 16 or 32, unfortunately). (In case anyone doesn't notice: on such a system, sizeof(int) is still 1, as it is measured in units of sizeof(char).)
Then we would be stuck with 16 bits integers. We are lucky to be in a point in time where integer types have been stable for a while, but it wasn't always so.
A very long time ago, the Microsoft C/C++ compiler used 16 bit ints. I had a boss that insisted we use long instead of int because he had been burned by this. Hadn't been a problem for at least 20 years, but that didn't matter to him.
When referring to the Arduino, unless explicitly stating a specific chip, most people are actually referring to the AT328P chip, which is a chip with 8-bit architecture (registers are 8-bit, 16-bit data types are split between a high and a low register). It has 32 KB programmable memory, and 2 KB RAM.
Indeed, though, on the Arduino platform, an int is usually 16 bit, but not because that's the chip's native archticture, but because that's the range required. Though I can't say for sure, I highly doubt (and now am actually almost completely certain in my doubts) that it would promote two chars to ints to perform operations on them, and last night also realized why, namely, there are counts for the number of cycles required to do operations on various data types [0].
If what you say about integer promotion is true, there would be no difference in clock cycles between an int and a byte, but there is.
So in essence, no, the Arduino is definitely somehow deviating from spec when it comes to promotion.
reply