Agh, I forgot to mention something about my uses that is important: I don't compile to a file. I compile to machine code in memory. I hope that wasn't confusing. On Oct 10, 2012 8:54 AM, "David Mertens" <[email protected]> wrote:
> Oleg, > > I think you missed Jared's point. There are many things one can try to > target in a compiler. These include small compiler, fast compiler, produce > compact executables, produce fast executables, and so on. GCC focuses on > building fast executables. TCC's main goal is to quickly compile code. I > repeat: runtime performance is not TCC's primary target. Minimizing code > loading time would improve runtime performance at the cost of compile time, > so you're not likely to get a lot of traction with your idea. > > Can you think of a way to get smart linking to work with the many varied > uses of TCC? I use TCC to compile C code on the fly in Perl scripts and > call the resulting functions from my Perl code as I see fit. I don't expect > smart linking to buy me much, if anything, but I do expect it to complicate > TCC's internals and potentially slow it down. I am only one voice---and I > am a user, not a developer---but I don't think that's a trade-off that I > like much. > > TCC is an open source project, of course. Perhaps your best solution is to > fork it and add your own smart linking optimizations. > > David > On Oct 10, 2012 2:11 AM, "Oleg N. Cher" <[email protected]> wrote: > >> I would mentioned that Turbo Pascal (7.1) has very fast compilation too, >> and was very compact - command-line compiler tpc.exe is 75 Kb. Then I do >> not agree with the fact that "smart" linking feature is a redundant in TCC. >> It's the absolutely necessary feature, especially if you actively work with >> large libraries and do not want to include all code from the libraries into >> your software. >> >> >> Jared Maddox wrote: >> >>> Actually, TCC is about compiling code quickly. It is most appropriate >>> for compiling other compilers, quickly testing code, and compiling >>> code as part of a JIT engine. There's nothing wrong with an 'extended' >>> TCC, but any such thing should be kept mostly or entirely separate >>> from TCC itself. >>> >> Oleg N. Cher, >> VEDAsoft Oberon Club >> http://zx.oberon2.ru >> >> ______________________________**_________________ >> Tinycc-devel mailing list >> [email protected] >> https://lists.nongnu.org/**mailman/listinfo/tinycc-devel<https://lists.nongnu.org/mailman/listinfo/tinycc-devel> >> >
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
