4 ms·

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 mo

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.
- GFK_of_xmaspast 11y ago
  > If that assumption happens to hold for all the systems that could is meant to run on, why shouldn't you make it? Because what's going to happen two years down the road when you need to get that code working on a different platform. (In the old days, they called that thinking "all the world's a VAX", which became "all the world's linux" in the not-quite-as-old days)
  - lultimouomo 11y ago
    > Because what's going to happen two years down the road when you need to get that code working on a different platform. And what happens when the different platform handles overflow differently? Or has non-IEEE floats? Or breaks whatever assumption the C standard already makes? Here's the thing: C is already built on assumptions, which might or might not hold for a specific platform. Choosing which assumptions we hold true is a pragmatic choice that must be done. C does it, and does it consciously - but it doesn't mean that it nails every choice.
    - GFK_of_xmaspast 11y ago
      If you're in a situation where you need specific implementation details of floating point arithmetic, then may the devil have mercy on your soul, because god certainly won't.
      - Solarsail 11y ago
        Wouldn't debugging / testability imply this is a fairly large proportion of programs? Having a calculation give different results on different hardware would make testing difficult: http://yosefk.com/blog/consistency-how-to-defeat-the-purpose-of-ieee-floating-point.html http://yosefk.com/blog/consistency-how-to-defeat-the-purpose...
        GFK_of_xmaspast 11y ago
        Your own link explains how easy it is to get different results even on the same hardware depending on compiler flags.

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.

GFK_of_xmaspast 11y ago
> If that assumption happens to hold for all the systems that could is meant to run on, why shouldn't you make it? Because what's going to happen two years down the road when you need to get that code working on a different platform. (In the old days, they called that thinking "all the world's a VAX", which became "all the world's linux" in the not-quite-as-old days)
- lultimouomo 11y ago
  > Because what's going to happen two years down the road when you need to get that code working on a different platform. And what happens when the different platform handles overflow differently? Or has non-IEEE floats? Or breaks whatever assumption the C standard already makes? Here's the thing: C is already built on assumptions, which might or might not hold for a specific platform. Choosing which assumptions we hold true is a pragmatic choice that must be done. C does it, and does it consciously - but it doesn't mean that it nails every choice.
  - GFK_of_xmaspast 11y ago
    If you're in a situation where you need specific implementation details of floating point arithmetic, then may the devil have mercy on your soul, because god certainly won't.
    - Solarsail 11y ago
      Wouldn't debugging / testability imply this is a fairly large proportion of programs? Having a calculation give different results on different hardware would make testing difficult: http://yosefk.com/blog/consistency-how-to-defeat-the-purpose-of-ieee-floating-point.html http://yosefk.com/blog/consistency-how-to-defeat-the-purpose...
      - GFK_of_xmaspast 11y ago
        Your own link explains how easy it is to get different results even on the same hardware depending on compiler flags.