USING C SET++ INVOKING COMPILER VIA XLC GIVE HUGE
ITEM: RTA000046469
QUESTION:
Customer has just installed the C++ PowerBench (C Set++ and WorkBench).
Have noticed that the size of the executable differ immensely if
he initiates the compiler via cc versus xlC.
Eg a simple program compiled via:
cc -o out1 out1.c yields out1 of size 4550bytes via ls -l
whereas
xlC -o out1 out1.c yields out1 of size 10343bytes again using ls -l.
Hence the executable of xlC is more than DOUBLE that of the old cc
Q: The user's manual suggests we should use the xlC version but given
that the executables are more than double of the old we are
hesitant to use xlC rather than cc.
Could you explain why the executables of xlC are huge compared
with cc and what advantages above cc, xlC provides??
---------- ---------- ---------- --------- ---------- ----------
A: To test this question I did several compiles of different
size files with both 'cc' and 'xlC'. Following are my results:
Source xlC executable cc executable difference between
(bytes) (bytes) (bytes) xlC and cc (bytes)
-------- -------------- ------------- ------------------
169 8733 3049 5684
7483 19855 14193 5662
88808 154655 148993 5662
1419292 2593471 2587821 5650
Apparently xlC adds an additional block of information to
each executable of approximately 5.2 KB. Other than this
block, the size of the object code remains roughly equivalent.
I assume that your questions on executable size and the advantages
of xlC are based on the assumption that xlC executable sizes are
double that of cc executable sizes for all sizes of source code.
Since this is not the case, would you still like me to address
the issue of the advantages of xlC over cc and the technical
explanation of the extra 5.2 KB block? If so, please reopen
this item and I will do the extra research necessary to address
those points.
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
We did not compare the sizes as thoroughly as you. We would however
like to know the technical explanation of the approx. 5.2KB extra
bytes for xlC as opposed to cc.
---------- ---------- ---------- --------- ---------- ----------
A: Using a small example program, we verified the sizing results reported
in this item above. Using the "/usr/ucb/nm" command to view the symbols
that reside within the executable, we found additional functions in the
C++ version. These functions provide additional start-up services for
the application, as well as shut-down services, code to "catch" throws,
static constructor/destructor location and invocation routines, and the
like.
The code size increase results from lots of implementation-dependant
things that are not documented on purpose, and from a functional stand-
point should not be a concern to the user. From a size standpoint, the
size of this additional code can change over time; the current 5K size
should not be considered "fixed".
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
What is of concern is if the size GROWS on a developers device who
compiles a lot of programs but with limited disk space. 5.2KB may
not be "much" now, but if it were to double the size of the executable
xlC will NOT be accepted unless there are very tangible benefits.
Benefits which are CLEARLY spelled out versus competitive compilers
which may produce smaller executables.
---------- ---------- ---------- --------- ---------- ----------
A: The overhead of the C++ startup vs. C is a language issue. As such,
it is not described in the documentation. The development staff makes
every effort to minimize this application-specific overhead, and the
current amount is as small as possible.
---------- ---------- ---------- --------- ---------- ----------
This item was created from library item Q668013 CVBKW
Additional search words:
CC COMPILE COMPILER COMPILERS CVBKW EXECUTABLE HUGE INVOKING IX
OZIBM OZNEW RISCL RISCSYSTEM SEP94 SET SETTING SOFTWARE VERSUS XLC
WWQA: ITEM: RTA000046469 ITEM: RTA000046469
Dated: 06/1996 Category: RISCL
This HTML file was generated 99/06/24~12:43:18
Comments or suggestions?
Contact us