Discussion :

[_C_Newbie]

Salut,
Mon probleme est comment programmer en C un systeme qui n'a pas de SE????!!!
J'ai réussi à écrire un "hello world" bootsector en ASM et qui marche sur un émulateur de PC-XT (emu8086) et maintenant je veux écrire des programmes en C totalement indépendants du DOS et du BIOS.
Je sais qu'il faut écrire mes propres fonctions de bases, mais:
Quel compilateur utiliser pour avoir des binaires 16 bits mode réel et sans les entêtes (raw binary)?
Comment ajouter mes fonctions écrites en ASM ou en C?
etc etc
Merci

[Kannagi]

Et c'est quoi exactement le souci ?
Le probleme n'est pas du C la.

Quel compilateur utiliser pour avoir des binaires 16 bits mode réel et sans les entêtes (raw binary)?

Je pense que n'importe quel compilateur C digne de ce nom permet de faire une compilation en binaire

Comment ajouter mes fonctions écrites en ASM ou en C?

Il y a plusieurs façon de faire cela , soit de rajouter en C de l'asm inline , soit de le rajouter pendant le link tes .o

Enfaite la question que j'ai a te poser , sait tu utilise gcc ?
Parce que gcc permet de faire tout cela , mais la ce n'est pas un souci de l'asm , ni du C mais de savoir utiliser un logiciel (ici gcc) , savoir chercher sur le net et lire une doc.

[Obsidian]

Bonjour,
C'est moi qui ai conseillé à _C_Newbie d'écrire en « programmation d'OS » ou « forum C » en fonction de ce qu'il voulait faire exactement.

Quel compilateur utiliser pour avoir des binaires 16 bits mode réel et sans les entêtes (raw binary)?

Concrètement, comme indiqué par Kannagi, n'importe quel compilateur C devrait faire l'affaire, mais certaines suites sont faites pour être utilisées partout et d'autres ciblent plus spécifiquement une plateforme en particulier. Dans tous les cas, il faut commencer par utiliser un compilateur qui soit capable de produire du langage machine pour le CPU que tu comptes utiliser (ici x86 16 bits).

Si tu utilises GCC, tu peux lui passer l'option « -m16 » qui va se charger de mettre en place tout ce qu'il faut pour que le code produit puisse fonctionner en mode 16 bits.

Par contre, ton compilateur, par défaut, va produire des fichiers objets « *.o » ou « *.obj » d'un certain format et faits pour être utilisés par tous les outils, y compris le compilateur lui-même. En extraire la substantifique moelle pour en faire soit un exécutable d'un format donné, soit pour en extraire le code, est en principe le travail de l'éditeur de liens (ou linker). Sous Unix et Linux, il s'agit de ld. ld prend en charge un certain nombre de formats mais, malheureusement (en ce qui concerne la version GNU, à tout le moins), il ne permet pas d'extraire facilement le code nu.

Personnellement, j'utilise objdump pour manipuler les fichiers objets (au format ELF) sous Linux et en extraire la section qui m'intéresse.

Comment ajouter mes fonctions écrites en ASM ou en C?
etc etc
Merci

Eh bien ça, justement, c'est à toi de le définir. Et de proche en proche, tu t'aperçois que tu vas être obligé, au bout d'un moment, d'écrire un mini-noyau.

Mais concrètement, si tu fais un système bootable depuis zéro, considère que toute la mémoire t'appartient. Tu n'as pas spécialement besoin de l'allouer auprès d'une entité déjà en place, donc tu peux installer ton programme là où il te plaît, pourvu que ce soit bien en RAM car en zone basse, sur un PC, les différents segments sont alloués à des tâches précises, à commencer par le tout premier kilo-octet (256 × 4 octets), réservé à la table des vecteurs des interruptions.

Le plus simple, dans un premier temps, consiste à écrire un bootloader capable de charger un fichier d'un seul bloc en mémoire et à sauter vers une adresse donnée. Ensuite, tu écris tout ton programme en C, même en utilisant la compilation séparée (donc plusieurs fichiers *.c), l'essentiel est de faire en sorte que ton compilateur te produise un seul fichier final, comme lorsque tu produis un exécutable ordinaire. Ici, il faudra en faire un fichier objet.

Tu choisis ensuite une fonction servant de point d'entrée (main() ou autre) que tu auras déclaré de type « void fn(void) » et tu retrouves la position de cette fonction par rapport au début de la section qui contient le code. Tu ajoutes ce même offset à l'adresse mémoire où tu auras choisi d'implanter ton fichier et tu l'appelles. Le compilateur aura fait le reste.

