Difference between revisions of "Bootstrapping"
(→How do we find if it really worked?) |
|||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category:Compiler]] | [[Category:Compiler]] | ||
==Definition== | ==Definition== | ||
| − | Check out the definition from | + | Check out the definition from [http://en.wikipedia.org/wiki/Bootstrapping_(compilers) Wikipedia] to know more about bootstrapping. |
==Why bootstrapping?== | ==Why bootstrapping?== | ||
The general idea is that when you do a change in the code generation (often for improving the speed) you want to get a compiler that has been compiled with the new code generation to benefit from the changes. | The general idea is that when you do a change in the code generation (often for improving the speed) you want to get a compiler that has been compiled with the new code generation to benefit from the changes. | ||
| − | ==When not bootstrapping== | + | ===When not bootstrapping=== |
Although you can always do a bootstrap, there are cases when it is actually not required. For example when: | Although you can always do a bootstrap, there are cases when it is actually not required. For example when: | ||
* Changing an header file which will impact the C generated code in a non-intrusive way, but still requires a new runtime. In that case, no bootstrap is necessary, it suffices to copy the new header and runtime to the current delivery. | * Changing an header file which will impact the C generated code in a non-intrusive way, but still requires a new runtime. In that case, no bootstrap is necessary, it suffices to copy the new header and runtime to the current delivery. | ||
* Changing a kernel library class which does not involve a special compiler knowledge (e.g. fixing a routine of STRING). | * Changing a kernel library class which does not involve a special compiler knowledge (e.g. fixing a routine of STRING). | ||
| − | |||
==Bootstrapping the compiler== | ==Bootstrapping the compiler== | ||
| Line 31: | Line 30: | ||
{{Note|By generated code we meant the C code because although the binaries should be exactly identical in size, they usually are not identical because most binary formats store a date in the binary and since they have not been compiled at the exact same time we cannot compare them.}} | {{Note|By generated code we meant the C code because although the binaries should be exactly identical in size, they usually are not identical because most binary formats store a date in the binary and since they have not been compiled at the exact same time we cannot compare them.}} | ||
| − | If | + | If they are not identical, then something is not right in the new code generation or in the run-time/header files, and the bootstrap process needs to be restarted from the ''original ec'' and the ''orginal delivery''. |
Of course you restart the bootstrap process after find the cause of the error and fixing it. | Of course you restart the bootstrap process after find the cause of the error and fixing it. | ||
| + | |||
| + | ==Building a delivery== | ||
| + | The above steps talk about building deliveries. Follow [[Building_a_delivery|the instructions on how to build a minimal delivery]] in a directory called EiffelXX. | ||
Latest revision as of 09:29, 26 June 2009
Contents
Definition
Check out the definition from Wikipedia to know more about bootstrapping.
Why bootstrapping?
The general idea is that when you do a change in the code generation (often for improving the speed) you want to get a compiler that has been compiled with the new code generation to benefit from the changes.
When not bootstrapping
Although you can always do a bootstrap, there are cases when it is actually not required. For example when:
- Changing an header file which will impact the C generated code in a non-intrusive way, but still requires a new runtime. In that case, no bootstrap is necessary, it suffices to copy the new header and runtime to the current delivery.
- Changing a kernel library class which does not involve a special compiler knowledge (e.g. fixing a routine of STRING).
Bootstrapping the compiler
Initial compiler
To start the bootstrap process you have to start from a working compiler, this is usually one of the released version. Let's call this compiler original ec and its delivery original_delivery.
First step
Using original ec and the configuration file finalize a new ec, this version is called ec_level1. This version is compiled with the header files and run-time of the original delivery.
Second step
Compile a new run-time and copy the headers to a new delivery level1 delivery, as well as the new ec_level1 executable. Now repeat the first step, you now get a version called ec_level2. This version is obviously compiled with the header files and run-time of the level11 delivery.
Final step
Using the same level1 delivery, but this time using the ec_level2 executable, repeat the first step, you now get a version called ec_level3. This version is also called the bootstrapped version.
How do we find if it really worked?
If everything went well, the generated code for ec_level2 and ec_level3 should be identical.
Note: By generated code we meant the C code because although the binaries should be exactly identical in size, they usually are not identical because most binary formats store a date in the binary and since they have not been compiled at the exact same time we cannot compare them.
If they are not identical, then something is not right in the new code generation or in the run-time/header files, and the bootstrap process needs to be restarted from the original ec and the orginal delivery.
Of course you restart the bootstrap process after find the cause of the error and fixing it.
Building a delivery
The above steps talk about building deliveries. Follow the instructions on how to build a minimal delivery in a directory called EiffelXX.
