Posté le 19/07/2009 à 02:45 Membre depuis le 10/06/2001, 40251 messages
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 (fr/en), MobiFiles (de)
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é
Posté le 19/07/2009 à 08:02 Membre depuis le 28/10/2001, 7625 messages
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.
Posté le 19/07/2009 à 12:25 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 19/07/2009 à 23:03 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 19/07/2009 à 23:25 Membre depuis le 28/08/2003, 8205 messages
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. »
Posté le 19/07/2009 à 23:27 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 19/07/2009 à 23:29 Membre depuis le 11/06/2001, 19563 messages
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
Posté le 19/07/2009 à 23:29 Membre depuis le 28/08/2003, 8205 messages
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. »
Posté le 19/07/2009 à 23:31 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 19/07/2009 à 23:39 Membre depuis le 11/06/2001, 19563 messages
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.
Posté le 21/07/2009 à 14:11 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 03/08/2009 à 22:35 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 04/08/2009 à 04:18 Membre depuis le 28/08/2003, 8205 messages
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. »
Posté le 04/08/2009 à 10:31 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 06/08/2009 à 02:38 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 06/08/2009 à 08:36 Membre depuis le 11/06/2001, 19563 messages
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.
Posté le 06/08/2009 à 12:16 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 06/08/2009 à 12:35 Membre depuis le 11/06/2001, 19563 messages
Tiens, je viens de me rendre compte que je peux fusionner HeapLock et HLock en une seule fonction pour gagner 18 octets. smile
Posté le 06/08/2009 à 13:12 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 06/08/2009 à 13:14 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 06/08/2009 à 13:28 Membre depuis le 11/06/2001, 19563 messages
Mais je me bas pas là. C'est pas pareil. Je remarque. C'est tout.
Posté le 06/08/2009 à 13:28 Membre depuis le 28/10/2001, 7625 messages
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.
Posté le 06/08/2009 à 13:30 Membre depuis le 11/06/2001, 19563 messages
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).
Posté le 06/08/2009 à 21:44 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 06/08/2009 à 23:48 Membre depuis le 11/06/2001, 19563 messages
Surement, mais clairement pas avant la 0.83... Pas si simple à coder sans tout casser à coté sad
Posté le 07/08/2009 à 00:40 Membre depuis le 10/06/2001, 40251 messages
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 (fr/en), MobiFiles (de)
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é
Posté le 07/08/2009 à 01:59 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 07/08/2009 à 11:31 Membre depuis le 11/06/2001, 19563 messages
En effet... Va falloir réfléchir.
Posté le 08/08/2009 à 01:14 Membre depuis le 18/06/2001, -26082 message
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) !
Posté le 08/08/2009 à 01:21 Membre depuis le 11/06/2001, 19563 messages
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
Posté le 08/08/2009 à 01:39 Membre depuis le 18/06/2001, -26082 message
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) !