Les RAM_CALLs sont tous obsolètes et/ou inutiles. On peut parfaitement écrire ses chaînes Exec sans en utiliser. Cf. aussi http://www.tigen.org/kevin.kofler/ti89prog/ramcalls.txt.
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Tu peux avoir cette opinion, mais d'autres personnes peuvent en avoir une autre wink
Deux choses qui sont réellement obsolètes, en revanche, sont ton fichier et le support kernel de TIGCC wink
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Kevin, je sais coder merci, tes remarques HS je m'en passe. T'en reparleras quand t'auras fait un LibsExec en nostub.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Ya pas à chier, des fois je suis une bête en optimisation :
		move.w	12(%a0),%d0			|read handle
		movea.w	%d0,%a0				|arg
		trap	#3				|deref it

couic

Ceci dit, je suis passé de 971 à 921 bytes ce soir, pour la partie principale.

Question : Faites-vous un compromis entre taille et maintenabilité pour ce genre de petit soft simple ? Est-ce gênant de chercher à optimiser à mort ? Sur 650 octets de code (sans les strings), j'espère que c'est pas gênant ?
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Est-ce que c’est vraiment nécessaire de tant optimiser ? Ton programme semble déjà bien léger. Sera-t-il amené à être exécuté dans des contextes où sa taille ou sa vitesse lui feraient défaut ?
Sinon, oui, c’est rigolo d’optimiser à mort, mais ça prend du temps, et comme tu l’as dit, ça peut empiéter sur un autre objectif du code : la maintenabilité, donc tout dépend de tes priorités.
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. »
Sasume (./64) :
donc tout dépend de tes priorités.

M'amuser. grin


Sinon, ya un bug : désarchiver modifie aussi le handle, j'ai même pas vérifié ça hier soir sick
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Folco (./63) :
Question : Faites-vous un compromis entre taille et maintenabilité pour ce genre de petit soft simple ?


Rien à ******** de la taille pour ce genre de petits softs simple grin
Folco (./65) :
Sasume (./64) :
donc tout dépend de tes priorités.

M'amuser. grin
Je trouve que c’est une raison suffisante wink
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. »
Je m'en doutais remarque, mais... je m'amuse ^^ Mais je sais pas pourquoi, j'ai toujours honte de releaser du code pas optimisé ^^

