Compilation en mode KERNEL - Page 3

Kevin> Si on n'utilise aucune des fonctions du kernel, OK pour le nostub ...

Mais c'est presque une erreur de n'utiliser aucune des fonctions du kernel ...
Que ce soit:
* les libs pour le graphisme (en dynamique, ce qui gagne de la place a partir du moment au tout le monde possede la lib - ce qui est le cas de graphlib/gray4lib et presque de genlib)
* les libs perso en cas de prog trop gros (ou pour rendre des fonctions precises accessibles a tout le monde: soundlib, genlib, api92, ...)
* les RAM_CALLs
* les ROM_CALLs plus rapide (bon d'accord, pas beaucoup, mais plus petits)
* la sauvegarde automatique de l'ecran (hum, mauvais exemple, c'est pas sur que ce soit une bonne idée, ca)
* les BSS
* ...

Je pense que la plupart des programmes peuvent tirer un avantage (meme minime) des kernels. Et le fait de dire que tout le monde n'as pas de kernel est une fausse excuse ... si un prog est interressant, il peut se permettre de demander d'installer 2 ou 3 trucs (et si certaines presonnes n'en sont pas capables, tant pis pour elles)

>Dark Angel:

>* les libs pour le graphisme (en dynamique, ce qui gagne de la place a partir du moment au tout le monde possede la lib - ce qui est le cas de graphlib/gray4lib et presque de genlib)

"tous ceux qui ont Universal OS" != "tout le monde"

>* les libs perso en cas de prog trop gros

On peut s'en sortir autrement, par exemple en utilisant la méthode de la FAT Engine (qui est trop grosse pour être une librairie statique à cause de la limite des 64 KO).

>(ou pour rendre des fonctions precises accessibles a tout le monde: soundlib, genlib, api92, ...)

On peut faire des librairies statiques personnelles (comme ExtGraph) avec les versions les plus récentes de TIGCC (et cela soit en C, soit en assembleur GNU, et peut-être dans pas trop longtemps aussi en assembleur A68k).

>* les RAM_CALLs

La plupart du temps, ils sont utilisés pour des routines sales (lecture directe de la table des handles ou de la VAT par exemple).
Et ils peuvent tous être obtenus autrement (sinon, comment ferait le kernel?).

>* les ROM_CALLs plus rapide (bon d'accord, pas beaucoup, mais plus petits)

Plus petits? En _nostub et avec OPTIMIZE_ROM_CALLS, c'est 6 octets par ROM_CALL. En mode kernel, c'est 8 octets (6 pour le saut absolu et 2 pour l'entrée dans la table des relogements) par ROM_CALL.

>* la sauvegarde automatique de l'ecran (hum, mauvais exemple, c'est pas sur que ce soit une bonne idée, ca)

En effet. Et puis, c'est facile à faire à la main (15 lignes en assembleur).

>* les BSS

C'est inutile. Il y a des fonctions pour allouer de la mémoire proprement (Heap*). C'est ce que fait "derrière les coulisses" le kernel pour les BSS, et là encore, il y a des tonnes de relogements inutiles à faire par rapport aux fonctions Heap*.

>* ...

?
Je crois que tu as déjà donné toutes les fonctions du kernel.

>Et le fait de dire que tout le monde n'as pas de kernel est une fausse excuse ... si un prog est interressant, il peut se permettre de demander d'installer 2 ou 3 trucs (et si certaines presonnes n'en sont pas capables, tant pis pour elles)

1. Un kernel sur HW2 AMS 2 nécessite de patcher AMS. (Je te rappelle que la méthode du HW2Patch qui ne modifie pas AMS plante dès que l'on essaye de changer les piles.)
2. Un kernel récent (c'est-à-dire une version récente de Universal OS) nécessite 12 KO. Les librairies "personnelles" comme genlib (que tu cites comme un des avantages des kernels) prennent encore plus de mémoire. Et puis, pour les librairies dynamiques, il faut installer à chaque fois la librairie entière, même si un programme n'en utilise qu'une fonction! Avec les librairies statiques, seules les fonctions réellement utilisées seront installées.


Et puis, je te rappelle qu'il n'est pas question ici d'un programme qui utilise les fonctions des kernels, mais d'un programme qui ne les utilise pas!
[edit]Edité par Kevin Kofler le 12-07-2001 à 21:25:14[/edit]

>>* les libs pour le graphisme (en dynamique, ce qui gagne de la place a partir du moment au tout le monde possede la lib - ce qui est le cas de graphlib/gray4lib et presque de genlib)
>"tous ceux qui ont Universal OS" != "tout le monde"
"tous ceux qui ont Universal OS" ~= "tout le monde"
Et meme ceux qui n'ont pas UniOs ont presque tous graphlib (a part les nostubers foux )

>>* les libs perso en cas de prog trop gros
>On peut s'en sortir autrement, par exemple en utilisant la méthode de la FAT Engine (qui est trop grosse pour être une librairie statique à cause de la limite des 64 KO).
Oui, on peu s'en sortir autrement, bien sur, mais c'est plus compliqué (et meme tres compliqué si on veut faire des librairies qui s'appellent les unes les autres).
Et si le FAT Engine poserait probleme avec la limite des 64Ko, c'est bien que les librairies dynamiques ont quand meme des avantages par rapport au librairie statiques, non ?
Et a part par ideologie, je ne voit pas tellement pourquoi ce n'est pas une librairie dynamique en mode kernel (ou peut etre le defi de programmer des libs dynamiques en nostub ? - mais ca reste du domaine de l'ideologie)
Ce que je dis, c'est le kernel a des avantages, pas qu'il est inévitable.

>>(ou pour rendre des fonctions precises accessibles a tout le monde: soundlib, genlib, api92, ...)
>On peut faire des librairies statiques personnelles (comme ExtGraph) avec les versions les plus récentes de TIGCC (et cela soit en C, soit en assembleur GNU, et peut-être dans pas trop longtemps aussi en assembleur A68k).
Oui, bien sur, mais c'est souvent une perte de place (surtout pour des librairies qui font un truc precis , comme soundlib, ou ps2lib , ou presque toutes les fonction sont forcement utilisées - ce qui n'est pas le cas de ExtGraph).
Encore une fois, c'est une possibilitée offerte par le kernel, qu'on est libre d'utiliser ou pas (et qui me semble superieur dans la plupart des cas)

>>* les RAM_CALLs
>La plupart du temps, ils sont utilisés pour des routines sales (lecture directe de la table des handles ou de la VAT par exemple).
Il y a des RAM_CALLs utilies et propres: CALCULATOR, HW_VERSION, LCD_WIDTH, LCD_HEIGHT, LCD_LINE_BYTES, KEY_LEFT,
KEY_RIGHT,
KEY_UP,
KEY_DOWN,
KEY_UPRIGHT,
KEY_DOWNLEFT,
KEY_DIAMOND,
LCD_SIZE,
KEY_SHIFT,
doorsos::font_medium,
, ROM_VERSION
>Et ils peuvent tous être obtenus autrement (sinon, comment ferait le kernel?).
Oui, mais s'ils sont offerts par le kernel, pourquoi s'en priver ?

>>* les ROM_CALLs plus rapide (bon d'accord, pas beaucoup, mais plus petits)
>Plus petits? En _nostub et avec OPTIMIZE_ROM_CALLS, c'est 6 octets par ROM_CALL. En mode kernel, c'est 8 octets (6 pour le saut absolu et 2 pour l'entrée dans la table des relogements) par ROM_CALL.
Et un regitre de condamné.
Au fait, ca fait combien de cycles dans les deux cas ?

>>* les BSS
>C'est inutile. Il y a des fonctions pour allouer de la mémoire proprement (Heap*). C'est ce que fait "derrière les coulisses" le kernel pour les BSS, et là encore, il y a des tonnes de relogements inutiles à faire par rapport aux fonctions Heap*.
Pas inutile. A utiliser avec precaution (en sachant comment c'est géré), mais ca peut faire gagner de la place.

>>* ...
>?
>Je crois que tu as déjà donné toutes les fonctions du kernel.
Oui, c'est fort possible
En fait, non, on a aussi l'anti-crash, la limite des 8Ko, l'utilisation de prog asm dans une expression, la definition d'un point de sortie, et peut-etre d'autres ...

C'est vrai que tout ce que fait le kernel peut etre fait autrement, mais c'est souvent plus simple (et plus efficace) avec le kernel.
Et en partant du principe que tout le monde a un kernel (ce qui est presque vrai), pourquoi se priver de ses avantages ?

doorsos::font_medium n'est pas un RAM call que je qualifierais de propre. (C'est pour l'accès direct aux fontes.)

>Et en partant du principe que tout le monde a un kernel (ce qui est presque vrai), pourquoi se priver de ses avantages ?

Remplace "presque vrai" par "faux". Et donc on ne peut pas partir de ce principe.

Sur ce forum , je pense que plus de 90% des calcs ont un kernel (je lance un sondage en rubrique divers)

Ce forum n'est paut-etre pas representatif de tous les utilisateurs de TI68k, mais l'utilisateur de base, soit il est capable d'installer un kernel, soit il ne m'interresse pas (parceque, de toute facon, il ne sert pas vraiment de sa calculatrice, et qu'en plus, il est un peu bete). Cela n'engage que moi, mais je me fiche de l'utilisateur moyen.

Cependant, il est vrai que si un programme n'utiliserais vraiment aucune fonction des kernel (mais les ROM_CALL peuvent etre considéré comme un avantage des kernel), il est relativement logique qu'il soit en nostub.

dark angel,je suis d'accord avec toi,le type qui sait pas poser un kernel sur sa bécane,il est cave.étant un newbie en C,je ne polurait pas ce topic passionnant avec des questions bete.néanmoins qui serait d'accord de venir sur béziers (34) pour me faire une formation tigcc ?

Moi ce que je trouve le plus exitant dans la prog sur ti, c'est le fait de tout faire soit même. Bref, en se passant des libs. A mon avis, c'est comme ca qu'on progresse. C'est pour ca que je prog en nostub ( le kernel est une lib et est dédié auw libs principalement ). Sinon, je prog sur PC. Après, pour ce qui est de l'utilisation, le nostub et le kernel n'ont pas de gros défaut qui permettent d'en exclure un plus que l'autre. Du moment que je peux faire fonctionner les 2 modes sur ma calc, y'a pas de prob.

Et au passage, y'a personne qui utilise une fonction de genlib. Il en faut au minimum 4 pour lancer genlib avec ce qu'il faut.
Et par ailleurs, si on a fait une surcouche a AMS, c'est que AMS n'a rien fait pour la programmation assembleur. On a la ROM table, un relogement de merde, et c'est tout.
T'appelle ca un systeme ?
Ils ont du y passer 5 minutes !

>[gandalf]:

>moi je dit vive le kernel, en plus t'as po besoin de laucher kand tu veu lancer un prgm depui la ligne de comande

Si c'est ça que tu veux, va voir ASH de Greg Dietsche: http://www.geocities.com/gdietsche/.
Ce TSR permet entre autre d'utiliser 2 lanceurs universels (un pour les programmes compressés avec ExePack et un pour les programmes non compressés) qui seront appelés automatiquement pour tous les programmes en assembleur, même pour ceux compressés avec ExePack.
(La version de h220xTSR qu'il utilise n'est pas à jour, mais comme tu utilises le HW2Patch, h220xTSR ne sera pas installé de toute façon. D'ailleurs, h220xTSR peut aussi être mis à jour séparément.)

>et enfin je trouve le lib statiques completemtnt cones , ca te boufe de la place

Non, les librairies statiques épargnent de la place, car seules les fonctions réellement nécessaires sont recopiées dans le programme, et on n'est donc pas obligés d'installer toute la librairie.

>C chaint si tu veut mettre a jour juste la lib en cas de MAJ du Tios....

Si c'est vraiment nécessaire (ce qui est assez improbable pour tout sauf des mesures anti-protection comme enter_ghost_space ou h220xTSR), on saura au moins quel fichier on doit mettre à jour (le programme qui bogue). Pour les librairies dynamiques, on ne sait jamais si le problème est dans le programme ou dans la librairie, voire dans le kernel, et en plus les librairies ne donnent même pas leurs versions.

Et pour un programmeur, ça prend 2 minutes de recompiler le programme concerné. (Je l'ai déjà fait en tout 9 fois pour h220xTSR: 3 mises à jour dans 3 programmes. D'ailleurs, normalement, il ne devrait plus rester de bogues dans h220xTSR avec les AMS actuels.)

Kevin tu va provoquer un raz de marée (va voir dans la rubrique "divers")... Tais-toi, sinon on débarque chez toi et on t'enferme dans un hopital de dé-nostubisation
[edit]Edité par Thibaut le 13-07-2001 à 16:24:42[/edit]

Kevin tais-toi notre vie est en danger ! Je BOUUUUUUUUEEE

>[Pollux]: cout<<"Hello world!" avec MFC linké dynamiquement : 20 ko; avec MFC linké statiquement avec "juste ce dont on a besoin" : 110 ko - sans commentaire

1. Oublie MFC et fais #define WIN32_LEAN_AND_MEAN (pas besoin de MFC pour un Hello World).

2. Si VC++ linke du code inutile (100% de MFC est inutile pour "Hello World"), c'est que son linkeur statique ou la librairie statique de MFC (et non pas le principe) est inefficace.

3. Extrait de la documentation de TIGCCLIB:

Q: I learn C++ in a school so it will be good if I can program my TI-89 in C++ (not in ordinary C). Do you plan to implement C++ on TI-89?
A: No. Although C++ is more powerful language than C, it is not a language which is good for TI calculators. It is not efficient enough to be good for a calculator. The code generated by C++ is less efficient than code generated by ordinary C, and it is too bloated. So, even if somebody made C++ compiler for TI, I don't recommend using any C++ extensions (like classes, and especially streaming), except if you like programs like
cout << "Hello world";
which produces 5 Kb long code...

Le C++ est inefficace (surtout cout; considère l'utilisation de printf comme dans le bon vieux C).
[edit]Edité par Kevin Kofler le 13-07-2001 à 17:12:05[/edit]

Thibaut-> bon, ben ça tombe bien, je v à la montagne en fin de semaine

Ben pour te faire chier j'emmène Kevin avec moi, on te suit.
Tu pourras toujours skier avec un skate board

lol

Erf moi j'ai une 89 & 92plus sans Kernel...

Franchement de nos jours de moins en moins de monde on un kernel...

Pour txtrider... je suis justement en train de faire un viewer Nostub.. qui pourra enfin propose un bon viewer sans avoir a installe de kernel.

JS

mhm j'aime quand tu me dits ca

La sauvegarde l'écran n'est pas obligatoire dans le mode kernel !!

20 et 100 ko ?? Faut pas exagérer : 3 et 35 ko. (testé avec VC++ 5.0)

>JM: La sauvegarde l'écran n'est pas obligatoire dans le mode kernel !!

Bon, avec les version inofficielles les plus récentes de Universal OS, en effet, elle n'est plus obligatoire. (Je suis au courant.)

Mais avec la dernière version officielle que tu as sorti (1.30), elle était encore obligatoire, et avec les autres kernels, elle l'est encore.
[edit]Edité par Kevin Kofler le 13-07-2001 à 22:52:36[/edit]

on aura quand, nous les futures versions ?

Kevin, arrete de prendre ce que Zlekio comme argent contant.
C'est ton Dieu ?

universalOS ne s'installe pas sur ma 92+, il plante...

Tu n'as peut-être pas configuré au mieux...

Sur ma 92+ ya pas de kernel non plus, faudrait que je patche la rom pour sa et g franchement pas envie de le faire...
Donc je reste avec des prog en C (ou asm) ecrit en nostub !!

Et puis franchement regardez les premier kernel pour TI-68k (Dooros et PlusShell) proviennent tout les 2 du monde des TI-92 !

Et en plus il ne sont plus mis a jour a l'heure actuelle !!! Sa prouve bien que sa va servir de - en - !

sinon
>>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
Et notable en plus la différence !!!

Noublie pas que l'ASM c un languague de programmation qui travaille directement avec le Processeur!! Utiliser un mode "kernel" c patcher un system avec quelque chose de pas forcement tres stable...


>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, ...

Ben heu regarde mieux la doc a ti-gcc alors...
Ya des pseudo constantes qui marchent tres bien en nostub qui permettes de récuperer la version HW les code de touche etc...
Et puis les BSS se n'est que du bricolage...
Mieux vaut utiliser des variables dynamique avec les pointeurs. Sa sa fait gagner de la place dans une app

tu perd de la place, puisque ce sont des pseudos-constantes.

>Sur ma 92+ ya pas de kernel non plus, faudrait que je patche la rom pour sa et g franchement pas envie de le faire...
Non, HW2patch, comme son nom ne l'indique pas, n'est pas obligé de patcher le ROM ...

>Donc je reste avec des prog en C (ou asm) ecrit en nostub !!
Ca, c'est ton probleme, mais tu passe a cote de pas mal de choses ...

>Et puis franchement regardez les premier kernel pour TI-68k (Dooros et PlusShell) proviennent tout les 2 du monde des TI-92 !
A ma connaissance, il n'y a que Fargo sur TI-92 ...
A non, il y a aussi [tie], mais c'est pour etre compatible avec les exe pour doorsos ... donc plus recent.

>Et en plus il ne sont plus mis a jour a l'heure actuelle !!! >Sa prouve bien que sa va servir de - en - !
Ca ne prouve rien du tout.
Et UniOS est mis a jour.

>sinon
>>>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
>Et notable en plus la différence !!!
>Noublie pas que l'ASM c un languague de programmation qui travaille directement avec le Processeur!! Utiliser un mode "kernel" c patcher un system avec quelque chose de pas forcement tres stable...
Que ce soit les Flash Apps ou le mode kernel, le code qu'on execute est toujours de l'ASM ...

>>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, ...
>Ben heu regarde mieux la doc a ti-gcc alors...
>Ya des pseudo constantes qui marchent tres bien en nostub qui permettes de récuperer la version HW les code de touche etc...
Je te raconte pas la place que tu va perdre !
Surtout si tu fait pas gaffe que ce sont des pseudo-constantes !

>Et puis les BSS se n'est que du bricolage...
>Mieux vaut utiliser des variables dynamique avec les pointeurs. Sa sa fait gagner de la place dans une app
Ca depend comment tu l'utilise ...

>Dark Angel: Non, HW2patch, comme son nom ne l'indique pas, n'est pas obligé de patcher le ROM ...

Mais quand on ne patche pas la ROM, dès que l'on change les piles, ça plante.

Et pour les kernels, ils ont été créés spécialement pour les TI-89/92+, mais l'intérêt principal de PlusShell et de DoorsOS était de faciliter le portage des programmes Fargo.

Vous faites comme vous voulez, mais je ne trouve pas que le nostub soit interressant pour developper des grosses app.
Il n'y a aucun arguments de valables.
Et le BSS, c'est du 100% pur dynamique !