ktigcc - Page 2

Kevin: c'est stupide ce que tu dit, le code il sera deja en archive dans 90% des cas, car l'utilisateur l'aura archivé, et au final pendant l'execution le code sera en double, dans l'archive et en ram

autant l'executer directemetn dans l'archive non ? (ce qu'on apelle du XIP)

J'adore

Bon, on va poster un message faisant allusion à la supériorité du kernel dans 2-3 topics au hasard, ça fera revivre un peu le forum

Godzil (./31) :
Kevin: c'est stupide ce que tu dit, le code il sera deja en archive dans 90% des cas, car l'utilisateur l'aura archivé, et au final pendant l'execution le code sera en double, dans l'archive et en ram

Là encore, avec les histoires de consommation de RAM et d'archive, je parle de ses programmes en plusieurs morceaux, pas de son système d'exécution en FlashROM (qui ne permet pas d'exécuter en FlashROM sous AMS et qui rajoute plein de limitations très contraignantes au programme, soit dit en passant). Il propose 2 technologies, j'ai expliqué pourquoi je les retiens toutes les 2 une mauvaise idée, mais c'est sûr que les arguments contre une des technologies ne vont pas s'appliquer à l'autre, totalement différente. (La seule chose qu'elles ont en commun est le kernel.) Donc merci de regarder le contexte...

Thibaut (./32) :
J'adore

Bon, on va poster un message faisant allusion à la supériorité du kernel dans 2-3 topics au hasard, ça fera revivre un peu le forum

c'était le business model de yaronet quelques années.

Martial Demolins (./35) :
A ma connaissance, il n'y a aucune contrainte (sauf peut-être les ints? suffit de piocher 4 octets dans la RAM). Tu peux détailler?

Pas de relogements == énorme contrainte. Par exemple, ça rend totalement impossible d'utiliser TIGCCLIB. Et sinon je signale qu'il y a aussi du code automodifiant dans TIGCCLIB.

Beurk. C'est obsolète comme façon de coder.

Perso, je trouve que le kernel est une façon un peu lâche de programmer. Oui, on peut faire des choses plus facilement, mais lorsqu'un utilisateur télécharge un programme, il s'attend à ce que ça marche, pas à avoir plein d'autres choses à se procurer (genre un kernel + des librairies).
Je sais que ce n'est pas la fin du monde d'aller se procurer ces trucs, mais perso, j'abandonnerais et j'irais plutôt me chercher un autre prog moins exigeant et qui fait la même affaire.
En plus, comme j'utilise ma calcu à l'école et pour les exams, elle se fait souvent resetter et j'ai la flemme d'avoir toujours à renvoyer un kernel pour pouvoir jouer à des jeux.
Bref, le mode kernel est bien pratique pour le programmeur mais pas très user-friendly.

Kevin Kofler (./29) :
CF utilise la mémoire (aussi l'archive) de manière totalement abusive, je sais. (AMHA, optimiser en taille plutôt qu'en vitesse pourrait réduire de beaucoup cette consommation.)

Tu veux essayer de tenir ton pari ?

KillerX (./40) :
Perso, je trouve que le kernel est une façon un peu lâche de programmer. Oui, on peut faire des choses plus facilement, mais lorsqu'un utilisateur télécharge un programme, il s'attend à ce que ça marche, pas à avoir plein d'autres choses à se procurer (genre un kernel + des librairies).
Je sais que ce n'est pas la fin du monde d'aller se procurer ces trucs, mais perso, j'abandonnerais et j'irais plutôt me chercher un autre prog moins exigeant et qui fait la même affaire.
En plus, comme j'utilise ma calcu à l'école et pour les exams, elle se fait souvent resetter et j'ai la flemme d'avoir toujours à renvoyer un kernel pour pouvoir jouer à des jeux. Bref, le mode kernel est bien pratique pour le programmeur mais pas très user-friendly.

Lancer de trolls 4/5.

oué, surtout le

Perso, je trouve que le kernel est une façon un peu lâche de programmer.

Moi je suis d'accord avec lui Mais dans la mesure où il économise de la place en archive, je préfère ce mode de programmation.

(Bon ben dans ce cas là, je vous laisse réinventer la roue à chaque fois que vous développez... au moins, avec ça, on va bien avancer ^^)

Tiens donc, un beau troll
Ca faisait super longtemps !

Je ne répondrai que sur la partie exécution en Flash.

D'une part, l'exécution en Flash ne permet pas le SMC. Le SMC qui permet parfois de bons compromis entre optimisation taille et optimisation vitesse: routine de niveaux de gris de TIGCCLIB/ExtGraph, FastDrawLine dans ExtGraph (et il me semble avoir vu du SMC dans le code de Genlib, mais je peux me tromper);

D'autre part, ne pas mélanger, dans l'image binaire du programme, les segments .data et .text, est mauvais pour l'efficacité taille surtout, et (marginalement) l'efficacité vitesse.
En effet, ça empêche l'utilisation de références d(pc) (venant souvent d'une optimisation du linker) en lecture, sauf pour les données constantes (qu'il est malin de mettre dans le même espace que .text).
Il y a au moins deux solutions pour implémenter les segments .data/.bss en RAM, .text en Flash:
* version FlashApp: segment .data ET .bss pré-alloué en RAM pour pouvoir faire la relocation lors de l'écriture une bonne fois pour toutes de la FlashApp (qui ne bouge pas lors du garbage collect de l'archive). Autrement dit, xxx.l en écriture ET en lecture - il faut faire exprès pour faire pire.
=> Consommation statique de RAM, potentiellement élevée; à moins de spécifier qu'un programme à exécution en Flash ne bougera pas lors d'un garbage collect de la Flash, il faut garder les infos de relocation, ce qui ajoute à la taille.
* version FlashApp modifiée: on alloue lors de l'écriture du programme (bootstrap), un handle en RAM, qui ne contiendra que les pointeurs vers .data et .bss lors de l'exécution. Bloc auquel on fait référence à travers une adresse xxx.l.
=> consommation statique de RAM négligeable, MAIS ajout d'un niveau d'indirection.

