9 ms·

Unfortunately, there are real world systems with C compilers that do not have 8 bit bytes. It's easy to forget the embedded world. C is one of the very, very

Unfortunately, there are real world systems with C compilers that do not have 8 bit bytes. It's easy to forget the embedded world. C is one of the very, very few languages that you can reasonably expect to run on your weird embedded microprocessor, microcontroller, DSP, or whatever. Bit, however, means "binary digit". That's the literal definition of the word. Historical usage of the word "byte" has varied.

lultimouomo 11y ago
> C is one of the very, very few languages that you can reasonably expect to run on your weird embedded microprocessor, microcontroller, DSP, or whatever. I'm not an expert on DSP processing in any way, but I'd argue that if the environment is so peculiar that it doesn't have 8-bit bytes, you won't be able to use so many of the (formally optional) parts of C that you might as well call your code "weirdC" and do without char. It's not like you're going to use normal C libraries, and you are most probably relying on a specific compiler implementation and a lot of platform specific weirdnesses.
- dietrichepp 11y ago
  I think you're underestimating the amount of legacy code that people have. We're not talking about "I have a new processor, let's write code for it." That's unrealistic. It's more like, "I have a new processor, let's get our existing code base working on it, because if we don't, we're going to lose millions of dollars."
  - lultimouomo 11y ago
    That doesn't touch my argument. If you're code is meant to run on DSPs it will already enforce all the relevant rules; if not, you'll have to port it anyway. It's not like your compiler backend that outputs code for DSPs will just compile standard C.
    - hamiltonkibbe 11y ago
      All the code using non-optional c constructs will compile. If you're doing something that uses floating point math and expecting to run it on a 16-bit DSP, you're probably doing something wrong. The biggest hurdle isn't compiler support, rather converting all the floating point operations to fixed-point and ensuring that you have enough resolution such that rounding errors don't make your IIR filter unstable for example. That's really outside the scope of the discussion though, as that is just an aspect of practical DSP using fixed point math.
- hamiltonkibbe 11y ago
  You can use char, and for the most part you won't notice any difference, until you start looking at the memory display in your IDE and have a short-lived WTF moment. A c-string looks strange in the memory view because there's a NULL octet between each character but that's an implementation detail that you don't really notice 99% of the time, because everything on the processor is designed to use 16-bit words. If you write a buffer of chars to the UART tx register, it will only put the half of the word with the character data onto the wire, just like with any other microcontroller, just like with PySerial, and just like with JS and websockets. That's why the C standard doesn't say a char is 8-bits, it just says that sizeof(char) is 1. I would argue that any code doing anything under the assumption that a char variable occupies 8 bits in memory and that the next char in an array is physically adjacent to it with no wasted space in between is just poorly-written and inherently not portable. As for why this is the case, Generally DSPs are designed to do a few tasks very well (multiply-accumulate being the most obvious example, simultaneous reads from X and y memory, etc.) and are generally optimized for a specific word size. If you really need to access an octet on E.g. A 16-bit TI DSP you can, you just need to shift and mask. That's obviously not very efficient, because that's not really what it's optimized for. If that's what you really need, you picked the wrong part. You're gonna be filter-/FFT-/DCT-/whatever-ing way more 12 or 16-bit ADC samples per second, per dollar, and per milliWatt on that 16-bit DSP than you would be on your octet-addressable MSP430. Regarding "Normal" c libraries, If they're valid C they should work just fine for the most part, With some obvious exceptions: you're not going to have a fun time with your "floats" on a processor without FP HW. That's why there's a standard, if you're not relying on undefined or implementation-defined behavior, you'll be fine(ish)
  - lultimouomo 11y ago
    > I would argue that any code doing anything under the assumption that a char variable occupies 8 bits in memory and that the next char in an array is physically adjacent to it with no wasted space in between is just poorly-written and inherently not portable I don't think that's fair at all. It's well written and perfectly portable, under that assumption. If that assumption happens to hold for all the systems that could is meant to run on, why shouldn't you make it? Why assuming that unsigned integers overflow to 0 is fair, and assuming 8 bit bytes is not? They are both pragmatic choices. I think arguing that the C standard didn't make the best choice is at the least a reasonable position. Saying that people who disagree with you on this are writing bad code is not the right way to approach the subject, IMO. > If they're valid C they should work just fine for the most part I've yet to find a library that is valid C, in the strictest sense of the term - i.e., no floats or doubles, no 8-bit char, no uint8_t, etc. I'm sure there are, among libraries meant to run on DSPs. Does it make sense for them and libraries meant to run on bigger processors to adhere to the same exact standard? I'm not sure.
