I am little surprised that the tone of this thread has turned negative. It is really not clear what the argument is about. Peoples preferences?
I cannot imagine that marking symbols as referenced to be expensive... If it was as simple as not outputting into target executable symbols that are not marked as used, this would be a truly simple task. And fast, while we're on it. However, the problem arises when linking with libraries, which is already compiled code. When including a symbol from a library, a mechanism needs to be created to determine which symbols this routine references, and then recursively repeat the process. I admit that I am not expert on binary and library formats... The only way I can think of doing this is to examine relocation tables, and hopefully extract/deduce this information from it. However I don't know if this is even possible. So, this could be a non trivial and not so fast operation. Regarding the comparison to Turbo Pascal, if I remember correctly, they used their own library format, and it might contain this dependency information that can be used to quickly eliminate unused code. tcc however needs to use standard formats. All in all, the problem does not seem trivial, and is made worse by the fact that it needs to work with multiple file formats/platform. Judging by activity of this project, it seems little ambitious. Miki. On 10 October 2012 14:38, Oleg N. Cher <[email protected]> wrote: > Дмитрий пишет: > > Do you really believe that the inclusion of unused code in the target >>> binary file will be faster than a smart linking? >>> >>> >> Maybe it's not, but, since no one is willing to implement the latter >> anyway, why argue? >> >> > I still hope that sane person will read this post. And at least agree with > my arguments. > > Smart linking is the norm in the Pascal world, which has long set > TurboPascal. You found the different of obstacles for the generation of > reduced-size code, justifying it with the desire to have a fast compilation > speed and the small size of the compiler itself. But you appeals to the > fact that the compiler may be placed on a floppy disk, and very happy. I do > not use a floppy disk. You do not use a floppy disk. We do use RAM and > flash memory on a few gigabytes and a very quick Internet channels. You do > agree, compiler size does not really matter. Moreover, smart linking > feature is a really special quality of good compiler. Compiling time? Heh, > with separate compilation, search in binary tree and mark code as unused is > microseconds. And a complete including a large library to target binary is > disk IO operations and already not microseconds, but much more. > > Or the implementation >>> of this feature will take a lot of megabytes of space in the amount of >>> the compiler? >>> >>> >> Maybe a single feature wouldn't, but the desire to include all the >> features possible certainly would. >> >> > If you do not want to do anything in this direction, what to justify their > laziness empty words? > > > > 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
