Kernel moteur de gestion des Listes, Matrix pour exécuter des fonctions - Page 2

Pour les libraries statiques, il est effectivement techniquement possible de les distribuer sans les sources, mais je vous avertis quand-même que TIGCC garantit seulement la compatibilité sources d'une release à une autre, donc une librairie statique pourrait ne plus marcher avec un nouveau TIGCC sans recompilation. Ça s'est déjà passé plusieurs fois, parfois à cause de changements matériels ou logiciels du côté de TI (V200, Titanium, AMS 2 et 3, mais c'est clair que c'est peu probable de nos jours), parfois parce que TIGCCLIB a été rendue plus efficace (passage par registres, par exemple, et là je n'exclus pas qu'un nouveau changement pourrait se produire).

Je viens de me rappeler que K. K. avait écrit un Wrapper qui offre à un programme d'hérité du comportement suivant :
- installe votre programme en Flash APPS temporaire => le programme reste chargé en mémoire
- rend disponible à du Ti_Basic des fonctions du programme C

Je vais donc proposer une version de mon Wrapper en utilisant ce Flash_APPS_Wrapper histoire de gagner sur le temps de relogement de la librairie en RAM.
Ça va grossir un peu la librairie Ti-Basic, mais il y aura certainement un gain en vitesse.


Question hors sujet : quel est le soft qu'utilise yaronet pour les posts du Forum ?

Kevin Kofler (./31) :
Pour les libraries statiques, il est effectivement techniquement possible de les distribuer sans les sources, mais je vous avertis quand-même que TIGCC garantit seulement la compatibilité sources d'une release à une autre, donc une librairie statique pourrait ne plus marcher avec un nouveau TIGCC sans recompilation. Ça s'est déjà passé plusieurs fois, parfois à cause de changements matériels ou logiciels du côté de TI (V200, Titanium, AMS 2 et 3, mais c'est clair que c'est peu probable de nos jours), parfois parce que TIGCCLIB a été rendue plus efficace (passage par registres, par exemple, et là je n'exclus pas qu'un nouveau changement pourrait se produire).

andoh_wilfried (./32) :
Question hors sujet : quel est le soft qu'utilise yaronet pour les posts du Forum ?

Comment ça ?

Oui, pas compris non plus le rapport avec le 68k sur ce coup-là.

je me code un petit framework PHP pour mon construire des site web, et il me faut un editeur.

L'editeur de Posts de Yaronet, celui dans lequel on écrit les messages,
c'est un soft fait maison ou un logiciel libre ou payant ?

Où peut-on l'avoir ?

C'est tout fait maison et yAro ne compte apparemment pas le publier.

heu l'éditeur de posts de yAronet c'est un textarea et 4 boutons à coté, au pire ça devrait pas être insurmontable à reproduire (plus précisément si tu bloques là-dessus, je ne suis pas sûr que tu arrives au bout de ton projet)

j'en voulais un tout fait, mais bon ça me dérange pas de recoder ça.
En fait j'ai quasi finit la parti Php site entiere modulable à partir d'une DataBase, je peaufine les outils.

Sinon revenons au sujet.

J'ai eu une idée que je voudrais dvlper mais je voudrais etre sure que ce soit faisable :

Créer un système de DLL (par encapsulant de fonction C/ASM dans un format perso)


Voici les questions que je me pose ?

- peut-on exécuter directement le code d'un programme C en pointant directement dans le programme ?
- si oui, où doit-on pointer ? (peut-être à la fin du fichier  comme cela se fait habituellement)
- quel fonction de TIGCC utilise-t-on pour cela ?

Voici comment je vois le système de DLL :

- une DLL est une fonction C/ASM encapsulée dans un format perso
- la librairie charge les DLL du répertoire des DLL et les vérouilles
- une table [nom_DLL, ptr_DLL] est crée pour un accès rapide au DLL
- la librairie propose 2 modes d'appels : run_DLL et run_PROG
- la librairie lorsqu'elle appelle une DLL, dépose au sommet de la pile l'address de la structure ARGUMENTS *ptr_ARG qui est bien sur verrouillée
- la DLL doit est compilé avec la structure ARGUMENTS  et déclare une variable ARGUMENTS  *ptr_ARG tel que  
    argptr = top_estack;  prt_ARG = (ARGUMENTS   *)GetIntArg(argptr );