clort 11y ago
As a male human of questionable maturity, I'd just like to say that I am really looking forward to working with ternary digits!

lultimouomo 11y ago

> C is one of the very, very few languages that you can reasonably expect to run on your weird embedded microprocessor, microcontroller, DSP, or whatever. I'm not an expert on DSP processing in any way, but I'd argue that if the environment is so peculiar that it doesn't have 8-bit bytes, you won't be able to use so many of the (formally optional) parts of C that you might as well call your code "weirdC" and do without char. It's not like you're going to use normal C libraries, and you are most probably relying on a specific compiler implementation and a lot of platform specific weirdnesses.

dietrichepp 11y ago
I think you're underestimating the amount of legacy code that people have. We're not talking about "I have a new processor, let's write code for it." That's unrealistic. It's more like, "I have a new processor, let's get our existing code base working on it, because if we don't, we're going to lose millions of dollars."
- lultimouomo 11y ago
  That doesn't touch my argument. If you're code is meant to run on DSPs it will already enforce all the relevant rules; if not, you'll have to port it anyway. It's not like your compiler backend that outputs code for DSPs will just compile standard C.
  - hamiltonkibbe 11y ago
    All the code using non-optional c constructs will compile. If you're doing something that uses floating point math and expecting to run it on a 16-bit DSP, you're probably doing something wrong. The biggest hurdle isn't compiler support, rather converting all the floating point operations to fixed-point and ensuring that you have enough resolution such that rounding errors don't make your IIR filter unstable for example. That's really outside the scope of the discussion though, as that is just an aspect of practical DSP using fixed point math.
hamiltonkibbe 11y ago
You can use char, and for the most part you won't notice any difference, until you start looking at the memory display in your IDE and have a short-lived WTF moment. A c-string looks strange in the memory view because there's a NULL octet between each character but that's an implementation detail that you don't really notice 99% of the time, because everything on the processor is designed to use 16-bit words. If you write a buffer of chars to the UART tx register, it will only put the half of the word with the character data onto the wire, just like with any other microcontroller, just like with PySerial, and just like with JS and websockets. That's why the C standard doesn't say a char is 8-bits, it just says that sizeof(char) is 1. I would argue that any code doing anything under the assumption that a char variable occupies 8 bits in memory and that the next char in an array is physically adjacent to it with no wasted space in between is just poorly-written and inherently not portable. As for why this is the case, Generally DSPs are designed to do a few tasks very well (multiply-accumulate being the most obvious example, simultaneous reads from X and y memory, etc.) and are generally optimized for a specific word size. If you really need to access an octet on E.g. A 16-bit TI DSP you can, you just need to shift and mask. That's obviously not very efficient, because that's not really what it's optimized for. If that's what you really need, you picked the wrong part. You're gonna be filter-/FFT-/DCT-/whatever-ing way more 12 or 16-bit ADC samples per second, per dollar, and per milliWatt on that 16-bit DSP than you would be on your octet-addressable MSP430. Regarding "Normal" c libraries, If they're valid C they should work just fine for the most part, With some obvious exceptions: you're not going to have a fun time with your "floats" on a processor without FP HW. That's why there's a standard, if you're not relying on undefined or implementation-defined behavior, you'll be fine(ish)
- lultimouomo 11y ago
  > I would argue that any code doing anything under the assumption that a char variable occupies 8 bits in memory and that the next char in an array is physically adjacent to it with no wasted space in between is just poorly-written and inherently not portable I don't think that's fair at all. It's well written and perfectly portable, under that assumption. If that assumption happens to hold for all the systems that could is meant to run on, why shouldn't you make it? Why assuming that unsigned integers overflow to 0 is fair, and assuming 8 bit bytes is not? They are both pragmatic choices. I think arguing that the C standard didn't make the best choice is at the least a reasonable position. Saying that people who disagree with you on this are writing bad code is not the right way to approach the subject, IMO. > If they're valid C they should work just fine for the most part I've yet to find a library that is valid C, in the strictest sense of the term - i.e., no floats or doubles, no 8-bit char, no uint8_t, etc. I'm sure there are, among libraries meant to run on DSPs. Does it make sense for them and libraries meant to run on bigger processors to adhere to the same exact standard? I'm not sure.

clort 11y ago

As a male human of questionable maturity, I'd just like to say that I am really looking forward to working with ternary digits!