From mboxrd@z Thu Jan  1 00:00:00 1970
Received: by margaux.inria.fr, Tue, 13 Oct 92 21:04:12 +0100
Received: from pomerol.inria.fr by margaux.inria.fr, Tue, 13 Oct 92 20:58:08 +0100
Received: by pomerol.inria.fr, Tue, 13 Oct 92 20:58:06 +0100
From: Xavier Leroy <xleroy@pomerol>
Message-Id: <9210131958.AA25408@pomerol.inria.fr>
Subject: Re: Enrichir 'camltop' avec des primitives C
To: caml-list@margaux
Date: Tue, 13 Oct 92 20:58:06 MET
Sender: weis@margaux

En reponse au message de Claude Fleurey: il est tout a fait normal que
les ``custom toplevels'' construits avec camlmktop et integrant des
primitives C fournies par l'utilisateur soient nettement plus gros que
le toplevel standard camltop, meme si le code ajoute (fichiers .zo
et .o) est de petite taille. En effet (et ceci s'applique non
seulement aux toplevels construits avec camlmktop, mais aussi aux
executables construits par camlc), tout executable construit avec
l'option "-custom", et donc a fortiori tout executable integrant des
primitives C de l'utilisateur, contient:

        1- du code machine pour le runtime + les primitives
           de l'utilisateur
        2- du bytecode pour le code ML

alors que les executables construits sans l'option "-custom"
contiennent seulement:


        1- un en-tete pour appeler le runtime partage
        2- du bytecode pour le code ML.

Le code machine pour le runtime est assez gros (de 50 a 200k, suivant
les architectures de machines), beaucoup plus que l'en-tete pour
appeler le runtime partage, ce qui explique pourquoi les executables
construits avec l'option "-custom" sont nettement plus gros.

- Xavier Leroy