🚀 go-pugleaf

 sa021pl@unidui.uni-duisburg.de (Joerg Pleumann) wrote:
> Hallo,
> 
> ich hab gestern versuchsweise mal den EMX 0.9a mit Fix#6 und GNU C 2.7.0
> unter OS/2 Warp installiert. Dann hab ich - vielleicht sollte ich
> erwaehnen, dass ich von C nicht besonders viel Ahnung habe - ein bisschen
> in C und C++ herumexperimentiert. Das Ergebnis meiner Experimente hat mich
> ein wenig erschreckt. Vielleicht kann mir jemand sagen, was ich falsch
> mache oder warum das, was mich stoert, sonst keinen stoert:
> 
> 1) Das uebliche Hello-World in C mit stdio.h war bei Weglassen aller
>    Symbolinformationen immer noch satte 24 KB groá. Ein bisschen happig
>    fuer die simple Ausgabe eines konstanten Textstrings.

Nun ja, dazu ist erst einmal zu sagen, dass du als Basis immer den
elementaren startup-code drin hast. Frag mich nicht, was der genau
macht, aber wahrscheinlich unter anderem Initialisierung der I/O und
des Speichermanagements.
Wenn du wikrlch Wert darauf legst, so einfache Programme kleienr zu
machen, gibt es folgende Moeglichkeiten:

- puts statt printf verwenden. printf ist recht komplex und daher auch
  ziemlich gross
  
- beim Kompilieren die Option -Zomf verwenden, dann werden
  Standard-OS/2 object files erstellt und der link386 verwendet. Bei
  der normalen Vorgehensweise wird wohl noch irgendwas dazugelinkt,
  damit die Programme auch unter nem Dosextender (eben dem emx.exe)
  laufen koennen.
  
- Dann gibts doch die Option -Zcrtdll (oder -Zmtd). Dann wird der
  Startupcode dynamisch dazugelinkt. Allerding slaueft das Programm dann
  nicht mehr ohne die DLLs (emxlibc...). Ausserdem gibts noch ein paar
  weitere switches, die stehen aber in doc/emxdev.doc

- Und zu guter letzt kannst du fuer Warp noch /Zlinker /exepack:2
  angeben, damit der link386 das Programm mit dem neuen Packmodus
  linkt.
  

> 2) Das entsprechende Programm in C++ mit iostream.h liess sich nicht auf
>    weniger als 64 KB bringen.

Tja, das ist wohl die Groesse der gcc iostream-library. Kann man wohl
nix machen,. befuerchte ich.

> 3) Ein Mini-Programm mit einer eigenen Klasse mit mehreren Feldern vom
>    Typ String und ein paar Billig-Methoden war irgendwas um 120 KB gross.

Hmm, _das_ finde ich allerdings etwas seltsam. Hast du das auch ohne
debug-info uebersetzt?

> Wie kommen diese Code-Groessen zustande? Ist das etwa normal fuer C? Dann
> kann ich ja gleich in Visual Basic programmieren und immer eine 5 MB DLL
> zu meinen Programmen dazugeben. Oder verhaelt sich nur GNU C so? Oder mache
> ich irgendwas falsch, gibt's da einen Parameter -SMALLEXE, den ich noch
> nicht entdeckt habe? :-)

Der GNU C-Compiler erzeugt eigentlich sehr guten (schnellen und
kleinen) Code. Allerdings kann ich zum C++-Compiler nichts sagen, es
kann sein, dass der nicht so gut wie der reine C-Teil ist.
Die recht grossen files, die bei kleinen Prograemmchen entstehen,
darfst du nicht so ernst nehmen, das liegt halt am dazugelinkten Code.
Dafuer waechst die Codegroesse dann bei steigender Komplexitaet des
Quellcodes aber auch nur langsam.
Dein kleines C++-Beispiel wundert mich hier etwas. Was meinst du mit
'Feldern vom Typ String'? Benutzt du fertige String-Klassen vom GNU?
Vielleicht liegts daran.

--
Frank Thilo   -  gl600@appl2.hrz.uni-siegen.de
IRC: Chestal  -  <A HREF="http://vespa.unix-ag.uni-siegen.de/~thilo"></A>

In <YrjLwYkkusiW084yn@unidui.uni-duisburg.de> sa021pl@unidui.uni-duisburg.de (Joerg Pleumann) writes:
>1) Das uebliche Hello-World in C mit stdio.h war bei Weglassen aller
>   Symbolinformationen immer noch satte 24 KB groá. Ein bisschen happig
>   fuer die simple Ausgabe eines konstanten Textstrings.

Zunaechst einmal hast Du fuer die Ausgabe des Strings die
Funktion printf() verwendet. Das bedeutet, dass auch format()
und eine ganze Galerie weitere Funktionen aus der libc.a mit zu
Deinen Programm dazugebunden werden muessen, weil sich printf()
auf diese Funktionen beruft, um seine Dausgabe zu erzeugen.
(Anmerkung: Diese Erklaerung gilt nur, wenn Du auf einem System
arbeitest, auf dem die libc statisch zu Deinem Programm gebunden wird.
Wenn Du eine libc_s.a bzw. eine LIBC.DLL hast, kommen durch
Verwendung von printf() kaum weitere Funktionen dazu).

