I wrote several months ago about our impending decision to switch to clang-cl on Windows. In the intervening months, we did that, and we also dropped MSVC as a supported compiler. (We still build on Linux with GCC, and will probably continue to do that for some time.) One (extremely welcome) consequence of the switch to clang-cl has only become clear to me in the past couple of weeks: using assembly language across platforms is no longer painful.
First, a little bit of background: GCC (and Clang) support a feature called inline assembly, which enables you to write little snippets of assembly code directly in your C/C++ program. The syntax is baroque, it’s incredibly easy to shoot yourself in the foot with it, and it’s incredibly useful for a variety of low-level things. MSVC supports inline assembly as well, but only on x86, and with a completely different syntax than GCC.
OK, so maybe you want to put your code in a separate assembly file instead. The complementary assembler for GCC (courtesy of binutils) is called gas, with its own specific syntax for various low-level details. If you give gcc an assembly file, it knows to pass it directly to gas, and will even run the C preprocessor on the assembly before invoking gas if you request that. So you only ever need to invoke gcc to compile everything, and the right thing will just happen. MSVC, by contrast, requires you to invoke a separate, differently-named assembler for each architecture, with different assembly language syntaxes (e.g. directives for the x86-64 assembler are quite different than the arm64 assembler), and preprocessing files beforehand requires you to jump through hoops. (To be fair, a number of these details are handled for you if you’re building from inside Visual Studio; the differences are only annoying to handle in cross-platform build systems.)
In short, dealing with assembler in a world where you have to support MSVC is somewhat painful. You have to copy-and-paste code, or maybe you write Perl scripts to translate from the gas syntax to whatever flavor of syntax the Microsoft assembler you’re using is. Your build system needs to handle Windows and non-Windows differently for assembly files, and may even need to handle different architectures for Windows differently. Things like our ICU data generation have been made somewhat more complex than necessary to support Windows platforms.
Enter clang-cl. Since clang-cl is just clang under the hood, it handles being passed assembly files on the command line in the same way and will even preprocess them for you. Additionally, clang-cl contains a gas-compatible assembly syntax parser, so assembly files that you pass on the command line are parsed by clang-cl and therefore you can now write a single assembly syntax that works on Unix-y and Windows platforms. (You do, of course, have to handle differing platform calling conventions and the like, but that’s simplified by having a preprocessor available all the time.) Finally, clang-cl supports GCC-style inline assembly, so you don’t even have to drop into separate assembly files if you don’t want to.
In short, clang-cl solves every problem that made assembly usage painful on Windows. Might we have a future world where open source projects that have to deal with any amount of assembly standardize on clang-cl for their Windows support, and declare MSVC unsupported?
Clang-cl sounds great. I hope Mozilla doesn’t end up only supporting clang I don’t think a monoculture that supports just one compiler is healthy .
Just like it’s when it comes to web browser engines .