@phloggen
An example is when a DMA controller has to be programmed with a start address of a C object,, and so a pointer value has to be convered to an integer, to be programmed into a DMA controller register. Technically doing that is UB, yet it works on pretty much any real-world compiler used for embedded programming.

@phloggen
I need to study the actual C standard (now C23, which is ISO/IEC 9899:2024) to learn more detail about the magicness of char*.
I with some reluctance admit that in programming small embedded systems (microcontrollers), I do (very rarely) deliberately use some C code that depends on deterministic implementation of what is technically UB, when there is no practical alternative. Usually this is limited to the lowest level hardware interfaces, and I comment the fact that it is known UB.

@phloggen
Also, in C and C++, the ONLY valid values for a pointer are to an object, or (if an array), any existing element of an array object, or the nonexistent element just one past the end of the array.
Doing any other pointer arithmetic is UNDEFINED BEHAVIOR.
If you have a pointer to the first element of an array, decrement the pointer, and then increment the pointer again, that is UB. You're not guaranteed to get the original pointer value back. Because it's UB, it could do ANYTHING!

@phloggen
For the benefit of those playing along at home, C and C++ allow you to cast a pointer type to a void*, and cast it back to the ORIGINAL pointer type, but casting it to any other pointer type is UNDEFINED BEHAVIOR.
Similarly, you can store a pointer in an intptr_t, and extract it back to the ORIGINAL pointer type.
Sadly, much C and C++ code does depend on other pointer casts which technically have UB.

@phloggen
Agreed. The problem with the vast majority of segmented memory architectures (e.g., x86) was not the segmentation per se, but the limitation on segment size.
That said, too much C software (and some C++ software) depends on what is technically undefined behavior, assuming a flat memory space so that they can abuse pointers. The pre-standard C language didn't say that you couldn't, so many programmers did, and still do.

@phloggen
Semiconductor process technology has always (until now?) advanced quickly enough that such language-directed architectures have been doomed to never become mainstream. There's at least a small chance that that could change, since Moore's law is still increasing density, but is not increasing single-core performance nearly as rapidly. While there are some important problems that are amenable to multi-core implementation, many are not.

@phloggen
Oooh, that sounds fun! I've been a fan of Ada since before the original Ada '83 standard (though had some serious limiations not resolved until Ada '95), and though I had a friend who worked at Rational, I have never used their machines, and could only drool over the specs.
I've always been interested in language-directed computer architecture, especially for languages with a higher semantic level than C.

If I were superstitious, I'd avoid mentioning it for fear of jinxing it, but since it's bad luck to be superstitious:
It looks like I'll have a new development contract for VHDL FPGA code starting later this week.
I've done quite a bit of VHDL FPGA work, and not quite as much Verilog FPGA work, but most of it has been personal projects, and only a small amount has been professional. I am excited about adding more professional FPGA development experience to my résumé.