PC compilers always followed that path.
The same in Turbo C would be:
void init()
{
asm {
mov ax, 0x13
int 0x10
}
}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.
Your remarks are a mute point in modern Windows compilers with Assembly intrinsics, the evolution of those inline assembly instructions.
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.
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.
void init() {
asm("ax"(0x13)) { int 0x10 }
}
There's also a Rust version of Dynasm.
Porting to rust is easier if it doesn't require a person to be an expert at two different kinds of inline assembly syntax. Being able to grab a chunk of inline assembly from a C project is very useful.
Whatever you do, don't embed knowledge of the assembly language into the compiler. That way lies madness. Assembly is often used for new CPU features that are not yet supported by the compilers that people are using. Constantly putting out minor compiler updates for every CPU revision would be miserable, and the users won't want to force those upgrades anyway.
There is also the issue, I'm sorry, of the rust preprocessor. It will be written and it will be used. It may even be popular and ultimately written into an ISO standard. The irregularity of switching suddenly to a radically different CPU-specific syntax for assembly code would make the preprocessor situation much more nasty and gross.
Wasn't Rust's current inline assembly syntax subtly different from the gcc-compatible one you'd find in most C projects? IIRC, it uses the syntax from the LLVM IR to specify inputs and outputs, instead of the syntax from GCC inline assembly.
The same path that Microsoft has decided to follow since they introduced 64 bit support. Compiler intrinsics.
Also copy paste inline Assembly from C into Rust only works for a specific C compiler.
Sadly, this doesn't save you from that, in fact, it can be argued that the string syntax is what makes you need to learn a whole second set of syntax. This is due to clobbers.
> There is also the issue, I'm sorry, of the rust preprocessor. It will be written and it will be used.
I don't forsee this happening; Rust has powerful enough generic capabilities that even with tens of millions of lines of Rust existing today (I'd actually guess we're in the hundreds right now, but still), nobody has invented one yet. Getting away from the pre-processor is considered a pro, not a con.
Yep, even ISO C++ is putting energy into making each standard revision one reason less to use it.
no need to invent one when cpp exists and works. I've seen people use it in Java, and it is sometimes used in unix config files (e.g. .Xresources).