Potential of a compiler that creates the executable at once
rempas
rempas at tutanota.com
Fri Feb 11 20:10:17 UTC 2022
On Friday, 11 February 2022 at 17:36:03 UTC, Patrick Schluter
wrote:
>
> If one wants to get really historic it is also what made Turbo
> Pascal did up to version 3.0. With Turbo Pascal 4.0 they went
> back to more classic object file/linker and there is a good
> reason for that. Separate compilation and linking modules and
> libraries are a thing. If you build the compiler for direct
> executable production you have to still support normal object
> file/library handling i.e. you put the functionality of the
> linker into your compiler.
Yep and that's what I love about it! You can have 2 ways to do
the same thing and choose based on what's best for the case.
For example, if your projects has 10M LoC, even if you can
compiler 1M LoC/S (which is a very big number), your project will
need 10 seconds to build which will make it very annoying. In
that case, we use the classic method of creating object files to
the files that were changed and then link them together.
However, if your project is 1M LoC or less, that is less than 1
second to build it which is not noticeable at all. The same
happens when the end-user compiles the software from source and
doesn't care (and won't even keep) about the object files because
he/she is not a developer. In that case it makes sense to not
waste time creating the object file and go straight creating the
executable/library.
If we are to make a new compiler (which I plan to), we should
create a whole toolchain that will consist of all the tools.
Sounds complex, I know but what's the point if we don't advance?
Make another compiler that outputs assembly so it will always
have dependencies and it will be slow to compile (slow compared
to if we outputted machine language directly)?
More information about the Digitalmars-d
mailing list