(cross : merci Sasume, c'est rassurant ^^)
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Sasume (./67) :
Folco (./65) :
Sasume (./64) :
donc tout dépend de tes priorités.

M'amuser. grin
Je trouve que c’est une raison suffisante wink

Pas mieux.
La suite :
PpHd (./59) :
Folco (./56) :
La release finale arrivera quand les ramcalls en fline arriveront. mod.gif

Hum, hu, ho, ha ?

topics/123095-probleme-de-pile-que-je-comprends-pas#15
PpHd (./59) :
Folco (./58) :
(j'ai commencé à coder man ya moins de deux heures biggrin.gif )


Il est où le topic ? gni.gif

topics/123300-man/2#35
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Release finale (normalement) : http://www.mirari.fr/HEOm

Ca corrige un bug en sortie, ça devait pas toujours libérer le handle de ce qui était exécuté (je sais plus trop dans quel cas). Le binaire est descendu en-dessous de 890 octets, et il n'y a plus de loader : ça prend pas un pet de mémoire au runtime quand c'est archivé, et c'est réentrant.

Vala vala. smile
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Au fait, c’est utile que ce soit réentrant ?
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. »
PedroM supporte plusieurs shell. Et la réentrance est une conséquence de ma manière de coder, c'est pas étudié pour spécialement, donc c'est une feature qui ne coute rien.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Plus précisément : si tu fais eexec (un_prog_qui_appelle_ngetch_ou_kbhit), alors on peut lancer un nouveau shell depuis ce programme, et relancer eexec. Ok, c'est tordu, mais faut bien prévoir ça.
De la même manière que sous PedroM, si t'utilises ngetchx/kbhit, faut s'attendre à ce que tes handles puissent bouger. Faut aussi vérifier si un handle est locké avant de le locker toi-même, pour ne pas le délocker si un autre process l'utilise... et que t'as un peu de chance quand même. ^^

Parce que le coup des handles lockés peut amener un cas bien foireux :
- le programme A démarre, regarde le handle H et voit qu'il n'est pas locké, il le lock et l'utilise
- le programme B démarre, voit que le handle H est locké, et retient ce fait
- le programme A s'arrête, en délockant en toute bonne foi H pour le remettre comme il l'avait trouvé
- puis B crash tranquillement, parce que H n'était pas censé bouger. A moins qu'il ait la chance de quitter en laissant soi-disant locké un programme déjà délocké.

Je sais pas si ya moyen d'éviter ça. En tout cas, je fais maintenant des HeapGetLock en serrant les fesses pour que les programmes soient fermés en FILO. grin

La seule solution serait que chaque programme ne lock rien, refasse des deref après ses ngetchx/kbhit, mais ça dois pas exister ^^
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Il faudrait peut être un compteur pour savoir combien de fois HeapLock et HeapUnlock ont été appelés de telle facon que l'on ne delocke que si on a exactement le même nombre d'appel à HeapUnlock qu'à HeapLock.
Comme les librairies en fait, ça semble être le meilleur moyen. Maintenant, implémenter ça... Faudrait une table dynamique.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Tiens, je viens de me rendre compte que je peux fusionner HeapLock et HLock en une seule fonction pour gagner 18 octets. smile
yeah, suffit de rajouter un trap #3 à la fin de HeapLock ou un truc du genre ? grin
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Ah et au fait c'est historique :
Mais j'ai perdu l'envie de me battre pour quelques dizaines d'octets.

topics/90160-pedrom-trap-3-genlib-cf-cachelib-bref#5

gni
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Mais je me bas pas là. C'est pas pareil. Je remarque. C'est tout.
Il n'a peut-être plus l'envie, mais il n'a pas le choix grin
Il a été obligé de faire maigrir la partie 0x21A000-0x21FFFF pour pouvoir releaser la RC7 wink
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Lionel Debroux (./81) :
Il n'a peut-être plus l'envie, mais il n'a pas le choix grin
Il a été obligé de faire maigrir la partie 0x21A000-0x21FFFF pour pouvoir releaser la RC7 wink

Oui, oui entre autre. Putain de section au milieu qui ne sert à rien (Pour PedroM).
PpHd (./75) :
Il faudrait peut être un compteur pour savoir combien de fois HeapLock et HeapUnlock ont été appelés de telle facon que l'on ne delocke que si on a exactement le même nombre d'appel à HeapUnlock qu'à HeapLock.

Sérieusement tu compte l'implémenter ? Parce que ça change la manière de coder du coup : il faut faire un HLock sans se soucier de l'état courant du handle, qu'il ne faudrait pas ne pas délocker sous prétexte qu'on l'a trouvé locké avant, sous peine d'avoir un handle locké pour perpette.

Même si ça arrive que pour la 0.83, si ça va vraiment être le cas, autant le savoir le plus tôt possible.

Et à mon avis, c'est la bonne solution, étant donné que les programmes jusqu'à maintenant n'ont pas été codés pour être dans un environnement multitâche, donc les programmeurs n'ont pas dû tenir compte de ce genre de détails qu'ils ne pouvaient pas prévoir. Et un compteur de lock les ferait continuer à marcher sans problème, même en multitâche.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Surement, mais clairement pas avant la 0.83... Pas si simple à coder sans tout casser à coté sad
Ce n'est pas compatible avec AMS de faire ça, et ça va faire foirer des programmes existants (on trouve du:
HANDLE h=...;
int waslocked=HeapGetLock(h);
void *p=HLock(h);
...
if (!waslocked) HeapUnlock(h);

– c'est parfaitement correct sous AMS, mais ça va faire foirer ton compteur, ça (et virer le if (!waslocked) ferait foirer le programme sous AMS)).
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Ben faut "tout simplement" que la table de référence sache qui a locké quoi, et soit mise à jour quand un programme termine ? C'est faisable avec les PIDs ?
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
En effet... Va falloir réfléchir.
PpHd (./82) :
Oui, oui entre autre. Putain de section au milieu qui ne sert à rien (Pour PedroM).

Euh attends, tu veux dire que t'as une section entière inutilisée ? Et elle ne le sera jamais ?

j'ai déjà une idée bien tordue si c'est le cas trivil
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Folco (./88) :
PpHd (./82) :
Oui, oui entre autre. Putain de section au milieu qui ne sert à rien (Pour PedroM).

Euh attends, tu veux dire que t'as une section entière inutilisée ? Et elle ne le sera jamais ?

j'ai déjà une idée bien tordue si c'est le cas trivil

Oue
Ben tu peux faire du swap avec, si un HeapAlloc/Realloc échoue après un GC de la RAM : tu y passe tous les handles non lockés, et à leur prochain deref tu tentes de les rebasculer en RAM s'ils sont en swap. Et si ya plus de RAM quand tu veux y redescrendre un handle, tu kill l'appli. smile

et au fait, pourquoi cette section est-elle définitivement inutilisable ? confus
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !