Mode kernel, spécifiquement pour PedroM, et en C - Page 1

yop PpHd,

Tu pourrais faire un petit topo des headers à utiliser pour programmer en C ?
ped-base.h devrait suffire je suppose ? A moins qu'il ne faille utiliser pedrom-base-before ? Je sais pas trop... En plus TIGCC m'emmerde parce qu'il me dit qu'il ne voit pas de __main... J'ai bien activé la compilation en mode kernel, et enlevé le link à tigcclink.

Merci de m'aider. Je comprends pas forcément tout ce qui se passa dans les headers C, pas autant que dans les headers asm du moins ^^

Ca marche comme çà:

#include "stdio.h"

int main (int argc, const char *argv[])
{
 printf ("Hello world\n!");
 for (int i = 0 ; i < argc; i++)
   printf ("ARGV[%d]=%s\n", i, argv[i]);
 return 0;
}

Bref du C tel que tu le vois dans n'importe quel bouquin normal
Pas besoin de -DUSE_KERNEL ou autre conneries du genre.

Ah ben OK ! Donc j'invoque tigcc en ligne de commande ? Parce que si je ne mets pas -DUSE_KERNEL, il va exporter NOSTUB par défaut, non ?
Ah et puis j'ai vu que main est de type int, ça c'est beau
Les constantes de sorties (donc d'erreur) de PedroM sont documentées quelque part ? Ou alors ce sont des erreurs standard, et je trouverai ici ou là ?

(puis ton exemple marche pas pour PedroM 0.80 )

J’imagine que dans le stdio.h PpHd a mis les #define qui vont bien pour que ld-tigcc génère le format qui va bien.
Mais peut-être que l’IDE écrase certaines directives dans sa bidouille pour compiler un projet entier ?

• Folco se précipite pour essayer de voir comment stdio.h se démerde.


Au fait, faut linker avec tigcclib.a ?

Ben il doit faire un #define USE_KERNEL, à tout casser…

Tu as regardé alors ?

Bingo

#define USE_KERNEL

(de ped-base.h, ligne 36)
Enfin, il y a *quelques* autres trucs…

Oui, j'ai regardé. Il y a plein de définitions que je ne comprends pas (pas mal de __HAVE_* en fait).
Ya que __HAVE_CONSOLE que j'ai compris. (le flag 2 quoi) Ca veut dire que par édfaut, l'écran n'est pas redessiné ?

Et sinon, le fait de lire le header, et les autres ped*.h ne m'a pas apporté beaucoup de réponses, je comprends mal le fontionnement de la toolchain.


euh, à mon sens, on doit pouvoir linker avec tigcclib.a, mais faut pas inclure tigcclib.h je crois ?

#ifdef DOORS
#ifndef __PEDROM__BASE__
#error Please, do not use tigcc std headers if you want to create a PedroM program.
#endif
#endif

A moins que __PEDROM_BASE__ soit exporté quand on choisis "support unofficial OS" ?

Et je comprends pas, mais vraiment pas, pourquoi on undef des symboles pour les redéfinir 3 lignes après :

#undef	NO_AMS_CHECK				/* Useless for PedroM */
#undef	NO_CALC_DETECT				/* Useless for Kernel mode */
#undef	EXECUTE_IN_GHOST_SPACE			/* Useless for PedroM */
#undef	USE_KERNEL
#undef  MIN_AMS

#undef	USE_FLINE_EMULATOR			/* Useless for Pedrom? */
#undef	USE_INTERNAL_FLINE_EMULATOR		/* Useless for PedroM */
#undef	RETURN_VALUE				/* Return value are not comaptible */

#define	NO_AMS_CHECK
#define	NO_CALC_DETECT
#define	USE_KERNEL
#define MIN_AMS 101
#define _NO_INCLUDE_PATCH
#define DOORS

^10

(et je voulais mettre ça dans SOS T3 OS en fait )

Par contre une fois que je vais y arriver, ça va être jouissif de coder avec tout ça

et puis j'arrive pas à compiler un main() vide, je me tape des erreurs dans tous les sens...

Ah ! J'arrive à compiler, ça y est ! Un programme vide fait bien ses 87 octets de programme qui fait rien.
On va pouvoir attaquer la suite

Folco (./9) :

Ya que __HAVE_CONSOLE que j'ai compris. (le flag 2 quoi) Ca veut dire que par édfaut, l'écran n'est pas redessiné ?

Ca veut dire que si on utilise stdio pour afficher sur la console, l'écran n'est pas redessiné à la sortie de ton programme !

Folco (./9) :
euh, à mon sens, on doit pouvoir linker avec tigcclib.a, mais faut pas inclure tigcclib.h je crois ?

On peut.

Folco (./9) :
Et je comprends pas, mais vraiment pas, pourquoi on undef des symboles pour les redéfinir 3 lignes après :

Pour avoir les définitions que je veux et pas celles par défaut.

PpHd (./12) :
Ca veut dire que si on utilise stdio pour afficher sur la console, l'écran n'est pas redessiné à la sortie de ton programme !

Bien !

Mais si main est de la forme "int main(void)", on va forcément avoir un retour ? Donc forcément en console?

PpHd (./12) :
On peut.

Ok. Vaut mieux faire les définitions de romcalls à la main pour ceux qui sont pas définis ? yen a déjà plein de string.h par exemple.

#ifndef __jmp_Tbl
# define __jmp_Tbl __jmp_tbl
#endif

C'est normal l'espace entre le # et define dans pedrom.h ?

c'est surtout inimportant

Ah.... 'scusez #tridehors#

non c'est à savoir en fait, les espaces entre # et define sont pas comptés, ça permet d'indenter "proprement"

//illisible
#ifdef truc
#define machin
#ifdef truc_bidule
#define machin_bidule(a) (int)((int)a+1)
#endif
#endif

//lisible 1
#ifdef truc
  #define machin
  #ifdef truc_bidule
    #define machin_bidule(a) (int)((int)a+1)
  #endif
#endif

//lisible 2
#ifdef truc
#  define machin
#  ifdef truc_bidule
#    define machin_bidule(a) (int)((int)a+1)
#  endif
#endif

au choix

Au fait, pour compiler, je fait tout simplement ça :
tigcc -Os -Wall -W -Wwrite-strings -ffunction-sections -fdata-sections machin.c

Pourquoi, si je compile avec l'IDE, il me dit que j'ai pas de section main et que le global import __kernel_program_header est pas résoudru ?
A cause de tigcclib je suppose ?

Parce que l'IDE c'est mal ?

Oui, nan mais justement, que fait-elle pour provoquer ça ? Je pensais qu'elle exécutait bêtement la ligne de script que j'utilise en ligne de commande ^^ (en tout cas, sont trop bien foutus tes headers )

Je ne sais pas. Je n'ai JAMAIS utilisé l'IDE de ma vie.

Cette virginité t'honore, ô grand PpHd

special tribute to Godzil ^^

Au fait, je veux utiliser kernel.h de Preos (.sdk/include/c/kernel.h), pour avoir les ramcalls.

Seulement, il va me chercher un kernel.h de tigcc, alors que j'ai écrit dans le source :
#include "kernel.h"
Je croyais qu'avec les guillemets, ça allait chercher dans le répertoire courant, non ?

Et c'est bien comme ça qu'il faut s'y prendre pour avoir les ramcalls ?

Heu, je crois.
Sinon extrait les définitions des ramcalls de kernel.h

./22 si tu utilises tigcc, quand tu utilises #include "fichier.h" ça permet d’inclure les fichiers qui sont dans l’espèce de dossier « header files » de l’ide, mais pas forcément dans le dossier physique où est stocké le fichier .c qui réalise l’inclusion.

C'est n'imp ce comportement, c'est hyper standard

Le moyen le plus simple : renommer le kernel.h en preos.h.

j'ai déja gueulé sur ça, mais c'est un feature parait il

Martial, essaie d'utiliser le kernel.h que j'ai commencé à merger pour GCC4TI
Il est censé être équivalent (ou alors, c'est un bug qu'il faut corriger ), et surtout, tu auras accès automatiquement à la dernière version des définitions contenues dans les autres headers.

Ok Lionel, l'es rendu où ce header ? Celui-ci ? http://trac.godzil.net/gcc4ti/browser/branches/include/C/kernel.h
Je comprends mal toutes les subdivisions quand je parcours les sources. Quelles différences entre trunk et branches ? Trunk c'est l'original et branch le fork ?

-> Ok, ça a l'air d'être le bon, mais je fais comment pour l'enregistrer ? Au format HTML c'est pas terrible, et un copier/coller copie également les numéros de ligne ...

Tout en bas de la page, il y a des liens directs de téléchargement
(c'est bête que Trac ne les propose qu'en bas, je trouve...)

Le ticket correspondant est http://trac.godzil.net/gcc4ti/ticket/9

J'avais déjà relu le fil du ticket, et merci pour le lien. Je l'ai cherché, pas trouvé ...