4 ms·
The style used by Turbo C is strictly inferior. There is no way for the author of the assembly code to cooperate with the compiler's register allocator or instr
by tropo 7y ago
The style used by Turbo C is strictly inferior. There is no way for the author of the assembly code to cooperate with the compiler's register allocator or instruction scheduler.
You wouldn't even need both of those lines with gcc. You could ask the compiler to put 0x13 into ax, and the compiler might schedule that instruction far earlier or even take advantage of the value already being in the register by luck.
Turbo C makes a simplistic assumption about what registers might have been trashed. With gcc, the compiler knows because you told it. Turbo C must save things to memory before the assembly and then reload registers afterward, which adds enough slowness that the assembly might not even be worthwhile.
- pjmlp 7y agoTurbo C was a compiler done in 1990 for MS-DOS, naturally it was just an example. Your remarks are a mute point in modern Windows compilers with Assembly intrinsics, the evolution of those inline assembly instructions.
- tropo 7y agoIt's not mute or even moot. Assembly intrinsics are not enough. I've dealt with this, getting software to run in Visual Studio. The intrinsics are simply not available. You end up running code through gcc to produce assembly, then hacking up the assembly (way too much to write by hand) into a separate *.asm file for Visual Studio. Vector stuff, if it isn't very new, is covered by intrinsics. Well, it is badly covered, with terrible failures to keep things in registers. Once you get into exotic OS-level stuff, the intrinsics simply don't exist. The most important one is the ability to put an arbitrary byte sequence into the instruction stream. For example, suppose you wanted to add a Spectre fix to your JIT on day 1. You needed to fix a security problem, so waiting for a new release of Visual Studio isn't an acceptable option. You really truly need the ability to put weird byte sequences into the code. Visual Studio doesn't provide an intrinsic for that.
- pjmlp 7y agoFor such corner cases using MASM on day 1 until the new VC++ release isn't much of an issue.
- tropo 7y agoMASM is just an assembler, with no awareness of the C or C++ code. MASM is unable to place arbitrary bytes into the middle of functions that are written in C or C++. To fix a problem like Spectre, and generally to solve unusual problems that the compiler vendor isn't dealing with, the full capability of an inline assembler is required.
- pjmlp 7y agoSure it can, I really don't see any difference between that and a naked call with LTO, beyond the convenience of saving about a minute not having to write a prototype for the function being called and adding MASM into the build.
- a1369209993 7y agoThat has nothing to do with their actual point; Turbo C could perfectly well support: void init() { asm("ax"(0x13)) { int 0x10 } } and as TFA suggests, plenty of implementations use the string-syntax without any register/clobber extensions.