4 ms·

> 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

> 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.)
- TheNewAndy 10y ago
  > Well, those chips are DSPs, which is kind of a different horse. This whole discussion has been about portable code. The point is that no matter what the horse is, you can still write code that works (and works efficiently). If you are writing a portable TCP/IP stack, then having a struct like you described doesn't help you one bit. It looks like you are setting things up so you can directly blat the bits into it (or avoid the copy and interpret some bits using this struct, whatever). If you do this, then you don't have portable code because of endianness. To make this code portable, you separate the in memory representation from the "on-wire" representation. The memory representation doesn't need compiler specific things like PACK_STRUCT_FIELD would expand to, it only needs types that are at least 16 or 32 bits wide. The code that fills in the struct needs to operate byte at a time and then fill in the struct members appropriately. Note that because byte in C isn't necessarily 8-bits wide, you have to be a little bit careful with the "byte-at-a-time" code, but it is very possible to write it so it works on any whacky machine that has a C compiler - including DSPs... they really aren't that special.
  - CamperBob2 10y ago
    I think we have to decide whether we're talking about specialized and/or archaic technological artifacts or modern general-purpose processors. My interest is limited to the latter, all of which have C compilers that support 1, 2, 4, and 8-element wide integers composed of 8-bit bytes. Confining the notion of "portability" to these platforms is fine with me. I'll definitely have to yield the point with respect to older DSP chips; I've never written code for a 56K or a SHARC, and never will. Endianness is generally hidden with wrapper macros or functions, and I suppose you could do the same to pretend you're accessing integers of unsupported sizes. But you can rest assured that losing track of the sizes of the underlying types is going to bite you in the ass. If I can't use typedefs, I'll want to use some semantically-equivalent notational cues.
    - TheNewAndy 10y ago
      You seem to think that it is difficult to write programs with this level of portability. It really isn't, you just program to the language spec, and everything else falls out. You don't need to come up with arbitrary rules about which processors are too specialized or archaic. The alternative you provide isn't obviously better than just writing portable code, but from what I can tell, you have never actually just tried the alternative. I can assure you that knowing that exact width of types is rarely useful when writing super portable code for platforms that are different enough that you are happy to decide that you wouldn't even bother coding for them. So I'm puzzled by why it suddenly becomes helpful when you decide you are only going to look at a subset of those platforms. Give an example of how it is going to bite me in the ass and then the discussion can be less emotional and actually based on facts.

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.)

TheNewAndy 10y ago
> Well, those chips are DSPs, which is kind of a different horse. This whole discussion has been about portable code. The point is that no matter what the horse is, you can still write code that works (and works efficiently). If you are writing a portable TCP/IP stack, then having a struct like you described doesn't help you one bit. It looks like you are setting things up so you can directly blat the bits into it (or avoid the copy and interpret some bits using this struct, whatever). If you do this, then you don't have portable code because of endianness. To make this code portable, you separate the in memory representation from the "on-wire" representation. The memory representation doesn't need compiler specific things like PACK_STRUCT_FIELD would expand to, it only needs types that are at least 16 or 32 bits wide. The code that fills in the struct needs to operate byte at a time and then fill in the struct members appropriately. Note that because byte in C isn't necessarily 8-bits wide, you have to be a little bit careful with the "byte-at-a-time" code, but it is very possible to write it so it works on any whacky machine that has a C compiler - including DSPs... they really aren't that special.
- CamperBob2 10y ago
  I think we have to decide whether we're talking about specialized and/or archaic technological artifacts or modern general-purpose processors. My interest is limited to the latter, all of which have C compilers that support 1, 2, 4, and 8-element wide integers composed of 8-bit bytes. Confining the notion of "portability" to these platforms is fine with me. I'll definitely have to yield the point with respect to older DSP chips; I've never written code for a 56K or a SHARC, and never will. Endianness is generally hidden with wrapper macros or functions, and I suppose you could do the same to pretend you're accessing integers of unsupported sizes. But you can rest assured that losing track of the sizes of the underlying types is going to bite you in the ass. If I can't use typedefs, I'll want to use some semantically-equivalent notational cues.
  - TheNewAndy 10y ago
    You seem to think that it is difficult to write programs with this level of portability. It really isn't, you just program to the language spec, and everything else falls out. You don't need to come up with arbitrary rules about which processors are too specialized or archaic. The alternative you provide isn't obviously better than just writing portable code, but from what I can tell, you have never actually just tried the alternative. I can assure you that knowing that exact width of types is rarely useful when writing super portable code for platforms that are different enough that you are happy to decide that you wouldn't even bother coding for them. So I'm puzzled by why it suddenly becomes helpful when you decide you are only going to look at a subset of those platforms. Give an example of how it is going to bite me in the ass and then the discussion can be less emotional and actually based on facts.