If you have arrived in the middle of this blog series, you might want instead to begin at the beginning.
This post explains the flow of data within the Visual C++ compiler – starting with our C++ source program, and ending with a corresponding binary program. This post is an easy one – dipping our toes into the shallow end of ocean.
Let's examine what happens when we compile a single-file program, stored in App.cpp, from the command-line. (If you were to launch the compilation from within Visual Studio, the diagram below would have to include higher layers of software; however, these end up emitting the very commands I'm about to describe).
So let's imagine we just typed: CL /O2 App.cpp
The CL stands from "Compile and Link". /O2 tells the compiler to optimize for speed – to generate machine code that runs as fast as possible. This command launches a process to execute the CL.EXE program – a "driver" that calls several pieces of software: when joined together, they process the text in our App.cpp and eventually generate a binary file, called App.exe. When executed, this binary will carry out the operations we specified in our original source file.
Let's take a stroll around the diagram above and explain what's going on.
CL.EXE parses our command-line, and checks that it makes sense. It then calls the C++ "front-end", located in C1XX.DLL (the "CXX" is meant to suggest "C++", but dates back to a time when "+" was not a legal character in file names). The FrontEnd is the part of the chain that understands the C++ language. It scans, parses and transforms your App.cpp into an equivalent tree, passed to the next component via 5 temporary files. The "language" represented by these 5 files is called "CIL", for "C Intermediate Language". Don't confuse this with the intermediate code, generated by managed languages such as C#, sometimes called "MSIL" but also, unfortunately, named "CIL" in the ECMA-335 standard.
Next, CL.EXE calls the "back-end", located in C2.DLL. We call the BackEnd "UTC", which stands for "Universal Tuple Compiler", although this name doesn't show up in any of the binaries included into Visual Studio. The BackEnd starts by converting the information from the FrontEnd into tuples – a binary stream of instructions. If we were to display them, they would look like a kind of high-level assembly language. It's high-level in the senses that:
Because we asked the compiler to optimize for speed, via the /O2 switch, the Optimize part of the BackEnd analyses the tuples and transforms them into a form that will execute faster but that is semantically equivalent – that yields the same results as would the original tuples. After this step, the tuples are passed to the CodeGen part of the BackEnd, which decides the final binary code to emit.
The CodeGen module emits App.obj as a file on disk. Finally, the Linker consumes that file, resolves any references to libraries, and produces the final App.exe binary.
In the diagram, black arrows show flow of data – text or binary. Red arrows show flow of control.
(We shall return to this diagram later in the series, when we hit the topic of Whole Program Optimization, specified to the compiler with the /GL switch, and to the Linker with the /LTCG switch. We will see the same set of boxes, but connected in different ways)
This blog will focus on the Optimize part of the compiler, with scant mention of the other components that make up the chain – FrontEnd, CodeGen or Linker.
This post has introduced lots of jargon. I'm not intending that you make total sense of it all at this point: this post is an overview, sprinkled with ideas that hopefully pique your interest, and ensure you'll come back next time, where I will start to explain all of that jargon.
Next time, we will look at perhaps the simplest optimization and how it works – the one called "constant folding".
how to write asp code...
To my knowledge eax is only a 32 bit register, while rax is a 64 bit register.
Did you guys test file based vs memory based using a Virus Scanner?
Our IT departments forces virus scanners onto our systems which make them perform like an 8088