Separate compilation is one solution to the problem of slow compilation.
Binary patching is another one. It feels a bit messy and I am sceptical that it can be maintained assuming it works at all.
I think a much better approach would be too make the compilers faster.
Why does compiling 1M LOC take more than 1s in unoptimized mode for any language?
My guess is part of blame lies with bloated backends and meta programming (including compile time evaluation, templates, etc.)
> Unfortunately you can't really statically link a GUI app.
But is there any fundamental reason why not?
> Also, if you happened to have linked that image to a.out it wouldn't work if
> you're using a kernel from this year, but that's probably not the case ;)
I assume you refer to the retirement of coff support (in favor of elf).
I would argue that given how long this obsolete format was supported was actually quite impressive.
Pros:
* uses Python and recursive descent parsing
* separates front and backend via an IR
* generates ELF binaries (either x86 or ARM)
* meant for real world use
Cons:
* more complex
* not written in a tutorial style
If you do embedded work, you often want to be in total control of all memory allocations. So it is good to know that the compiler will not produce some invisible
heap allocations and there is a useful subset of the standard libray that does not use them either.
yes, this sounds pretty messy and I am wondering how they deal with the different memory consistencies of the two architectures. IIRC apple CPUs have HW support for the stricter x86 model.
4) renewable energy disruptions, e.g. supervolcano eruption, large meteor strike