Naturellement, en seize bits, il faudra faire attention à différentes petites choses. Tant que tu seras en dessous de 64 kilo-octets, tu pourras considérer que le début de la section de code commence à zéro et que tu peux implanter ton image en segmentdetonchoix:0000. Les sauts seront locaux et relatifs, donc ils ne poseront pas de problème. Au delà, tu devras gérer des FAR CALLs et donc soit instruire le compilateur sur l'adresse où devra être implémenté le code produit (l'équivalent de ORG en assembleur) — si cela est possible — soit utiliser le linker pour faire cette tâche avant d'extraire ton image finale.

[chrtophe]

Si tu prends ton exemple "Hello World", tu utilises probablement la fonction printf, qui elle-même va utiliser des fonctions de l'OS. Si je prends l'exemple d'un programme DOS en 16 bits, j'utiliserais des fonctions BIOS de l'interruption int 0x10. Si tu ne veux pas du tout utiliser le BIOS, pour afficher quelque chose, il te faut savoir t'adresser à l’électronique de la carte vidéo. Cela revient en gros à te créer un OS.

Regardes ici, le famueux PepinOS:
http://a.michelizza.free.fr/pmwiki.php?n=TutoOS.TutoOS

[_C_Newbie]

Merci Kannagi, Obsidian et chrtophe pour vos réponses.
J'ai appris que le compilateur gcc produits des fichiers ELF en 32bits mode protégé.
Ce que je veux c'est du raw binary (pas de header ELF) en 16 bit mode réel pour le 8088 exactement. Est-ce que c'est possible avec GCC? Quel version? Quels parametres de compilation?
j'ai pas besoin de gros fichiers, c'est juste pour apprendre donc pas besoin de far call.
J'ai appris aussi qu'il faut un fichier en ASM pour préparer le terrain pour le programme en C! par exemple initialiser le stack pointer puis faire un call au point _main du programme en C, et peut être initialiser les variables aussi (section .bss)?
comment configurer le linker pour lier les deux fichiers (asm et C) ensemble? Je crois que le linker a besoin d'un point d'entree _start.
Est-ce que je peux definir l'adresse où mon programme C sera chargé en RAM?
Enfin, écrire un bootloader pour charger un programme en mémoire ça je sais le faire (en asm).

[Kannagi]

Ce que je veux c'est du raw binary (pas de header ELF) en 16 bit mode réel pour le 8088 exactement. Est-ce que c'est possible avec GCC? Quel version? Quels parametres de compilation?
comment configurer le linker pour lier les deux fichiers (asm et C) ensemble? Je crois que le linker a besoin d'un point d'entree _start.

Non c'est impossible
On avait compris ce que tu voulais , mais toi t'as pas compris que je on te donnerai pas la solution toute faite.
Bref sérieusement t'as fait des recherches au moins , t'as cliquer sur le lien de chrtophe au moins ?
Tu veux faire un OS mais tu sais pas faire des recherches normal quoi...

[chrtophe]

Tu trouves les infos dans le lien que je t'ai fourni.

Voici le processus que fait gcc :

• Transformation du code C en assembleur (option visible avec gcc -s) en direction du CPU de destination, gcc est capable de générer du code mulltiplatefomes et mutliprocesseurs, par défaut il prendra l'assembleur de l’architecture sur lequel il tourne
• transformation en fichier objet de ce code assembleur, un fichier objet ELF
• linkage qui va relier tous les .o si tu as plusieurs fichiers source C, lier les avec les bibliothèques utilisées, et rendre ce code réellement exécutable

Si tu avais lu le lien fourni, tu aurais vu les options suivantes :

• --oformat=binary, qui va te générer un fichier binaire
• -Ttext 1000 qui va faire démarrer le code à l'adresse 01x1000

Le point d'entrée d'un code écrit en C est main, c'est d'ailleurs pour ça qu'un code miniumum en C sera :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int main(argc,argv)
{
}

Quand tu compiles un code en c, il est automatiquement linké avec la libc, sauf si tu as passé l'option -nostdlib, et dans ce cas le point d'entrée sera _start.

Autre point important, je ne sais pas comment gcc gère le mode réel et si il le gère. Une simple recherche google à ce sujet et j'ai trouvé que gas, (Gnu ASsembler, l'assembleur par défaut de GCC) ne gère que partiellement le mode 16 bits, ce qui semble aller dans le sens de mes doutes.

Tu auras donc besoin d'un minium d'assembleur pur.

