Compilation en mode KERNEL - Page 1

Quand je compile en mode kernel, TIGCC me met:

error with _rom_call_26A
un truc dans ce genre

pquoi ?

As-tu la version 0.91 SP1? http://tigcc.ticalc.org

Once more merci Kevin !
Vive le mode kernel, je gagne 200 octets sur mon jeux rain !

je vais passer pour un newbie mais g jamais réussi a compiler un jeu en C en kernel......c pour ça que je prgm en nostub

>Vive le mode kernel, je gagne 200 octets sur mon jeux rain !

Je ne suis pas d'accord.
Si tu n'as pas besoin de librairies, utilise le mode _nostub. Ou au moins compile dans les 2 modes. On s'en fiche des 200 octets si on a besoin d'un kernel de 12 KO pour lancer le programme!

Et puis:

* As-tu utilisé OPTIMIZE_ROM_CALLS pour le mode _nostub? Avec ça, les ROM calls sont plus courts qu'en mode kernel!
Pour ceux qui veulent des chiffres:
- OPTIMIZE_ROM_CALLS: 6 octets par ROM call
- mode kernel: 6 octets + 1 entrée dans la table de relocation (2 octets) = un total de 8 octets par ROM_call
* As-tu utilisé ExePack?


Avec des gens qui n'utilisent le mode kernel que pour "gagner 200 octets" (en réalité perdre 12000), je me demande s'il ne faudrait pas supprimer le support pour le mode kernel dans les prochaines versions de TIGCC.

PS: N'ayez pas peur, l'équipe TIGCC ne le fera jamais!
[edit]Edité par Kevin Kofler le 08-07-2001 à 23:01:26[/edit]

Et les libs????

Ce qui m'énerve le plus, ce n'est pas l'utilisation de librairies, mais l'utilisation du mode kernel pour des programmes qui n'utilisent aucune librairie dynamique.

D'ailleurs, pour les versions futures de TIGCC, il n'y a pas à avoir peur: ce n'est pas moi qui décide.

Là OK, mais le kernel apporte qd même de la stabilité dans le programme, pour les erreurs avec appels aux trap

Tu connais TI-Guard? Quand ce projet de godzil sera fini, il apportera un anti-crash aussi pour les programmes en _nostub.
Entretemps, on peut utiliser TICT Explorer.

Et puis:
* Même le meilleur anti-crash ne sert que rarement parce que la plupart du temps, il y a de la mémoire corrompue par les bogues. Si TI oblige les gens à faire un reset en cas de bogue, il y a une raison!
* Si le programme n'est pas bogué, pas besoin d'anti-crash: avec TI-Chess, j'ai eu une seule fois un plantage, et c'était avec une ancienne version qui ne vérifiait pas si le fichier de sauvegarde était archivé avant d'y écrire. Et pourtant TI-Chess est un programme énorme.
[edit]Edité par Kevin Kofler le 08-07-2001 à 21:14:47[/edit]

>et puis Otheos ne passe pas du côté obscur de la force!

Justement, donc programme en _nostub.

Si on utilise TICT Explorer, on n'a pas besoin de TI-Guard et donc pas de h220xTSR non plus. D'ailleurs, h220xTSR n'est nécessaire que sur les HW2 AMS 2 non patchées, plateforme sur laquelle les kernels ne marchent pas du tout. Si on veut mettre un kernel, on doit mettre le HW2Patch de toute façon et on peut faire de même pour le _nostub.

D'ailleurs, un lanceur universel pour tous les programmes non compressés ne fait que 505 octets, pas 12 KO. Un lanceur ExePack universel ne fait que 1577 octets, pas 12 KO. Même les 2 ensemble ne font que 2082 octets, ce qui est toujours loin des 12 KO de Universal OS.
[edit]Edité par Kevin Kofler le 08-07-2001 à 22:26:42[/edit]

>pas très loin des 3 ko de TeOS...

Oui, mais essaye de lancer un programme compressé avec ExePack avec TeOS tout seul (sans lanceur).

505 << 3021 (taille exacte de TeOS on-calc)

IL ne FAUT PAS supprimer le mode kernel de TIGCC... les libs dynamique en ont besoin !!! (Ziplib, par exemple !)

Personne ne compte le faire de toute façon.

