The Texas Instruments C55x DSP has 16-bit bytes. See the compiler documentation at http://www.ti.com/litv/pdf/spru281f section 5.3 if you do not believe me. This DSP has more unusual properties:
type size (bits)
------------------------------
char 16
short 16
int 16
long 32
long long 40
float 32
double 32
pointer (data) 16 or 23
pointer (function) 24
>What's the proper scenario to use "long" instead of "int"? I've never bothered to use it.
It was necessary with 16-bit processors, because ints were 16-bit shorts, and longs were 32-bits.
With modern processors and OS', there isn't really a reason to use it. In fact, it's potentially dangerous if you're writing *nix code that's supposed to run on 64 or 32-bit systems. In that case, you don't want to use longs, because they're 32-bits on a 32-bit compile, but 64 on 64-bits on a 64-bit compiler. For Windows, int and long are interchangable 32-bit values, which is another reason to avoid using longs as much as possible when writing portable code.
The immediate reason is that the ALU is 40 bits wide. The reason it has this particular size is probably a tradeoff between computational power vs silicon area and power consumption.
I had an OCD incident few years back and did a lot of thoughtful reading of all things readable on the subject. In distilled form the sacred knowledge is this - as far as the C standard is concerned, a byte is always exactly 8 bits, and a char is AT LEAST 8 bits. In fact, there is a compiler that operates in terms of 60 bit chars and that's the one on older Cray machines.
No, a byte is not always 8 bits. byte and char are basically synonymous.
byte -- addressable unit of data storage large enough to hold any member of the
basic character set of the execution environment.
...
Note 2: A byte is composed of a contiguous sequence of bits,
the number of which is implementation-defined.
throws down gloves