Viele moderne Unices erlauben ausserdem, direkt aus der
Objektdatei zu pagen. In diesem Fall wird beim Aufruf des
Programms der Code des Programmes nicht geladen, sondern nur in
den virtuellen Speicher gemapped und zwar so, dass das Mapping
fuer Textsegmente und nicht beschreibbare Datensegmente nicht in
die Auslagerungsdatei zeigt, sondern direkt in die
Programmdatei. Dadurch wird Platz in der Auslagerungsdatei
eingespart.

Durch die Ausfuehrung des Programmes werden dann Seitenfehler
erzeugt, die das Laden der Programmseiten in den Speicher direkt
aus der Programmdatei erlauben, ohne dass die Auslagerungsdatei
bemueht werden muss. Damit das funktioniert, muessen die
Programmsegmente in der Programmdatei aber genau so gross sein,
wie die Speicherseiten, die von der Speicherverwaltung des
Systems verarbeitet werden. Das bedeutet also, dass die Segmente
in der ausfuehrbaren Datei auf eine Seitengroesse aufgefuellt
werden.

Hier unter Nextstep auf einer NeXTstation (Motorola 680x0,
Seitengroesse 8 KB, paging aus Programmdateien):

kris@black /tmp> cat probe.c

main()
{
        printf("Hello, world\n");
}

kris@black /tmp> cc -v
Reading specs from /lib/m68k/specs
NeXT Computer, Inc. version cc-216.obj~13, gcc version 2.2.2
kris@black /tmp> cc -o probe probe.c
kris@black /tmp> cc -g -o probe-symdeb probe.c
kris@black /tmp> cc -s -o probe-strip probe.c
kris@black /tmp> cc -s -object -o probe-strip-merge probe.c
kris@black /tmp> l pro*
-rwxr-xr-x  1 kris     wheel      48952 Aug 14 09:29 probe*
-rwxr-xr-x  1 kris     wheel      16384 Aug 14 09:29 probe-strip*
-rwxr-xr-x  1 kris     wheel       1252 Aug 14 09:33 probe-strip-merge*
-rwxr-xr-x  1 kris     wheel      49660 Aug 14 09:39 probe-symdeb*
-rw-r--r--  1 kris     wheel         39 Aug 14 09:29 probe.c

Das Programm probe ist ohne Stripping entstanden. Es enthaelt
Segmente und Symboltabellen, jedoch keine ausreichende
Information fuer symbolisches Debugging. Mit der Option -g wird
symdeb-Information in die Objektdatei eingebracht und die Datei
wird noch etwas groesser.

Stripping bringt nicht sonderlich viel, weil die Segmente der
Programmdatei auch in probe-strip noch aufgeblasen werden. Erst,
wenn man erlaubt, dass die Segmente nicht aufgeblasen werden,
bekommt man die minimale Programmgroesse unter Verwendung von
printf().

Man kann das Programm natuerlich noch weiter verkleinern, indem
man es ein wenig aendert:

kris@black /tmp> cat p2.c

static char text[]="Hello, world\n";

main()
{
        write(1, text, 13);
}
kris@black /tmp> cc -O4 -S -o p2.s p2.c
kris@black /tmp> cat p2.s
.data
_text:
        .ascii "Hello, world\12\0"
.text
        .align 1
.globl _main
_main:
        link a6,#0
        pea 13:w
        pea _text
        pea 1:w
        jbsr _write
        unlk a6
        rts
kris@black /tmp> cc -O4 -object -s -o p2 p2.c
kris@black /tmp> ./p2
Hello, world
kris@black /tmp> l p2
-rwxr-xr-x  1 kris     wheel       1188 Aug 14 09:49 p2*

Aber wie man sieht, bringt es das auch nicht. Unter Nextstep
brauchen die Load-Commands des MachO Objektformates den
restlichen Platz von einem KB. Mit otool bekommt man sie
aufgelistet.

Kristian
-- 
Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897
".sig 1-.sig 3 were sabotaged during editing. .sig 4 disappeared
 24 hours after completion. .sig 5 was our last best hope for peace.
 It  failed. In the year of the Editor War...."  -- stolen from Ron Peterson

Joerg Pleumann (sa021pl@unidui.uni-duisburg.de) wrote:
> Wie kommen diese Code-Groessen zustande? Ist das etwa normal fuer C? Dann
> kann ich ja gleich in Visual Basic programmieren und immer eine 5 MB DLL
> zu meinen Programmen dazugeben. Oder verhaelt sich nur GNU C so? Oder mache
> ich irgendwas falsch, gibt's da einen Parameter -SMALLEXE, den ich noch
> nicht entdeckt habe? :-)

