Why bring these ancient home computer platforms into play? Those were totally different to program for. Why not compare a C compiler from 1998 to one from 2018, on x86 (no SSE of course)? C compilers have gotten better, but not spectacularly.
>> 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:
int return32(){
int x=1;
for (int i=0; i<5; i++){
x*=2;
}
return x;
}
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.
> wWhy bring these ancient home computer platforms into play? Those were totally different to program for. Why not compare a C compiler from 1998 to one from 2018, on x86 (no SSE of course)? C compilers have gotten better, but not spectacularly.
To clear up the myth among young generations that C compilers always generated fast code, regardless of the platform.
As for something more modern, in 1998, C code quality was still at a similar level to other system's languages, before they started to fade away thanks to the increase in UNIX, Linux and BSD adoption
For example, given that Delphi and C++ Builder share the same backend, their generated code was quite similar, even if it would require disabling some of the Delphi's security checks.
>> 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.