> If you haven’t been living under a rock quarantined against COVID-19, you’ve probably heard about C becoming assembly 2.0, or the new assembly, or YES THIS.<p>What's this referring to? Has something been proposed recently?<p>> Now, many compilers have done some work with this using what are known as intrinsics. However, these do not allow us to fully exploit what we can in assembly. Most of the intrinsic instructions follow the C calling conventions, so they are required to load from RAM, do something with it, then store back into RAM.<p>> Since we store the intermediate values, we’re exercising the memory controller for every intrinsic. For our assembly, we load at the beginning and store at the very end. Nothing is in between.<p>I don't understand this claim. It seems demonstrably false to me. Intrinsics don't have to follow the C calling convention. And they in practice don't follow it. You can try it for yourself. It definitely doesn't store intermediate results to memory for his example code.<p>In fact, isn't what clang generates roughly the same assembly as the hand-written assembly in the article?<p><a href="https://godbolt.org/z/rfmFB5" rel="nofollow">https://godbolt.org/z/rfmFB5</a><p>The author looks like an expert so I guess I'm missing something.
I wrote very similar article long back. <a href="http://www.avabodh.com/cin/cin.html" rel="nofollow">http://www.avabodh.com/cin/cin.html</a>
> All in all, the compiler, when emitting its assembly code, must make these decisions. One data type of note is char. The standard does not 100% state whether we should sign extend or zero extend a char. In fact, I noticed a difference between GNU’s RISC-V toolchain vs GNU’s Intel/AMD toolchain. The former will sign extend, whereas the former zero extends.<p>The C standard states that an unqualified "char" type (without the "signed" or "unsigned" keywords) is implementation-defined to be either signed or unsigned.<p><a href="https://en.cppreference.com/w/cpp/language/types#Character_types" rel="nofollow">https://en.cppreference.com/w/cpp/language/types#Character_t...</a><p>> char - type for character representation which can be most efficiently processed on the target system (has the same representation and alignment as either signed char or unsigned char, but is always a distinct type). Multibyte characters strings use this type to represent code units. The character types are large enough to represent any UTF-8 eight-bit code unit (since C++14). The signedness of char depends on the compiler and the target platform: the defaults for ARM and PowerPC are typically unsigned, the defaults for x86 and x64 are typically signed.
> "Another reason we use assembly over a high-level language is to use instructions that C or C++ cannot really use. For example, the advanced vector extensions (AVX) for an Intel processor don’t have a 1-to-1 conversion from C."<p>This might be beyond the scope of the article, but it may be worth noting <a href="https://ispc.github.io/" rel="nofollow">https://ispc.github.io/</a>, which is a C language extension and accompanying (LLVM-frontend) compiler. ISPC exposes an SPMD programming model that efficiently maps to the CPU's vector lanes (think CUDA kernels, but running on those vector lanes instead of a GPU). Except for a few new keywords and some library functions, it is almost identical to C and has C linkage.
The thing I adore about computer science is that it is quite tractable to understand absolutely everything from theories of data and computation, programming languages and operating systems, and hardware.<p>This article is a fantastic look at the lower parts of the stack, and it’s really made me look forward to the next time I’ll be teaching this topic in my own classes.<p>RISC looks much easier to learn than the code I’ve been using: clang generated asm in macOS.<p>I was actually thinking of moving to using assembler in DOSBox (1) for nostalgia reasons and (2) because it could be a lot simpler and less crufty.<p>What’s an equivalent platform / set of tools with which I could do some real world RISC? Is my macOS assembler RISC already, but just not as elegant as this author’s examples?
The nice thing about assembly code isn't the lack of abstractions, but the fact that the image of compilation (the assembly process) is bigger than most languages' compilers: just about any output you want has a corresponding input.<p>People always confuse these things, and it's important that we don't to continue striving for better programming languages.