4 ms·

How is assembly less safe than C? C is full of undefined behavior which might be interpreted differently by different compilers, whereas (maybe with the excepti

How is assembly less safe than C? C is full of undefined behavior which might be interpreted differently by different compilers, whereas (maybe with the exception of some unusual circumstances) the behavior of assembly language for major instruction sets is 100% documented.

ncmncm 6y ago
I see that you have not coded in assembly language.
- umanwizard 6y ago
  I haven’t; I’ve only read it a bit. I could be wrong about a relative lack of UB compared to C - do you have examples?
  - ncmncm 6y ago
    When you code in assembly language, you discover how incompletely documented every chip is. Any detail of behavior not documented might change in a later chip, and is thus UB. Makers of compatible chips are obliged to keep a collection of systems with all the extant chip designs to run experiments against, and to maintain their own documentation of discovered but unspecified commonalities that users' code may have come to depend on. Each released chip, and each stepping of each release, has its own unique set of bugs-- deviations from documentation, from observed behavior of previous chips, and of chips yet to be released. Writers of assembly code need a compendium of behaviors, documented or not, that cannot be relied on for the set of release platforms. Many such bugs depend on an ill-characterized history of processor states, making them, often, (more or less) reliably reproducible only with a particular program that was discovered to evoke each. Often the behavior noted is seen only once in a million runs. An example on Intel is the popcount instruction that runs very slowly, sometimes, in chips released up to a few years ago. The instruction appeared along with ...SSE3?, and had the bug until it was noticed and fixed in a subsequent chip. The bug is the reason Gcc uses the same register for source and destination when it emits this instruction. Intel's ISA manual does not mention this behavior.
    - umanwizard 6y ago
      Thank you for the details. I guess I had an overly rose-tinted view of the quality of Intel documentation.

ncmncm 6y ago

I see that you have not coded in assembly language.

umanwizard 6y ago
I haven’t; I’ve only read it a bit. I could be wrong about a relative lack of UB compared to C - do you have examples?
- ncmncm 6y ago
  When you code in assembly language, you discover how incompletely documented every chip is. Any detail of behavior not documented might change in a later chip, and is thus UB. Makers of compatible chips are obliged to keep a collection of systems with all the extant chip designs to run experiments against, and to maintain their own documentation of discovered but unspecified commonalities that users' code may have come to depend on. Each released chip, and each stepping of each release, has its own unique set of bugs-- deviations from documentation, from observed behavior of previous chips, and of chips yet to be released. Writers of assembly code need a compendium of behaviors, documented or not, that cannot be relied on for the set of release platforms. Many such bugs depend on an ill-characterized history of processor states, making them, often, (more or less) reliably reproducible only with a particular program that was discovered to evoke each. Often the behavior noted is seen only once in a million runs. An example on Intel is the popcount instruction that runs very slowly, sometimes, in chips released up to a few years ago. The instruction appeared along with ...SSE3?, and had the bug until it was noticed and fixed in a subsequent chip. The bug is the reason Gcc uses the same register for source and destination when it emits this instruction. Intel's ISA manual does not mention this behavior.
  - umanwizard 6y ago
    Thank you for the details. I guess I had an overly rose-tinted view of the quality of Intel documentation.