- la DLL efface l'addresse du pointeur sur ARGUMENTS en faisant top_estack = argptr;
- la DLL s'exécute en utilisant les ptr_ARG pour acceder aux arguments et  peut retourner son résultat sur la pile

Qu'en pensez-vous ?

- peut-on exécuter directement le code d'un programme C en pointant directement dans le programme ?

Oui en kernel, non en nostub.

- si oui, où doit-on pointer ?

C'est le kernel qui fait ça tout seul, t'appelles la fonction comme n'importe quelle autre.

(peut-être à la fin du fichier comme cela se fait habituellement)

- quel fonction de TIGCC utilise-t-on pour cela ?

Il n'y en a pas, les DLL nostub n'étant visiblement pas utilisables dans le cas que tu décris.

- la librairie charge les DLL du répertoire des DLL et les vérouilles

Tu vas refaire tout le boulot du kernel.

- une table [nom_DLL, ptr_DLL] est crée pour un accès rapide au DLL

Tu vas refaire tout le boulot du kernel.

Alors faut donc que je me documente sur les Lib Dynamique Nostub, et aussi la prog Kernel alors.

C'est compris alors

La "programmation kernel" n'a rien de très spécifique : tu écris différentes fonctions dans ta lib (GetListPtr, GetListElement ou que sais-je encore).
Il suffit à un programme d'écrire ensuite GetListElement( n ) pour exécuter le code de ta lib qiu lui renverra ce qu'il faut. De ton côté, tu n'a rien de spécifique à faire.

Note que je ne dis pas ça dans le sens "Fais du kernel !", mais parce que j'ai fini par comprendre que ce type de programmation n'est jamais choisi par ignorance de ce que permet le kernel plus que par choix réfléchi.

Je suis en train de pencher pour cette option en effet.

Je veux créer des genres de DLL que la librairie chargera dynamiquement et pourra exécuter.

Mais bon je penche plus pour faire une librairie dynamique Nostub; pas question de rendre ce progamme dépendant d'un autre.

Tu ne peux charger qu'une seule "DLL" à la fois en nostub.

Tu as deux solutions pour aborder le problème :
- ou tu te penches sur les moyens techniques dont tu disposes ("DLL" nostub, kernel), puis tu fais un choix éclairé.
- ou tu te donnes un concept à réaliser, puis tu tords les moyens existants jusqu'à ce qu'ils fassent peut-être ce que tu veux.

Perso, je prendrais la première. Indice : demande-toi pourquoi il existe des dll kernel, mais aucune "DLL nostub" dans le sens de ce que tu veux faire.

Et faut arrêter de fantasmer sur les quelques ko que prend un kernel en RAM devant ce dont dispose la calc, c'est de la branlette intellectuelle. ko que d'ailleurs tu reperdras en codant dans ta "DLL" ce que contient le kernel. Qui plus est, beaucoup ont un kernel, ne serait-ce que pour les jeux ou les viewers de texte.

Peut-être qu’il a aussi envie de s’amuser à coder lui-même le travail de relogement et de liaison…

Et de déprotection de l'exécution. C'est évident qu'il peut avoir envie de s'y amuser, mais les envies qu'il a exprimées jusqu'à maintenant sont tout autres.

Folco (./43) :
Et faut arrêter de fantasmer sur les quelques ko que prend un kernel en RAM devant ce dont dispose la calc, c'est de la branlette intellectuelle.

Surtout qu'au final tu as plus de mémoire accessble dans ton programme en kernel, qu'en native classique
Et j'ajouterai que faire ce que tu as décrit est immédiat dans ce format, mais est très dur dans l'autre, et que tu ne pourrais JAMAIS faire que ton programme soit indépendant d'un autre programme.

andoh_wilfried (./35) :

je me code un petit framework PHP pour mon construire des site web, et il me faut un editeur.

Il en existe de tout fait, à intégrer directement. Un qui a le vent en poupe en ce moment est TinyMCE (http://tinymce.moxiecode.com/) mais il y en a bien d'autres (FCKeditor, Kupu...)

Ces 3 jours, grace à une petite grippe j'ai eu le temps de faire joujou avec ma 92+.

Ca a donnée ceci comme démo de StackLib : Post .0

Vous pouvez tester la gestion des paramètres passés à une fonction grace à la démo.

C'est stable d'après mes test, mais tenez moi au courant si vous voyez des bugs.


Je pourrai enfin me pencher sur la librairie statique et le wrapper Ti-basic.