|
Code generated by C compilers is fast in 2018. Code generated by C compilers for C64, Spectrum, Atari, Atari ST, Amiga, Mac, CP/M, MS-DOS, Windows 3.x, Nintendo, MegaDrive,... systems meant many times the code would be 80% like this: void some_func(/* params */) {
asm {
/* actual "C" code as inline Assembly */
}
}
Lots of Swift sugar also gets optimized away, and there is plenty of room to improvement.The code that current C compilers don't generate, many times is related to taking advantage of UB. They also generate extra code for handling stuff like floating point emulation though. Just as an example, IBM did their whole RISC research using PL/8, including an OS and optimizing compiler using an architecture similar to what LLVM uses. They only bothered with C, after making the business case that RISC would be a good platform for UNIX workstations. |
>> The code that current C compilers don't generate, many times is related to taking advantage of UB
Compilers are really smart in optimizing things that aren't relevant to the real world.
For example, this code would reduce to "return 32" in most modern compilers:
Does that make impact in real-world code? Almost certainly not, it's a contrived case. Most UB cases fall into the same category.>> They also generate extra code for handling stuff like floating point emulation though.
Not necessarily.