Kevin Kofler>
Je ne connais aucune TI89 sur laquelle il n'y aie pas de kernel (surement pas la tienne), et ceci pour des raisons evidentes (la plupart des bons jeux necessitent un kernel).
Donc les 200 octets gagnées en compilant en mode kernel sont vraiment gagnées !
En utilisant OPTIMIZE_ROM_CALL, ce n'est pas sur qu'on recupere ces 200 octets, car on perd un registre (moins d'optimisations possibles). De plus, d'autres fonctions sont plus facilement accessibles en kernel qu'en nostub: les RAM_CALL (CALCULATOR, HW_VERSION, certains codes de touches, ...), les BSS, ...

heureusement...

>Je ne connais aucune TI89 sur laquelle il n'y aie pas de kernel (surement pas la tienne)

Sur ma TI-92+, il n'y a pas de kernel.

C'est une HW2 AMS 2.04 non patchée (je vais peut-être mettre la 2.05), avec h220xTSR 1.03, AutoClBr et XtraKeys. J'ai TI-Chess et TI-Pang dessus comme jeux en ce moment.

Sur ma TI-89, il y a Universal OS, mais peut-être pas pour longtemps encore, si les programmeurs se décident enfin à programmer en _nostub, le vrai format assembleur des TI-89/92+. Les kernels ont été crées à l'origine surtout pour faciliter le portage des programmes Fargo (TI-92).
[edit]Edité par Kevin Kofler le 08-07-2001 à 23:10:54[/edit]

>lol et DrawStr est la vraie routine d'affichage de texte peut-être?

Oui. Pourquoi réinventer la roue?

>t'as trop

Non, je ne bois pas d'alcool.

>Je ne connais aucune TI89 sur laquelle il n'y aie pas de kernel
Sur mes deux calculatrices il n'y a pas de kernel...

>tu devrais savoir que ce sont les apps qui sont le vrai format assembleur des 89/92+
ben non il y a clairement une différence entre les APPS et les progs ASM

>Les kernels ont été crées à l'origine surtout pour faciliter le portage des programmes Fargo
Tout a fait d'accord, et je trouve regrettable qu'il n'y ai eu aucune amélioration depuis ce temps là

Moi, je trouve regrettable qu'ils sont encore nécessaires pour certains programmes.

>Tu dois pas bcp t'en servir
Ben si, mais moi je fais plutot de la programmation sur mes TI, le seul jeu que j'ai c'est TI-Chess.

Lisez un peu les autres forums. Il y a des centaines de personnes qui n'utilisent que du _nostub.

Bon je vois que le débat est relancé

Pour répondre à DarkAngel, oui je pense que tous les "bons" jeux actuels (tetris, phoenix, etc.) ont besoin d'un kernel (en + qui n'a pas txtrider ?) donc tous ceux qui jouent ONT effectivement un kernel, autant l'utiliser !

Pour répondre à Kevin, OPTIMISE_ROM_CALL fait gagner environ 200 octets, c'est vrai, mais ca divise par 2 la vitesse de mon jeux !
J'utilise pas mal de pointeurs, et si j'ai bien compris, OPTIMISE_ROM_CALL occupe un registre d'addresse (a5) tt le le long de l'exécution, cela peut expliquer pourquoi.

EXEPACK ?
Lanceur = 1.71ko Programme compressé = 3.94ko
Total = 5.65 ko

RUNC ?
Lanceur = 613 octets = 0.6 ko Prog kernel compressé = 4097 octets = 4 ko
Total = 4.6 ko

C'est vrai pour runc il faut un kernel, mais comme tt le monde en a un (voir plus haut pourquoi ), Kernel et Runc me semblent le couple gagnant !

Evidemment on ne parle ni de la possibilité d'appeler des fonctions dans des libraires dynamiques, ni d'utiliser des variables globales non initialisées.

Kevin l'argument de la "masse populaire" en faveur du _nostub ne tient pas

La masse n'a pas tjrs raison, l'histoire l'a montré il me semble (oulà on s'éloigne là )

Pour runc, tu dois aussi compter shrnklib! (C'est pour ça que le lanceur est plus petit!) Et pour ExePack, il y a un lanceur (ttstart) qui peut lancer tous les programmes compressés pour ceux qui trouvent un lanceur par programme du gaspillage.

Sinon, fais au moins 2 versions (une ExePack, une RUNC).

D'ailleurs, le _nostub tourne partout, le mode kernel seulement là où il y a un kernel installé.
[edit]Edité par Kevin Kofler le 09-07-2001 à 00:22:10[/edit]

Ok Kevin 4 versions alors :
Nostub, Kernel, PPG, RUNC

Ca va pas être le bordel

PS : shrklib + pk92lib = 1ko
ttstart (universel) fait aussi 1.7ko chez moi !
[edit]Edité par Otheos le 09-07-2001 à 00:28:19[/edit]

>Pollux:

>si les voitures futures avaient des systèmes pour soulever la voiture qui pesaient 100 kg, est-ce qu'il faudrait critiquer les voitures qui demandent un cric (comme au XXè siècle ) et qui sont plus légères simplement parce que c vieux, qu'il faut tourner une manivelle et sortir de la voiture? ce serait ridicule de faire la promotion des nouveaux systèmes (sauf à cause d'un accord entre constructeurs pour vendre des moteurs plus puissants ).

Oui. Si on peut le faire automatiquement, autant le faire, même si ça revient plus cher (à cause du poids).

>ben c la même chose, là

Ce genre de comparaisons est toujours risqué. Et même si c'était la même chose, je répondrais oui.

>Otheos:

>Ok Kevin 4 versions alors :
>Nostub, Kernel, PPG, RUNC

Oui, s'il te plaît. Mais les 2 versions compressées (PPG ExePack et RUNC) suffiraient probablement.

>Ca va pas être le bordel

Non. Chacun choisira ce qu'il utilise et tout le monde sera content.

L'alternative est de n'utiliser que le mode _nostub. Il marche de la même maniére avec ou sans kernel.