Si tu prends l'exemple du noyau Linux, le code d'amorce est en assembleur et il est linké au code C.

[Obsidian]

Merci Kannagi, Obsidian et chrtophe pour vos réponses.
J'ai appris que le compilateur gcc produits des fichiers ELF en 32bits mode protégé.
Ce que je veux c'est du raw binary (pas de header ELF) en 16 bit mode réel pour le 8088 exactement. Est-ce que c'est possible avec GCC? Quel version? Quels parametres de compilation?

Relis les commentaires, c'est expliqué dedans.

Mais tant qu'à faire, plutôt que s'embêter à gérer les chevauchement en 16 bits, il est plus intéressant d'apprendre à passer en mode protégé en assembleur, puis d'utiliser des segments de la longueur de ton choix.

j'ai pas besoin de gros fichiers, c'est juste pour apprendre donc pas besoin de far call.

Non, mais c'est le compilateur qui va générer tout cela pour toi, donc tu ne t'apercevras pas forcément du moment où tu vas franchir la limite.

J'ai appris aussi qu'il faut un fichier en ASM pour préparer le terrain pour le programme en C! par exemple initialiser le stack pointer

Effectivement, il faudra penser à réserver un peu d'espace pour la pile.

puis faire un call au point _main du programme en C, et peut être initialiser les variables aussi (section .bss)?

Tout cela, c'est vrai lorsque tu travailles en conditions normales sous un système d'exploitation type UNIX. La section .bss ne t'intéresse que si tu utilises des variables globales dont tu peux très bien te passer.

comment configurer le linker pour lier les deux fichiers (asm et C) ensemble? Je crois que le linker a besoin d'un point d'entree _start.

Tu demandes à ton assembleur de produire les mêmes fichiers objets que ton compilateur (du ELF par défaut sur GCC, ou n'importe quoi d'autre), tu lies tes fichiers avec le linker et tu extrais à la fin le code du fichier final.

Regarde du côté de objcopy qui permet de faire cela sans trop de peine.

Est-ce que je peux definir l'adresse où mon programme C sera chargé en RAM?

Non, pas facilement. C'est ce que je t'explique également au-dessus.

À la place, soit tu génères du code explicitement position-independent avec « -fPIC », soit tu le laisses générer du code fait pour débuter au début d'un segment, donc à 0000, même si le point d'entrée se trouve un peu plus loin, et tu charges l'image de ton exécutable au début du segment de ton choix. Donc où tu le souhaites en mémoire, avec une granularité de 16 octets.

[_C_Newbie]

Bref sérieusement t'as fait des recherches au moins , t'as cliquer sur le lien de chrtophe au moins ?
Tu veux faire un OS mais tu sais pas faire des recherches normal quoi...

Il faut pas faire un jugement hâtif !!
Tu es sûr que GCC produit du 16bit mode réel???????
J'ai fait de recherches sur le sujet avant de poster ma question. Apparemment rare sont les compilateurs qui le font (bcc, ack, digitalmars...) mais je sais pas comment faire exactement. Ces compilateurs sont très peu connus.
J'ai dit que le processeur cible est un 8086/8 donc pas de mode protégé.
Bien sûr j'ai visité la page du "Pépin" c'est un OS en 32 bits mode protégé non?
http://a.michelizza.free.fr/pmwiki.php?n=TutoOS.KernelC

[chrtophe]

Tu es sûr que GCC produit du 16bit mode réel???????

Pour moi non, ce sera du 16 bits mode protégé.

dans ton cas, si tu veux absolument du code 8088, regardes du coté des anciens compilateurs C de l'époque :
Borland C qui était payant mais je crois qu'on peut maintenant l'utiliser gratuitement - à vérifier
Visual C ancienne version.

Tu ne pourras pas exécuter ses applications sur les systèmes récents, les applis 16 bits sont incompatibles avec les CPU 64 bits.

Par ailleurs emu8086 n'est qu'un assembleur, même si il comporte un émulateur, tu ne pourras pas aller bien loin. Je te conseilles plutôt Bochs.
Tu peux aussi regarder du coté de dosbox, dans lequel tu pourrais installer une vieille version de compilateur C, te permettant de générer du code 16 bits mode réel depuis une source en C. Et avec DosBox, tu peux avoir un volume logique vu depuis celui-ci correspond à un dossier de ton système hôte.

[_C_Newbie]