(Ce deuxième point n'est pas valable si on utilise du reg-relatif pour les accès à .data et .bss - ce qui n'est possible que si la somme des deux tailles ne dépasse pas 64 KB).


En résumé: pour moi, c'est pas une bonne idée de faire de l'exécution en Flash...

Pourtant c'est nécessaire pour les programmes qui ont vraiment besoin d'un max de RAM. GTC est le meilleur exemple.
[hop, 2 trolls en 1 ]

Lionel Debroux (./45) :
[...]


En résumé: pour moi, c'est pas une bonne idée de faire de l'exécution en Flash...

Pourtant c'est ce qui est fait dans (disont) 90% du materiel embarqué, c'est bien qu'il y a une raison

> Pourtant c'est nécessaire pour les programmes qui ont vraiment besoin d'un max de RAM.
C'est nécessaire, mais on perd en efficacité
Il y a rarement des solutions présentant tous les avantages.

> > En résumé: pour moi, c'est pas une bonne idée de faire de l'exécution en Flash...
> Pourtant c'est ce qui est fait dans (disont) 90% du materiel embarqué, c'est bien qu'il y a une raison
Evidemment, mais c'est simplement une raison autre que l'efficacité taille et vitesse du code
Quand on fait de l'exécution en Flash en général, on profite de la non-volatilité de la mémoire (à l'échelle de quelques années). C'est plus facile / moins coûteux d'avoir une grosse Flash que d'avoir une grosse RAM.

bah je suis à peu près d'accord avec lui... C'est au programmeur de se casser la tête, pas à l'user. Mais bon si c'est vraiment un gros avantage pour le programmeur, on peut peut-etre faire des concessions

ouais pour les décompresseur à la limite ok, mais pour tester AMS ou HW c'est pas grand chose franchement (en temps d'execution et en terme de place pour les différents codes). Et encore le décompresseur peut etre négligeable pour les gros programmes = ceux pourquoi on utilise un décompresseur en principe.

