Hacker News Reader

Comment by pjmlp | Hacker News Reader

Most programming languages with compilers to native code (JIT/AOT), the myth of high level Assembler for C only applies if your computer is a PDP-11 or a basic 8-bit CPU like a 6502 or Z80.

The ANSI C and C++ standards define the concept of abstract machine for the language semantics, just like in most languages.

Additionally you have the concepts of sequence points, the new memory model semantics for multi-threaded code and the beloved UB.

UB which doesn't exist in most languages, because their rather leave it implementation defined or lose the opportunity to target some strange CPU not able to support the language semantics.

Also Assembly doesn't has UB, making it ironic that it is safer to write straight Assembly at the expense of portability than C or C derived languages.

View on HN

The ARM Architecture Reference Manuals are full of "if you do X, the instruction is UNPREDICTABLE".

> Also Assembly doesn't has UB, making it ironic that it is safer to write straight Assembly at the expense of portability than C or C derived languages.

You just need to know your compiler flags/configuration to produce exact assembly output (if you want that). And about assembly not having UB, BSF and BSR are pretty good examples for that.

That just is quite ironic, because it is even version dependent across releases of the same compiler, which means anything fine tuned for version X can break on version X + 1, due to changes on the optimizer.

And I doubt anyone is regularly reviewing the produced Assembly every single time they change compilers.

Assembly doesn't have more than 200 documented cases that hardly any human is capable of remembering.

You could argue that each processor's errata is UB in assembly. I remember that programming for the XScale we had a whole manual of errata that we had to program around. Though because it's documented it's not "Undefined", it's just "Incorrect but we know how incorrect".

Aren't all undocumented instructions / opcodes actually UB? If you execute an undocumented instruction the processor has to do something.

You can't really accidentally or unintentionally arrive at undefined behaviour in assembly language though. You would have to explicitly use an undocumented instruction or opcode and the result would probably be a hardware interrupt or exception every time.

Not quite every time though: https://github.com/xoreaxeaxeax/sandsifter

Woah that's pretty neat! Thanks!

Reply on news.ycombinator.com