1


demo StackLib 5Ko 8 paramètres

Syntaxe : stacklib(param1, param2, ...)

NB : param peut-être une indirection "#varname"

Exemple1 : stacklib({1,2}, "will", 2x^2)
Exemple2 : stacklib(("folder", "#data/fold_ini")
Exemple2 : stacklib(("folder", {a,b,c,d}, "->",{{0,1}{0,0}}, "|", {0,1})


Lisez le fichier Arguments contenu dans le zip pour connaitre comment simuler des arbres à partir des paramètres en utilisant les tag_spéciaux :
- "->" (STO) : pour repeter en boucle
- "|" pour repeter le dernier paramètre.

J'ai pas testé encore la rapidité mais voici comment je procède : sans allocation dynamique de mémoire(je vais rendre global la structure de 1,5ko que j'utilse) :

1 - Je traverse chaque paramètre(LIST|MAT ou NUM|STR|EXPR) pour référencer le ptr sur debut les pour en connaitre les dimensions
2 - J'exécute la Fonction ensuite en me promenant dans chaque paramètre en fonction des tag Spéciaux


Il y a bien une 2ème méthode(que je compte tester à cause du gain possible en vitesse, mais ça va nécessité de l'allocation dynamique de mémoire) :

- allouer dynamiquement un tableau de pointeur à 2 dimension pour chaque paramètre
- access directe à chaque éléments des LIST|MAT


Y a quelques contraintes à spécifiér à la compilation :

1 - nombre maxi de paramètres = 8
2 - nombre maxi d'éléments dans une structure(LIST|MAT) = 501 index( On verra s'il faut le faire sur l'Estack restante )


Toute bonne volonté pour tester la démo et signaler d'éventuels bugs est bienvenue.





J'écris un moteur de gestion des expressions Ti_Basic (Listes, Matrix) pour exécuter des fonctions qui lui seront passé en paramètre.
Le moteur va faire dans les 5Ko et a un fonctionnement à VERTEL.
En fait c'est le moteur de ExtLiB en version améliorée.

Ca peur servir rapidement à créer une fonction pour le Ti-Basic, si on s'y connait pas trop en Gestion des Liste et Matrix surtout que
ca supporte un système de boucle interne sur les arguments

Ce que je veux faire c'est d'en faire un programme Kernel que d'autres programme C pourraient utiliser.
En gros ce programme se chargerait de récupérer les arguments Ti-Basic et d'appeler la fonction C.

Est possible de réaliser ça, car je présume que le mode Kernel permet de partager les ressource ?

2

Oui, et tu n’es pas obligé de passer par un kernel pour faire ça…
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

3

quelles ressources?

si tu veux que d'autres programmes C profitent de ton truc, fais en une lib, statique ou dynamique, mais pas un programme! en plus ça évitera d'avoir à penser à kernel/pas kernel.

les programmes à la vertel c'est bien pour la prog en basic, mais pas plus.

4

Sasume (./2) :
Oui, et tu n’es pas obligé de passer par un kernel pour faire ça…

Et tu fais ça comment ?
andoh_wilfried (./1) :
Ce que je veux faire c'est d'en faire un programme Kernel que d'autres programme C pourraient utiliser.

5

squalyl (./3) :
si tu veux que d'autres programmes C profitent de ton truc, fais en une lib, statique ou dynamique, mais pas un programme! en plus ça évitera d'avoir à penser à kernel/pas kernel.

Ben faudra montrer comment tu fais une lib statique ou dynamique appelable par un programme basic hein. hehe

Pour être appelable du TI-Basic, faut que ce soit un programme. Et pour être appelable par un autre programme, tu peux très bien en faire un programme. Un programme supporte les exports...

Le kernel permet justement de faire tout ce qu'il demande... Appeler son programme à partir de n'importe quel point d'entrée à partir d'un programme C/asm, appel style vertel par un programme en basic.

Et quelle serait la solution en nostub ?

6

Hm oui pardon, c’est sûr que s’il veut faire une lib dynamique, le plus simple est d’utiliser la couche PreOs.
Mais il peut faire une lib statique.
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

7

Mais les programmes en Basic feront comment ? cheeky

8

En effet s'il veut faire quelque-chose qui soit à la a fois une bibliothèque C et un programme appelable en TI-Basic, il faut un programme/lib kernel.
Après il y a la possibilité de faire une lib statique et un programme séparé.
avatar

9

purée mais vous le faites exprès?

pour les dev C on donne une lib statique.

en kado avec, un programme wrapper qui donne accès à la lib pour le basic.

c'est plus clair, comme ça?

10

Alors est-ce possible que cela prenne la forme suivant :

- mon programme télécharger on calc( sous une forme appropriée )
- quelqu'un code un programme C utilisant un mécanisme( que le mode Kernel supporte je pense) pour appeller le gestionnaire des paramètres de mon programme

Y a-t il une source de programme qui pourrait m'aider, c'est à dire une programme utilisant ce mécanisme ?

NB: j'ai jamais fait du KERNEL, j'ai toujours été nostub.



11

ne choisis pas.

les dévs qui feront du C, utiliseront ta librairie en conjonction avec leur propre programme grâce à gcc4ti ou tigcc. Ca touchera jamais la calc. Voir genlib.

ceux qui veulent dév en basic, tu leurs files un prog nostub appelable comme vertel ou flib, qui utilise ta lib.

12

squalyl (./9) :
purée mais vous le faites exprès?

pour les dev C on donne une lib statique.

en kado avec, un programme wrapper qui donne accès à la lib pour le basic.

c'est plus clair, comme ça?

C'est possible d'utiliser un autre ton ? neutral On est ni des clebs ni des débutants...

Surtout quand ta première solution était fausse, et que ta seconde est pas la seule et unique, loin de là (et, à mon sens, pas la plus simple).
andoh_wilfried (./10) :
Y a-t il une source de programme qui pourrait m'aider, c'est à dire une programme utilisant ce mécanisme ?
NB: j'ai jamais fait du KERNEL, j'ai toujours été nostub.

Cf la doc de PreOS. Avant de choisir, regarde ce que ça propose, pour savoir si ça peut te convenir. De plus, "faire du kernel" signifie juste "appeler des fonctions du kernel", on pourrait comparer ça à "appeler quelques romcalls supplémentaires que t'es pas habitué à utiliser". C'est aussi con que ça.

13

Bon, pas la peine de s'emporter pour si peu, même si effectivement un ton correct aurait été le bienvenu dans le ./9...

Concernant ton programme, je pense qu'il est dommage de faire du mode kernel s'il a vocation à être utilisé par des softs en BASIC (un programme BASIC qui a besoin d'un kernel pour se lancer, ça se justifie pas trop à mon avis). Par ailleurs vu tu que tu vas faire essentiellement des manipulations de la VAT et de fichiers AMS, je ne suis pas sûr que le kernel t'apporte grand chose d'utile.

Ensuite, comme a dit squalyl avant de s'exciter pour rien, la forme qui devrait convenir à un maximum de personnes est :

- Une bibliothèque qui exporte toutes tes fonctions de manipulation destinées à être utilisées en C (statique ou dynamique peu importe, je parle juste d'un framework conçu sous la forme d'une lib, le mode compilation n'a aucune importance et se change en 5 minutes).
- Un programme utilisable en BASIC qui utilise les arguments qu'il a reçu depuis la ligne de commande pour appeler les fonctions de ta bibliothèque (c'est à dire le "wrapper" évoqué en ./9).

De cette façon tu pourras fournir à la fois un programme destiné au basic (sous la forme d'un exécutable autonome ou d'un exécutable + une librairie dynamique, encore une fois ça ne change rien), et une bibliothèque facile à exploiter si quelqu'un est intéressé par ton outil.
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

14

Zephyr (./13) :
De cette façon tu pourras fournir à la fois un programme destiné au basic (sous la forme d'un exécutable autonome

C'est tout à fait possible en effet.
Zephyr (./13) :
ou d'un exécutable + une librairie dynamique

Tu peux détailler stp ? Je vois pas ce que ça donnerait.

15

En fait moi je vote pour le programme kernel (histoire de bien foutre la merde ^^).
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

16

Zeph > en nostub, tu es obligé de faire une lib statique (et je trouve ça dommage sad )
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

17

Très j'ai compris. il y 3 version possibles :

- Un wrapper pour le basic(lanceur de fonction : prions que ça rame pas trop ) :

J'avais en effet pensée à ça : ( on va donner un nom au prog : stckLib ou argLib )
- passer en paramètre à arglib une fonction et ses arguments
- argLib verrouiller le Handle de la fonction pour l'appeler en faisant l'extraction des arguments individuels.



- Un lib statique :

ça veux dire que le code sera libre je suppose ? c'est quoi la différence avec lib dynamique



- Un programme KERNEL:

Ca va crée un genre de DLL que les programmes en mode KERNEL peuvent utiliser



Bon je vais lire la DOC de préos et déjà essayer de finir la Version lib pour le Basic et faire des tests pour
voir ce que ça donne niveaux vitesse.

En fait j'ai juste extrait le moteur de ExtLib, que j'ai un peu modifier.
Voici le fonctionnement actuel :

** parcours de chaque argument à partir d'une version perso de next_expression_index utilisant la dite fonction : my_nei
my_nei fait les opérations suivantes en tout en parcourant l'argument

- sauvegarde des pointeurs sur début et fin de l'argument
- sauvegarde dans un tableau des offset de chaque élément des arguments LISTE ou MATRIX
- la taille du tableau d'offset est limité pour l'instant à 2000 éléments donc 4Ko
- On peut donc pointer directement vers chaque élément de l'argument



J'évite ainsi de parcourir les arguments de façon inutile.
Je précise que l'indirection est supportés.

Si vous avez des suggestions n'hésiter pas.
C'est vrai que limiter la taille des données de type tableau à 2000 éléments est peut-être un peu radical.

Je pourrai toujours trafiquer et stocker directement les tableaux d'offset dans l'Estack.
Ce qui éviterai l'allocation de mémoire, mais ça limitarai la taille des tableaux d'offset
à moins de 64ko/nbr_arguments par argument

18

andoh_wilfried (./17) :
ça veux dire que le code sera libre je suppose ? c'est quoi la différence avec lib dynamique

Pas nécessairement. Les programmes auront juste besoin d'un header pour savoir comment appeler les fonctions, mais les fonctions elles-même seront dans une librarie statique (un fichier archive, extension .a). Ton code ne sera donc pas visible.

Une lib statique est linkée à la compilation : le code de ta lib est ajouté au programme qui l'utilise à la compilation. Chaque programme utilisant ta lib inclut les morceaux qu'il en utilise.
C'est un fichier archive sur PC.

Une lib dynamique est linkée quand le programme qui l'appelle se lance : les sauts vers les fonctions de ta librarie sont résolus par un kernel, et les programmes qui utilisent ta lib n'en contiennent pas le code.
C'est un fichier "asm" sur la calculatrice.




Ce que tu peux faire en kernel, c'est un programme foutu comme ça :
- les programmes basic appelleront le programme, la fonction main() sera exécutée. A elle de lire les arguments du programme basic pour savoir quelles fonctions doivent être exécutées.
- les programmes C appelleront directement les fonctions exportées du même programme, sans passer par main. Tu leur auras fourni un header pour qu'ils sachent comment passer leurs arguments.

Ca revient donc à faire un seul et unique fichier sur la calculatrice, servant à la fois aux programmes Basic et C. Ca évite d'avoir un wrapper sur calculatrice et une archive sur PC.

19

Folco (./14) :
Tu peux détailler stp ? Je vois pas ce que ça donnerait.
Flanker (./16) :
Zeph > en nostub, tu es obligé de faire une lib statique (et je trouve ça dommage sad )

TIGCC ne propose pas de créer des DLL nostub ? (limitées à une seule par programme, mais DLL quand même). Ou alors ma mémoire me faut défaut...
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

20

Oui, en effet, mais bonjour si chaque programme doit embarquer le mini-kernel nécessaire au lancement de cette DLL. Sans parler que le temps d'appel d'un programme basic (relogement du wrapper + chargement de la DLL).

21

c'est sûr que c'est pas optimal comme solution, j'évoquais juste le fait que ce soit techniquement possible ^^

la solution kernel que tu décris en ./18 est intéressante sur le concept, mais je trouve que se trainer une dépendance kernel pour un programme basic n'est vraiment pas une bonne idée, surtout si c'est pour gagner les 3 ou 4ko que va peser la bibliothèque (et encore, c'est uniquement si on suppose que plusieurs programmes l'utilisant seront installés sur une même calc).
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

22

En effet ton argument est de taille Zephyr.

Combien de programme fait en mode KERNEL font utilisation des LISTES et MATRIX comme paramètres pour retourner des LISTES ou MATRIX
ou alors exécuter des commandes Graphiques ?

D'un autre coté ça ouvre la porte à la possibilité pour programme de lire des données sauvegardées dans les LISTES ou MATRIX quelques appels de fonctions

23

Dur de te donner un nombre comme ça. D'ailleurs, ça m'étonnerait qu'en-dehors des programmes spécifiquement faits pour interagir avec du Basic, les programmes (kernel ou non d'ailleurs) utilisent en représentation interne les structures du TIOS (listes et matrices) : les fonctions d'accès sont en effet très lentes et contraignantes. Ils utilisent à mon avis, pour la très très grande majorité, des types propres au langage dans lequel ils sont programmés (tableaux en C, zones de mémoire directement en assembleur).

24

Les DLL AMS native ne sont pas du tout faites pour le partage de code grin
Leur footprint est important, à cause du code de chargement du DLL.

Comme dit plus haut par Zephyr, entre autres, ça n'est pas très intéressant de faire une lib kernel, à cause de la faible probabilité de faible partage de code entre plusieurs programmes qui utilisent la lib.
Une librairie statique, wrappée par un programme ASM AMS native ("nostub"), sera probablement ce qui gaspillera le moins de place.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

25

Zeph > « Nos DLLs sont volontairement limitées à une seule DLL pour éviter l'utilisation en tant que véritables DLLs! »
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

26

27

./25 : attentions, de fausses DLL se cachent parmi nous !
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

28

ok, merci à tous. Vais tacher de faire le Wrapper pour le basic pour voir.

29

Zephyr (./27) :
./25 : attentions, de fausses DLL se cachent parmi nous !

I don't exist embarrassed
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

30

bonne mémoire grin
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)