<HTML>
<HEAD>
<TITLE>Conventions d'appel</TITLE>
</HEAD>
<BODY>
<H1>5. <A NAME="s5"></A>Conventions d'appel</H1>
<P>
<A HREF="Assembly-HOWTO.html#toc5">Contenu de cette section</A></P>
<P></P>
<P></P>
<P></P>
<H2>5.1 <A NAME="ss5.1"></A> Linux</H2>
<P></P>
<P></P>
<H3>Edition de liens avec GCC</H3>
<P></P>
<P>C'est la solution la plus pratique.
Consultez la documentation de gcc
et prenez exemple sur les sources du noyau Linux
(fichiers <CODE>.S</CODE> qui sont utilisés avec gas, non pas as86).</P>
<P>Les arguments 32 bits sont empilés dans la pile vers le bas dans
l'ordre inverse de l'ordre syntaxique
(c'est-à-dire qu'on accède aux arguments ou les dépile
dans l'ordre syntaxique), au-dessus de l'adresse de retour 32 bits.
<CODE>%ebp</CODE>, <CODE>%esi</CODE>, <CODE>%edi</CODE>,
<CODE>%ebx</CODE> doivent être conservés par l'appelé,
les autres registres peuvent être détruits;
<CODE>%eax</CODE> doit contenir le résultat,
ou <CODE>%edx:%eax</CODE> pour des résultats sur 64 bits.</P>
<P>Pile virgule flottante: je ne suis pas sûr,
mais je pense que le résultat se trouve dans <CODE>st(0)</CODE>,
la pile étant à la discrétion de l'appelé.</P>
<P>Notez que GCC possède certaines options pour modifier les conventions
d'appel en réservant certains registres, en mettant les arguments dans des
registres, en supposant que l'on ne possède pas de FPU, etc.
Consultez les pages .info concernant le i386.</P>
<P>Il faut prendre garde à déclarer l'attribut <CODE>cdecl</CODE> pour une
fonction qui suit la convention standard GCC (je ne sais pas exactement
ce que cela produit avec des conventions modifiées). Consultez la
documentation GCC dans la section: <CODE>C Extensions::Extended Asm::</CODE></P>
<P></P>
<P></P>
<H3>Problèmes ELF et a.out</H3>
<P></P>
<P>Certains compilateurs C ajoutent un underscore avant tout symbole,
alors que d'autres ne le font pas.</P>
<P>En particulier, la version GCC a.out effectue ce genre d'ajouts, alors
que la version ELF ne le fait pas.</P>
<P>Si vous êtes confronté à ce problème, regardez comment des paquetages
existants traitent le problèmes. Par exemple, récupérer une ancienne
arborescence des sources de Linux, Elk, les
qthreads ou OCAML...</P>
<P>Vous pouvez également redéfinir le renommage implicite de C en assembleur
en ajoutant les instructions suivantes:
<HR>
<PRE>
void truc asm(&quot;machin&quot;) (void);
</PRE>
<HR>
pour s'assurer que la fonction C truc sera réellement appelée
machin en assembleur.</P>
<P>Remarquez que l'outil <CODE>objcopy</CODE>, du paquetage <CODE>binutils</CODE>,
devrait vous permettre de transformer vos fichiers objets a.out
en objets ELF et peut-être inversement dans certains cas.
D'une manière plus générale, il vous permet d'effectuer
de nombreuses conversions de formats de fichiers.</P>
<P></P>
<P></P>
<H3>Appels systèmes directs</H3>
<P></P>
<P>Il n'est absolument pas recommandé d'effectuer de tels appels
par ce que leurs conventions peuvent changer de temps en temps,
ou d'un type de noyau à un autre (cf L4Linux),
de plus, ce n'est pas portable, difficile à écrire,
redondant avec l'effort entrepris par libc,
et enfin, cela empêche les corrections et les extensions effectuées
à travers la libc, comme par exemple avec le programme <CODE>zlibc</CODE>
qui réalise une décompression à la volée de fichiers compressés avec gzip.
La manière standard et recommendée d'effectuer des appels systèmes
est et restera de passer par la libc.</P>
<P>Les objets partagés devraient réduire l'occupation mémoire des programmes,
et si vous souhaitez absolument avoir de petits exécutables, utilisez
<CODE>#!</CODE> avec un interpréteur qui contiendra tout ce que
vous ne voulez pas mettre dans vos binaires.</P>
<P>Maintenant, si pour certaines raisons, vous ne souhaitez pas effectuer
une édition des liens avec la libc, récupérez-la et essayez de comprendre
comment elle fonctionne! Après tout, vous prétendez bien la remplacer
non? </P>
<P>Vous pouvez aussi regarder comment
<A HREF="ftp://ftp.forth.org/pub/Forth/Linux/linux-eforth-1.0c.tgz">eforth 1.0c</A>
le fait.</P>
<P>Les sources de Linux sont fort utiles, en particulier le fichier
d'en-tête asm/unistd.h qui décrit comment sont effectués les appels
système...</P>
<P>Le principe général est d'utiliser l'instruction
<CODE>int $0x80</CODE> avec le numéro de l'appel système
<CODE>__NR_</CODE>machin (regarder dans <CODE>asm/unistd.h</CODE>)
dans <CODE>%eax</CODE>,
et les paramètres (jusqu'à cinq) dans
<CODE>%ebx</CODE>, <CODE>%ecx</CODE>, <CODE>%edx</CODE>,
<CODE>%esi</CODE>, <CODE>%edi</CODE>. Le résultat est renvoyé dans
<CODE>%eax</CODE> avec un résultat négatif étant l'erreur
dont l'opposé est tranféré par la libc dans errno. La pile utilisateur
n'est pas modificée donc n'avez pas besoin d'en avoir une correcte
lors de l'appel.</P>
<P></P>
<P></P>
<H3>Entrées/sorties sous Linux</H3>
<P></P>
<P>Si vous souhaitez effectuer des entrées/sorties directement sous Linux,
soit il s'agit de quelque chose de très simple qui n'a pas besoin
de spécificités du système et dans ce cas là, consultez le mini-HOWTO
<CODE>IO-Port-Programming</CODE>, ou alors vous devez créer un nouveau gestionnaire
de périphérique et vous devriez alors lire quelques documents
sur les méandres du noyau, le développement de gestionnaires de
périphériques, les modules du noyau, etc. Vous trouverez d'excellents
HOWTO ou autres documents du projet LDP.</P>
<P>Plus particulièrement, si vous souhaitez réaliser des programmes
graphiques, rejoignez le projet GGI:
<A HREF="http://synergy.caltech.edu/~ggi/">http://synergy.caltech.edu/~ggi/</A>
<A HREF="http://sunserver1.rz.uni-duesseldorf.de/~becka/doc/scrdrv.html">http://sunserver1.rz.uni-duesseldorf.de/~becka/doc/scrdrv.html</A>
</P>
<P>Dans tous les cas, vous devriez plutôt utiliser l'assembleur en ligne de GCC
avec les macros provenant des fichiers linux/asm/*.h que d'écrire des
sources en assembleur pur.</P>
<P></P>
<P></P>
<H3>Accéder aux gestionnaires 16 bits avec Linux/i386</H3>
<P></P>
<P>De telles choses sont théoriquement possibles (preuve: voir
comment DOSEMU permet à des programmes d'accéder au port série), et j'ai
entendu des rumeurs que certaines personnes le font (avec le gestionnaire
PCI? Accès aux cartes VESA? PnP ISA? Je ne sais pas). Si vous avez de
plus amples précisions à ce sujet, soyez les bienvenus.
Le bon endroit à regarder est les sources du noyau, les sources de
DOSEMU (et des autres programmes se trouvant dans
<A HREF="ftp://tsx-11.mit.edu/pub/linux/ALPHA/dosemu/">le répertoire DOSEMU</A>
), ainsi que les sources d'autres
programmes bas niveaux (peut-être GGI s'il gère les cartes VESA).</P>
<P>En fait, vous devez utiliser soit le mode protégé 16 bits, soit le
mode vm86.</P>
<P>Le premier est plus simple à configurer mais il ne fonctionne
qu'avec du code ayant un comportement propre qui n'effectue pas
d'arithmétique de segments ou d'adressage absolu de segment (en particulier
pour l'adressage du segment 0), à moins que par chance tous les
segments utilisés peuvent être configuré à l'avance dans le LDT.</P>
<P>La seconde possiblité permet d'être plus "compatibles" avec
les environnements 16 bits mais il nécessite une gestion bien plus
compliquée.</P>
<P>Dans les deux cas, avant de sauter sur le code 16 bits, vous devez:
<UL>
<LI>mmapper toute adresse absolue utilisée dans le code 16 bits
(comme la ROM, les tampons vidéo, les adresses DMA et les entrées/sorties
passant des zones de mémoires mappées)
à partir de /dev/mem dans votre espace d'adressage de votre
processus.</LI>
<LI>configurer le LDT et/ou le moniteur en mode vm86.</LI>
<LI>demander au noyau les droits d'accès nécessaires
pour les entrées/sorties (voir plus haut).</LI>
</UL>
</P>
<P>Encore une fois, lisez attentivement les codes sources
situés dans le répertoire de DOSEMU et consorts,
en particulier ces mini-émulateurs permettant de faire tourner
des programmes ELKS et/ou des .COM assez simples sous Linux/i386.</P>
<P></P>
<P></P>
<P></P>
<H2>5.2 <A NAME="ss5.2"></A> DOS</H2>
<P></P>
<P>La plupart des émulateurs DOS sont livrés avec certaines interfaces
d'accès aux services DOS. Lisez leur documentation à ce sujet, mais bien
souvent, ils ne font que simuler <CODE>int $0x21</CODE> et
ainsi de suite, donc c'est comme si vous étiez en mode réel
(je doute qu'ils aient de possibilités de fonctionner avec des
opérandes 32 bits: ils ne font que réfléchir l'interruption dans
le mode réel ou dans le gestionnaire vm86).</P>
<P>Certaines documentations concernant DPMI (ou ses variantes
peuvent) être trouvées sur
<A HREF="ftp://x2ftp.oulu.fi/pub/msdos/programming/">ftp://x2ftp.oulu.fi/pub/msdos/programming/</A>
</P>
<P>DJGPP est livré avec son propre sous-ensemble, dérivé, ou remplacement
(limité) de la glibc.</P>
<P>Il est possible d'effectuer une compilation croisée de Linux vers DOS.
Consultez le répertoire devel/msdos/ de votre miroir
FTP de sunsite.unc.edu. Voir également le dos-extender MOSS
du projet Flux d'utah.</P>
<P>D'autres documentations et FAQ sont plus consacrés à DOS.
Nous déconseillons le développement sous DOS.</P>
<P></P>
<P></P>
<H2>5.3 <A NAME="ss5.3"></A> Windauberies...</H2>
<P></P>
<P>Heu, ce document ne traite que de libre logiciel.
Téléphonez-moi lorsque Windaube le deviendra ou du moins ses
outils de développement!</P>
<P>En fait, après tout, cela existe:
<A HREF="http://www.cygnus.com">Cygnus Solutions</A>
a développé la bibliothèque cygwin32.dll
pour que les programmes GNU puissent
fonctionner sur les machines MicroMerdiques.
Donc, vous pouvez utiliser GCC, GAS et tous les outils GNU ainsi que bon
nombre d'applications Unix. Consultez leur site Web.
Je (Faré) ne souhaite pas m'étendre sur la programmation sous Windaube,
mais je suis sûr que vous trouverez tout un tas d'informations partout...</P>
<P></P>
<P></P>
<H2>5.4 <A NAME="ss5.4"></A> Votre propre système d'exploitation</H2>
<P></P>
<P>Le contrôle sur le système étant ce qui attire de nombreux programmeurs
vers l'assembleur, une prémisse ou un corollaire naturel de son utilisation
est la volonté de développer son propre système d'exploitation.
Remarquons tout d'abord que tout système permettant son auto-développement
pourrait être qualifié de système d'exploitation, combien même tournerait-il
au-dessus d'un autre système sur lequel il se déchargerait de
la gestion du multitâche (Linux sur Mach) ou des entrées/sorties
(OpenGenera sur Digital Unix), etc.
Donc, pour simplifier le débogage, vous pouvez souhaiter développer
votre système d'exploitation comme étant un processus fonctionnant
sous Linux (au prix d'un certain ralentissement), puis, utiliser le
<A HREF="http://ww.cs.utah.edu/projects/flux/">Flux OS kit</A>
(qui permet l'utilisation des drivers Linux et BSD dans
votre propre système d'exploitation) pour le rendre indépendant.
Lorsque votre système est stable, il est toujours temps d'écrire
vos propres gestionnaires de matériels si c'est vraiment votre passion.</P>
<P>Ce HowTo ne couvrira pas des sujets comme le code de chargement du système,
le passage en mode 32 bits, la gestion des interruptions,
les bases concernant les horreurs des processeurs Intel
(mode protégé, V86/R86), la définition de votre format d'objets
ou de vos conventions d'appel.
L'endroit où vous pourrez trouver le plus d'informations
concernant tous ces sujets est le code source de système déjà
existants.</P>
<P>Un grand nombre de pointeurs se trouvent dans la page:
<A HREF="http://www.eleves.ens.fr:8080/home/rideau/Tunes/Review/OSes.html">http://www.eleves.ens.fr:8080/home/rideau/Tunes/Review/OSes.html</A>
</P>
<P></P>
<P></P>
<HR>
<P>
Chapitre <A HREF="Assembly-HOWTO-6.html">suivant</A>,
Chapitre <A HREF="Assembly-HOWTO-4.html">Précédent</A>
<P>
Table des matières de <A HREF="Assembly-HOWTO.html#toc5">ce chapitre</A>,
<A HREF="Assembly-HOWTO.html#toc">Table des matières</A> générale</P>
<P>
<A HREF="Assembly-HOWTO.html">Début</A> du document,
<A HREF="#0"> Début de ce chapitre</A></P>
</BODY>
</HTML>
