PpHd a écrit :
1. Si vous avez pas le niveau pour faire un linkeur en mode kernel, je n'y peux rien pour vous. (J'aime etre mechant parfois 
)
2. Ca sera compatible avec les precedent kernels.
Ah, OK. Tu utiliseras tout simplement les DLLs kernel? Je pense qu'on pourra faire la même chose en
_nostub avec un peu de "startup code" rajouté par le linker (
LoadDLL + code de relogement). Maintenant qu'on a un vrai linker qui sait ou s'arrêtent les fichiers
.o (pas
Obj2Ti qui recevait tout en prélinké), ça devrait être faisable.
3. Faire des PC relatifs entre fichier .o est une pure aberation car le compilateur ne peut pas savoir la taille du saut au moment de lacompilation, ne serait ce que pour faire les programmes de 64K.
Je déconseille moi aussi les PC-relatifs entre fichiers
.o, mais ça existe. Et si les objets sont l'un à côté de l'autre dans la ligne de commande de linking, c'est censé marcher. Mais bon, tu as raison, ce n'est censé marcher que si et seulement si le programme fait moins de 64 KO.
4. C'est ce qu'on appelle simplifier la vie du programmeur, quelque chose que vous ne connaissez pas car vous aimez lui compliquer la vie.(J'aime etre mechant parfois (2) )
Alors:
- pourquoi Zeljko Juric a-t'il rajouté des fonctions de
stdio.h alors que
vat.h est plus rapide et prend moins de place?
- pourquoi Thomas Nussbaumer a-t'il intégré le double-buffering à ses routines de niveaux de gris, et d'une manière plus facile à utiliser que
genlib (chez toi, il faut échanger les 2
DSCREENs à la main, chez nous, il suffit d'appeler
GrayDBufToggleSync)?
- pourquoi ai-je codé
*scanf alors qu'on peut très faire sans?
- pourquoi Sebastian a-t'il patché
GCC pour permettre les variables globales non-initialisées en mode
_nostub?
- pourquoi Sebastian a-t'il patché
GCC pour permettre les nombre binaires en
0b...?
- pourquoi Pollux et moi avons-nous patché
A68k pour rendre optionnel le
END à la fin (merci d'ailleurs à Pollux pour ses contributions à
A68k)?
- pourquoi ai-je patché
GCC 3.1 pour générer du code plus efficace avec des trucs comme
&(SCR_RECT){{0,0,239,127}} (le même code que ce que donnait
GCC 3.0 - ils ont changé ça pour être plus conformes au standard C99; si c'est ce que vous voulez, passez
-fno-global-compound-literals à
TIGCC).
...
Et ben, tout ça a été fait pour faciliter la vie du programmeur. C'est l'un des objectifs les plus importants de
TIGCC que de faciliter la vie du programmeur.
>et parce que ça ne marche qu'en mode kernel
Pourquoi alors s'emmerder a rajouter le support du mode kernel ?
Pour la compatibilité avec les vieux programmes. Je suis contre l'ajout de nouvelles fonctionnalités kernel-only, et il me semble bien que Sebastian et surtout Zeljko pensent comme moi.
Je ne trouve vraiment pas une bonne idée que de continuer de rajouter des trucs à ce format dépassé. Corriger des bogues dans
PreOs et améliorer le support pour le format existant, d'accord, mais arrête de rajouter des trucs.
