4 ms·

Ok, now lets suppose you have done the job of thinking about it, and you are now up to actually acting on your thinking. What do you write? You want: - A sing

Ok, now lets suppose you have done the job of thinking about it, and you are now up to actually acting on your thinking. What do you write? You want: - A single code base - The code be compiled on the "I don't have a 16-bit type" machine, as well as on your amd64 machine and x86 machine. Having it work on a 24-bit machine might be nice too if you want bonus points. - You don't want to waste memory on the crappy embedded chips where memory is scarce As far as I'm aware, you can either: 1) Use fixed 32-bit types everywhere (you lose both 24-bit compatibility and waste memory... possibly not the end of the world) 2) Use non-fixed width types and tick all the boxes. You don't really gain anything by using the 32-bit types (who cares if you know exactly how big it is - you only needed 16-bits anyway), but you do lose things.

CamperBob2 10y ago
Honestly, there's no way I'd use an MCU that doesn't support 16-bit integer types. I've never even heard of such a thing. It's really a property of the compiler, not the hardware. I use 32-bit ints and floats all the time on 8-bit 8051s and AVRs, both of which are among the most primitive microcontrollers in use today. They are typedefed to S32 and F32 precisely because I want a unified code base that compiles and works the same under Windows. If I know I'll never need more than 8 or 16 bits, I'll use an S8 or S16, but I certainly won't hesitate to use an S32 or even an S64 on these chips if needed. Using "int" is asking for some serious grief in the embedded world, which is why it's almost never done anymore. I've also never heard of a 24-bit processor -- unless you're thinking of some antediluvian bit-slice processor, or something like that? -- but I'm sure the same code will compile and run on it just fine, if and when I ever encounter one. If not, that's not my problem. It can be blamed jointly on the administration and faculty at the school that handed a diploma to the programmer who wrote the C compiler for it. At the end of the day, if I'm that worried about RAM and resource usage, or if I'm building 100,000,000 of something that has to use the smallest, cheapest controller possible, I'm probably writing in assembly anyway.
- TheNewAndy 10y ago
  > Honestly, there's no way I'd use an MCU that doesn't support 16-bit integer types. I've never even heard of such a thing. SHARC chips don't have any integer types smaller than 32-bits. Why would they, when they can't address any smaller than 32-bits? > I've also never heard of a 24-bit processor -- unless you're thinking of some antediluvian bit-slice processor, or something like that? 56k chips have 24-bit chars. Not so common any more, but they are still kind of kicking around. > but I'm sure the same code will compile and run on it just fine, if and when I ever encounter one. My point is that it won't. If you use types which must be exactly 16-bits wide, then you can't compile that code for machines that don't have a 16-bit wide register.
  - deleted 10y ago
    [deleted]
  - CamperBob2 10y ago
    SHARC chips don't have any integer types smaller than 32-bits. 56k chips have 24-bit chars. Not so common any more, but they are still kind of kicking around. Well, those chips are DSPs, which is kind of a different horse. Why would they, when they can't address any smaller than 32-bits? How, for instance, would you write a TCP/IP stack, if you can't do something like this? struct tcp_hdr { PACK_STRUCT_FIELD(u16_t src); PACK_STRUCT_FIELD(u16_t dest); PACK_STRUCT_FIELD(u32_t seqno); PACK_STRUCT_FIELD(u32_t ackno); PACK_STRUCT_FIELD(u16_t _hdrlen_rsvd_flags); PACK_STRUCT_FIELD(u16_t wnd); PACK_STRUCT_FIELD(u16_t chksum); PACK_STRUCT_FIELD(u16_t urgp); } PACK_STRUCT_STRUCT; There are a couple of right answers and a wrong answer. The wrong answer is, "You can't." The right answer is, "Go ahead and declare the 8-bit or 16-bit integer. The compiler will do the necessary shifting and masking to simulate unaligned reads and writes, including those that straddle two word boundaries." Another right answer might be, "You wouldn't," in the case of a dedicated DSP chip. What I'm saying is that I've never seen a general-purpose platform where that wasn't supported. It might not be fast, of course, but embedded work is often more about interoperability than speed. (DSP being an obvious exception; I'm lucky enough not to have had to work with any old-school DSP coprocessors.)
    - 10y ago

CamperBob2 10y ago

Honestly, there's no way I'd use an MCU that doesn't support 16-bit integer types. I've never even heard of such a thing. It's really a property of the compiler, not the hardware. I use 32-bit ints and floats all the time on 8-bit 8051s and AVRs, both of which are among the most primitive microcontrollers in use today. They are typedefed to S32 and F32 precisely because I want a unified code base that compiles and works the same under Windows. If I know I'll never need more than 8 or 16 bits, I'll use an S8 or S16, but I certainly won't hesitate to use an S32 or even an S64 on these chips if needed. Using "int" is asking for some serious grief in the embedded world, which is why it's almost never done anymore. I've also never heard of a 24-bit processor -- unless you're thinking of some antediluvian bit-slice processor, or something like that? -- but I'm sure the same code will compile and run on it just fine, if and when I ever encounter one. If not, that's not my problem. It can be blamed jointly on the administration and faculty at the school that handed a diploma to the programmer who wrote the C compiler for it. At the end of the day, if I'm that worried about RAM and resource usage, or if I'm building 100,000,000 of something that has to use the smallest, cheapest controller possible, I'm probably writing in assembly anyway.

TheNewAndy 10y ago
> Honestly, there's no way I'd use an MCU that doesn't support 16-bit integer types. I've never even heard of such a thing. SHARC chips don't have any integer types smaller than 32-bits. Why would they, when they can't address any smaller than 32-bits? > I've also never heard of a 24-bit processor -- unless you're thinking of some antediluvian bit-slice processor, or something like that? 56k chips have 24-bit chars. Not so common any more, but they are still kind of kicking around. > but I'm sure the same code will compile and run on it just fine, if and when I ever encounter one. My point is that it won't. If you use types which must be exactly 16-bits wide, then you can't compile that code for machines that don't have a 16-bit wide register.
- deleted 10y ago
  [deleted]
- CamperBob2 10y ago
  SHARC chips don't have any integer types smaller than 32-bits. 56k chips have 24-bit chars. Not so common any more, but they are still kind of kicking around. Well, those chips are DSPs, which is kind of a different horse. Why would they, when they can't address any smaller than 32-bits? How, for instance, would you write a TCP/IP stack, if you can't do something like this? struct tcp_hdr { PACK_STRUCT_FIELD(u16_t src); PACK_STRUCT_FIELD(u16_t dest); PACK_STRUCT_FIELD(u32_t seqno); PACK_STRUCT_FIELD(u32_t ackno); PACK_STRUCT_FIELD(u16_t _hdrlen_rsvd_flags); PACK_STRUCT_FIELD(u16_t wnd); PACK_STRUCT_FIELD(u16_t chksum); PACK_STRUCT_FIELD(u16_t urgp); } PACK_STRUCT_STRUCT; There are a couple of right answers and a wrong answer. The wrong answer is, "You can't." The right answer is, "Go ahead and declare the 8-bit or 16-bit integer. The compiler will do the necessary shifting and masking to simulate unaligned reads and writes, including those that straddle two word boundaries." Another right answer might be, "You wouldn't," in the case of a dedicated DSP chip. What I'm saying is that I've never seen a general-purpose platform where that wasn't supported. It might not be fast, of course, but embedded work is often more about interoperability than speed. (DSP being an obvious exception; I'm lucky enough not to have had to work with any old-school DSP coprocessors.)
  - 10y ago