C bzw. der dafuer verwendete, "normale" Linker ist nicht besonders gut im
aussortieren von Code der nicht benoetigt wird. Wenn der Linker eine Referenz
in ein Object File findet, dann wird der gesamte Inhalt des Object Files zum
Executable hinzugelinkt, ohne weitere Pruefungen, ob vielleicht nur eine der
drei darin enthaltenen Funktionen benoetigt wird.

Der Effekt gibt sich etwas mit groesseren Programmen, da dann die Wahrschein-
lichkeit gross ist, dass Du mehr als eine Routine aus einem Object File
tatsaechlich nutzt. D.h. die Executables werden nicht in demselben Masse
groesser wie Deine Quellen.

Was noch dazu kommt ist, dass GNU-C im Vergleich zu anderen Compilern recht
umfangreichen (aber auch schnellen) Code erzeugt. Damit Du Dir vorstellen
kannst, in welchem Umfang sich die Compiler hier unterscheiden mal die
Groesse ein und desselben Programms auf den unterschiedlichen Plattformen:

	Linux (Compiler: gcc)		484356
	OS/2 (Compiler: Watcom)		308352
	DOS (Compiler: Watcom)		372940

Alle Programme sind statisch gelinkt und entstehen bis auf ein paar Routinen
zum Bildschirm/Tastatur I/O aus denselben Sourcen. Inwiefern die Groesse vom
Format des Executables abhaengt (DOS: EXE, OS/2: LX, Linux: a.out) ist mir
nicht klar, ich denke aber, dass sich die grossen Unterschiede dadurch nicht
erklaeren lassen.

Wahrscheinlich musst Du mit dem Speicherbedarf einfach leben (vielleicht noch
etwas RAM nachstecken).

Gruss


	Uz


-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com

In de.comp.lang.c, sa021pl@unidui.uni-duisburg.de (Joerg Pleumann) wrote:

>1) Das uebliche Hello-World in C mit stdio.h war bei Weglassen aller
>   Symbolinformationen immer noch satte 24 KB groá.

Naja, printf() ist eine ziemlich komplizierte Funktion, mit vielen
Konvertierungsmoeglichkeiten.  Die muss halt komplett mitgeschleppt
werden.

Probier's mal mit puts(), da sollte die Sache besser aussehen.
-- 
Thomas König, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.

Joerg Pleumann (sa021pl@unidui.uni-duisburg.de) wrote:

> 1) Das uebliche Hello-World in C mit stdio.h war bei Weglassen aller
>    Symbolinformationen immer noch satte 24 KB groá. Ein bisschen happig
>    fuer die simple Ausgabe eines konstanten Textstrings.

> 2) Das entsprechende Programm in C++ mit iostream.h liess sich nicht auf
>    weniger als 64 KB bringen.

> 3) Ein Mini-Programm mit einer eigenen Klasse mit mehreren Feldern vom
>    Typ String und ein paar Billig-Methoden war irgendwas um 120 KB gross.

> Wie kommen diese Code-Groessen zustande? Ist das etwa normal fuer C?

Nein, aber es ist normal fuer das was Du programmiert hast.
Betrachten wir Dein "Hello World":

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
  printf("Hello world\n");
  return EXIT_SUCCESS;
}

Sieht kurz aus, oder? Ist es aber nicht:
- printf() ist eine eierlegende Wollmichsau. Da wandert Fliesskommacode,
  etliche Formatierfunktionen (schon mal die man-page von printf()
  gelesen?) und noch einiges mehr in das Executable.
  Der Compiler kennt printf() ja nicht, er generiert einfach einen
  Aufruf fuer eine unbekannte Funktion namens printf(). Der Linker
  wiederum packt die ganze Mega-Funktion printf() in Dein Programm,
  da er ja nicht weiss welche Teile davon gebraucht werden
- der uebliche Startup-Code ist ebenfalls dabei: Kommandozeilenparsing
  (-> argc, argv), Bereitstellen von stdin, stdout und stderr als
  stdio-Streams und vermutlich auch die Installation einer Speicher-
  verwaltung fuer malloc(). Und natuerlich jede Menge Cleanup-Code.
  Dass diese Dinge nicht benoetigt werden weiss ja niemand :)

Bei C++ ist es aehnlich. Eine Klasse zieht meistens etliche KB Code
mit in das Executable; woran das liegt kann ich aber nicht schluessig
erklaeren weil ich C++ nicht kenne.

Du darfst Du Dich durch die Groesse der Mini-Programme nicht erschrecken
lassen. Vieles ist Overhead der nur einmal im Executable auftaucht,
egal wie gross das Programm ist. Wenn also bei Deinem 24KB Hello-World
23KB Overhead sind, dann hat auch ein Programm mit 100000 Zeilen
vielleicht nur diese 23KB Overhead.

> 	Joerg

Christian


--
  //   Christian Stieber               Stieber@Informatik.TU-Muenchen.de
\//    Certified Amiga Developer       http://www.leo.org/~stieber/
--------------------------------------------------------------------------
			  Nobody, just nobody