onur (./50) :
bah je suis à peu près d'accord avec lui... C'est au programmeur de se casser la tête, pas à l'user

Amha, tout dépend de la finalité.
Soyons clairs : les programmes sur TI, ça reste adressé à une certaine forme de geeks (et en plus ils tournent sur une plate-forme qui n'est pas vraiment faite pour ça à la base, donc c'est un peu normal d'avoir à bidouiller un petit peu pour que ça roule).
L'objectif n'est pas le même que celui de MS Word par exemple, qui est un produit commercial destiné au grand public, et pour lequel les développeurs doivent vraiment faire un maximum d'efforts pour faciliter l'utilisation.

En meme temps dire qu'installer un kernel est dur, c'est de la mauvaise foi

ouais mais après les problèmes de dépendance, tu les a avec le kernel que tu utilises non? (j'ai jamais codé en kernel).

je sais pas, j'y connais rien. Les noms des fonctions sont-elles identique d'une lib à l'autre? Après, l'utilisateur doit se préoccuper de la version du kernel etc.. Ca devient vite le galère, je me souviens à l'époque où j'étais simple utilisateur.

PpHd (./41) :

Kevin Kofler (./29) :
CF utilise la mémoire (aussi l'archive) de manière totalement abusive, je sais. (AMHA, optimiser en taille plutôt qu'en vitesse pourrait réduire de beaucoup cette consommation.)

Tu veux essayer de tenir ton pari ?

Vu qu'il faudrait essentiellement reconcevoir CF (y compris genlib) depuis le départ (c'est entièrement conçu pour la vitesse au dépens de la taille), je n'ai pas du tout le temps. Rien que genlib aurait besoin d'une réécriture d'une grande partie du code (genlib-small est tout sauf optimale en taille).

Lionel Debroux (./45) :
Le SMC qui permet parfois de bons compromis entre optimisation taille et optimisation vitesse

Voire de l'optimisation taille tout court dans certains cas.

Martial Demolins (./51) :
C'est pas que ça. si tu veux overlaoder ton programme pour qu'il sache décompresser, s'adapter aux AMS et aux HW, trouver et utiliser des fichiers de données etc, tu peux, mais ça bouffe de la place à chaque fois.

Le lanceur-décompresseur prend 1 KO seulement (grâce à ttunpack-small, merci à Samuel Stearley!), et en plus un lanceur-décompresseur commun peut être utilisé, donc c'est un très mauvais argument. La consommation de place pour la compatibilité avec les différents AMS/HW est minime, quant aux fichiers de données, les fonctions nécessaires sont déjà dans AMS (vat.h), donc je ne vois pas de quelle consommation de place tu parles là. (De plus, le kernel ne propose rien pour les fichiers de données, à part l'abus du système de librairies conditionnelles de PreOs.)

Martial Demolins (./53) :
Par contre, c'est lourd (regarde la manière dont AMS est détecté dans PreOS par exemple).

Un programme normal n'a pas besoin de détecter AMS de cette manière, PreOs contient ces détections pour faire marcher les RAM_CALLs qui servent à faire marcher les programmes bogués qui utilisent des hacks obsolètes (et d'ailleurs, souvent, un réassemblage de ces programmes est nécessaire pour les faire utiliser les nouveaux RAM_CALLs plutôt que les anciens hacks avec des adresses ou des offsets codés en dur).

Martial Demolins (./57) :
dépendances? tu parles du seul et unique fichier de lib à envoyer?

Non, il parle des versions toutes incompatibles des libs en circulation.
* stdlib ne pourra jamais regrouper toutes les libs utilisées.
* Rien ne garantit que tous les programmes sont compatibles avec les versions dans stdlib.
* stdlib est une solution "bulldozer" au problème, on gaspille 20 KO (compressés en plus) pour fournir toutes les libs qu'un programme pourrait utiliser, même si aucun programme n'utilise ne serait-ce qu'une seule fonction de certaines de ces libs. (Par exemple, qui utilise réllement jplib?)