Re: opinions wanted on control of extern inlines

Thanks to every one for their replies. Your advice was valuable and
carefully considered. I'm posting this reply in the hope of provoking
more thought and as a reference to anyone who may in the future follow
these footsteps.


The problem is a little more complex that my orignal email may have
suggested.


The original image size was 6.5 Mb when compiled with the CLC++ compiler
from centerline with gcc as the back end, using a template repository
mechanism (now obsolete and nolonger supported). This compiler did cause
code bloat due to the production of extern copies of inline functions.
To minimize this the c++ source was catenated into aggregate files each
of which was some 10% to 15% the total source (the total source is about
500,000 lines of c++).


As mentioned in my previous mail the default gcc behaviour produces an
image of 32 Mb. If a closed template library is built the image reduces
to some 13 Mb while the -frepo flag (of the repo patch) can reduce the
image to 9.5 Mb. The unexplained 3 Mb I suggest is caused by vtable
production and inefficient creation of extern inlines.


However the repo patch cannot be employed as a viewpathing mechanism is
used to undertake changes to code. The repo patch can (and does) try to
recompile official build source from down the viewpath, which fails
since since users don't have write permission to these directories.


The use of other compilers is questionable. Wind River Systems (WRS) do
not support the loading of ELF object files onto an embedded sparc
target so any compiler must produce the default a.out-coff format for
sparc chips. There is also the question of tool support since some
functionality may be lost with other compilers (although we can probably
live with some loss of tool functionality if the core is left intact).


My original suggest seems to be flawed. The #pragma interface and
#pragma implementation directives cause a closed set of templates, to be
produced so the suggested method would still only reduce the image size
to 9.5 Mb (it would probably be smaller due to savings made on inlines
and vtables).


I would now suggest a two stage approach. Using the gcc 2.8.0 compiler.
A parsing of the preprocessed c++ and the use of pragma directive to
control vtables and inlines. This stage would also pick out the header
files and template declarations. After the compile a second subprogram
will pick out the undefined references to templates and (using the
extentions present in the 2.8.0 compiler) cause individual template
methods to be instantiated as necessary.


This would seem easy to implement that my original suggestion, be
compatable with our environment and the products supplied by WRS, while
reducing the image size as much as possible. It would also seem to be
more unlikely to suffer from unforseen problems, and easier to modify if
complication arise.


As always, opinion and advise would be most welcome, and once again
thanks to all who answered my original mail.


Oh - I will put any code/patch onto the web for others to use once/if it
works.


regards.


Rachel-Louise


--
Rachel-Louise Koktava
KittyCrap@severins-child.demon.co.uk
--

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