Merci chrtophe, oui en effet malhereusement gcc ne produit pas du code exécutable par un 8086.
emu8086 permet la programmation en asm c vrai mais on peut démarrer l'émulateur à partir d'un floppy virtuel. Donc je veux écrire mes programmes en C et les mettre dans ce disque virtuel pour les essayer.
Est-ce que DosBox permet de démarrer sur une image disk?
En tout cas c'est une bonne piste (turboC + dosbox), merci. Reste à savoir est-ce que je peux sauvegarder les programmes générés dans cet environnement pour les utiliser avec emu8086 ou autre émulateur PC-XT.

[chrtophe]

Est-ce que DosBox permet de démarrer sur une image disk?

Non, tu as un "ms-dos", tu pourras installer Turbo C dedans dans un dossier visible et par DosBox et par ton hôte pratique si tu veux modifier les fichiers depuis ton hôte. celui-ci est capable de faire tourner les anciens jeux qui fonctionnaient sous DOS. (gère léemulation CD-ROM, souris, Vidéo, carte son).

Si tu as besoin de booter sur une disquette, Bochs sera adapté. C'est un émulateur complet qui contient même un débuggeur très bien fait. Tu pourras choisir le CPU à émuler.

Tu ne pourras par contre pas facilement transférer des données de ton hôte vers ta machine simulée. Tu pourras via le biais d"une image de disquette par exemple.

[_C_Newbie]

J'ai installé dosbox et commencé à jouer avec turboc!
Je vais voir comment générer un code indépendant de tout OS pour créer une image disk avec et ensuite le lancer dans un émulateur.
Apparemment TurboC marche sans probleme sous XP donc pas besoin de dosbox.

[_C_Newbie]

TURBO C (V2.01 que j'utilise) ne génère que des fichiers EXE (MZ), même pas des COM malgré le choix de tiny model !
EXE2BIN ne réussit pas à convertir ces EXE.
Est-ce qu'il y a un moyen de convertir un fichier exe manuellement?
On a besoin de "rellocation"?

[chrtophe]

De mémoire, c'est comme ça qu'on fait. Ton .exe dépasserait pas 64K par hasard ? le .com de ce que je me rappelle doit tenir dans 64K.

[_C_Newbie]

Non le code ne dépasse pas les 64k. C'est un simple hello world !!

Exemple:
ce bout de code compilé par turbo c donne un fichier exe de 5,85 k !!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
main(){ 
asm nop
asm mov ax, 0
asm inc ax
return 0;}

le même code compilé par FASM donne un ficher de 5 octets:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
use16
org 0
 
nop
mov ax, 0
inc ax

Mon problème est commet extraire les 5 octets des 5850 ?

[_C_Newbie]

Bon c'est presque résolu.
Avec turbo C il suffit de compiler en choisissant le modele tiny puis linker à la main afin d'empêcher le compilateur d'ajouter son propre startup file c0t.obj (ce qui explique en partie le gros volume généré dont on a parlé avant):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
     tcc -mt -c myprog.c
     tlink  /s myprog

l'option /s permet de générer un fichier MAP détaillé dont on en a besoin pour savoir l'emplacement des différents segments.
Enfin, exe2bin'er le fichier exe qu'on a obtenu:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
   exe2bin myprog.exe myprog.bin

Le premier problème, le code généré commence toujours à l'offset zero. Il reste comment choisir un autre offset? Peut être par le biais d'un fichier startup ? Je sais pas !

Autre problème:
En principe dans le modèle tiny CS=DS, mais j'ai trouvés que les variables (section data) sont dans un segment différent. Il faut donc, en run time, charger DS avec la valeur récupérée à partir du fichier MAP !! Comment ?

IMPORTANT:
Pour les curieux, on peut générer un fichier ASM à partir du fichier C avec la commande:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
     tcc -S myprog.c

Attention -S en majuscule.

On peut aussi étudier le fichier "myprog.bin" dans IDA Free. C'est trèèèèss fooooooort !!!
TIPS:
- si l'opcode n'apparait pas (à gauche des instructions asm) aller dans le menu options --> text representation et mettre 5 dans la case "number of opcode bytes"
- vous pouvez enregistrer le resultat dans un fichier lst : menu file --> produce output file --> produce LST file
LST contient toutes les informations sur l'écran mais "produce ASM file" n'enregistre que l'asm.

[Invité]

Je pense que sur la rubrique assembleur du site, se trouvent pas mal des tutorials et des codes source
qui vont vous aider .. croyez moi

Tu peux commencer par ces deux exemples:

• http://asm.developpez.com/telecharge...iche-l-horloge
  
• http://asm.developpez.com/telecharge...327/linux-0-00