4 ms·

But does not define them in terms of hardware. My numbers referred to the native widths of the hardware words. sizeof(int) would of course return those numbers

by dwarman 11y ago

But does not define them in terms of hardware. My numbers referred to the native widths of the hardware words. sizeof(int) would of course return those numbers divided by 8, but machines are almost universally referred to by bit width, not byte width. Intel 64 bit chips, not Intel 8 byte chips, for example. So sizeof(int) is still a function of hardware width, and hardware width is defined in terms of bits. Perhaps I should have been a bit more specific, instead of leaping over fully internalized transforms without explanation? Here? In a discussion about hardware? And note that 36 bits is not a multiple of 8, which actually breaks sizeof() anyway.

dllthomas 11y ago
"Perhaps I should have been a bit more specific, instead of leaping over fully internalized transforms without explanation?" I don't know about "should" - my post wasn't really meant as criticism. I just thought we had an opportunity to dig in a little deeper and do so a little clearer. "Here? In a discussion about hardware?" There are a whole lot of people here who have only done web dev or high-level x86 application development, and many who are only passingly familiar with C or HW. "And note that 36 bits is not a multiple of 8, which actually breaks sizeof() anyway." Oh, a 36 bit architecture without a char size of 9? Interesting! How did that work? Can that be standard conforming?
- dwarman 11y ago
  "should": a problem with lengthy experience and age is just how many steps between A and Z get chunked into merely A to B since it is "obvious". Which, in my case, is why I do not teach. Ive forgotten too many derivations. SO digging deeper would be a good exercise for me. Thanks. 36 bits was a custom DSP architecture. Could not use C to get at the extra 4 bits, had to use ASM. Storage units is also inconstant. I've had fun with another DSP who used 16 bit instead of 8, could not address bytes at all. No C at all so I don't know what it would have done with sizeof(int). Had to exchange stream data with a conventional architecture via DMA. Fun times. In some ways I am a little dissappinted in the arc of our technology. It may have become constrained overly by what compiler tech can do easily and can not do so easily. I really should not be able to understand how a quad-core architecture is put together and works, not after some 50 years of development, but I do. Not because I'm a genius, but because it is essentially the same stuff I worked with in the 60's with a lot of emvblishments, short cuts, and optimizations, but not fundamental change.

by dwarman 11y ago

dllthomas 11y ago

"Perhaps I should have been a bit more specific, instead of leaping over fully internalized transforms without explanation?" I don't know about "should" - my post wasn't really meant as criticism. I just thought we had an opportunity to dig in a little deeper and do so a little clearer. "Here? In a discussion about hardware?" There are a whole lot of people here who have only done web dev or high-level x86 application development, and many who are only passingly familiar with C or HW. "And note that 36 bits is not a multiple of 8, which actually breaks sizeof() anyway." Oh, a 36 bit architecture without a char size of 9? Interesting! How did that work? Can that be standard conforming?

dwarman 11y ago
"should": a problem with lengthy experience and age is just how many steps between A and Z get chunked into merely A to B since it is "obvious". Which, in my case, is why I do not teach. Ive forgotten too many derivations. SO digging deeper would be a good exercise for me. Thanks. 36 bits was a custom DSP architecture. Could not use C to get at the extra 4 bits, had to use ASM. Storage units is also inconstant. I've had fun with another DSP who used 16 bit instead of 8, could not address bytes at all. No C at all so I don't know what it would have done with sizeof(int). Had to exchange stream data with a conventional architecture via DMA. Fun times. In some ways I am a little dissappinted in the arc of our technology. It may have become constrained overly by what compiler tech can do easily and can not do so easily. I really should not be able to understand how a quad-core architecture is put together and works, not after some 50 years of development, but I do. Not because I'm a genius, but because it is essentially the same stuff I worked with in the 60's with a lot of emvblishments, short cuts, and optimizations, but not fundamental change.