Re: Optimization techniques and runtime checks

> [For embedded applications there are systems where the object code
> that the compiler generates is really the intermediate code from the
> first pass of the compiler, and the linker reads everything in
> including the libraries and does the optimization and code generation
> on the whole thing.  Dunno how fast it is but it is my impression that
> all of the code in the chips in your car was built that way. -John]


There is a kernel of truth in there, but you are mixing a few things
together.


For some small microcontrollers, especially those with "brain-dead"
processors like 8051 cpus, many toolchains do "whole program
optimisation". For chips like these, you don't have a decent data stack
(there are not "sp + offset" addressing modes), and ram is often in
banks. To get efficient code, the compiler needs to try to fit local
variables and parameters into static ram addresses, re-using them when
possible, and consider code flow patterns when deciding which banks to
use for different types of data. This is not done by a compiler and
linker as you describe, but having a single program that takes all the C
code from all the files, and treats it as a single unit (roughly
speaking, you rename every file-static function and variable, adding the
filename to the identifier, then make almost everything "static").
There are not separate compile and link stages.




For larger processors (of which there are many in modern cars) using
modern compilers, you can have "link time optimisation". Here each unit
is handled by the compiler to produce a intermediary code in internal
formats - but it is not just from the first pass. This code is
analysed, warnings are generated when possible, and a large amount of
optimisation is carried out while still in the internal formats. The
linker then combines these (from many files), and passes the combination
back to the compiler for further processing. For scalability, this can
be done in repeated steps with different groups of files, rather than
all at once - when building Firefox or LibreOffice, you want to take
advantage of your 64-core build system.
[Sounds reasonable. I was thinking of the ARM tools which I suppose do
more than a tyrpical first pass before handing stuff off to the linker. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.