QQN a t il un ANTI CRASH POUR Ti89 !!! SVP - Page 3

J'ai l'impression que vous bavez d'indignation parceque j'ai dit des trucs contre PreOS.
Je suis pas contre PreOS. Mais tout joueur qui s'y connait voit bien
qu'il y a plus de jeux NoStub sans plantages que de jeux Kernels sans
plantages.

je pense plutôt que les programmes en asm sont plus facilement buggués que ceux en C car
1) ils sont parfois vieux donc codés à une époque où la TI n'était pas tjs très bien connue
2) c'est bcp plus facile de laisser des bugs qui ne se voient pas en asm

Les plantages viennent pas par l'intervention divine, vous savez.
C'est peut-etre la qualité du programmeur qui est en cause.

t'as codé quoi comme programme ?

Mais les plantages peuvent aussi te corrompre l'archive. Vive EM_Write!

Possible, ok, mais c'est jamais arrivé.

Ca m'est déjà arrivé (avec un programme nostub ) et mon AMS a été crashée

Sans doute les programmeurs se ruent-ils sur l'ASM parceque ca fait classe et
que c'est plus vraiment puissant que le C à ce qu'ils disent et ils veulent
utiliser la technologie truc ou la librairie machin alors on programme pour kernel bien évidemment parcequ'on a peur des plantages qui tombent du ciel.

Perso que je code en asm parce j'aime bien ça, parce que j'ai la flemme d'apprendre le C et qu'on peut facilement faire des trucs marrants (plus qu'en C j'ai l'impression).
L'anticrash n'est qu'une des nombreuses fonctions du kernel, idem pour les libs. J'ai tenté de faire un désassembleur de programmes kernel (en nostub), ça m'a donné envie de programmer en kernel quand j'ai vu toutes les possibilités du relogement kernel

snow> je t'oublie pas, je repondrai apres

Flanker
: J'ai tenté de faire un désassembleur de programmes kernel (en nostub), ça m'a donné envie de programmer en kernel quand j'ai vu toutes les possibilités du relogement kernel

TIGCC 0.95 te donnera pas mal de ces possibilités en _nostub aussi.

en ASM ?

Oui, aussi. Vu que c'est le linker qui gère le code de démarrage et plus un système de patchage des fichiers .s sortis par le compilateur comme avant, c'est entièrement utilisable en assembleur.

avec les RAM_CALL ? les BSS ? les libs dynamiques ?

Laisse non la surprise Kevin. Vive TIGCC 0.95.

Il y a:
* relogements au format des kernels ou en un format compressé
* ROM_CALLs au format des kernels ou en un format compressé, utilisables avec exactement la même syntaxe qu'en mode kernel (jsr _ROM_CALL_ABC)
* BSS, avec relogements au format des kernels ou en un format compressé, et avec initialisation automatique à 0 en option
Tout ceci activable et désactivable séparément.

Il n'y a pas les RAM_CALLs (ce sont des adresses internes à AMS trouvées par le kernel à travers des hacks; la solution propre est d'utiliser les ROM_CALLs exportés plutôt que ces adresses internes) ni les librairies dynamiques (utilise les librairies statiques).

les RAM_CALL ne sont pas toujours un hack je crois. Ca peut aussi être une méthode économe en place pour des constantes (genre les dimensions de l'écran, les codes de touche).
Maintenant, je n'ai plus trop d'idées de programmes (faudrait que je finisse d'abord tous mes TSR et CS), mais a priori ils seront en kernel

Flanker
: les RAM_CALL ne sont pas toujours un hack je crois. Ca peut aussi être une méthode économe en place pour des constantes (genre les dimensions de l'écran, les codes de touche).

Si tu veux gagner de la place avec les constantes, tu peux faire des versions séparées pour chaque modèle. Par exemple:
move.l #__ld_calc_const_92_89_93_200,model_number
(93 représentant la TI-92+)
La valeur pour TI-92 peut être omise si tu ne linkes pas pour TI-92 (Fargo):
move.l #__ld_calc_const__89_93_200,model_number
C'est le linker qui mettra les vraies valeurs lors de l'exportation des fichiers tout à la fin de la phase de linking, donc le temps de compilation est presque le même qu'en faisant une version identique pour les 3 modèles.
Tu peux utiliser ces __ld_calc_const dans n'importe quel contexte où une vraie valeur immédiate est utilisable (sauf addq/subq, et je pense que moveq #__ld_calc_const ne va pas marcher non plus avec A68k parce que le format AmigaOS ne prévoit pas les relogements absolus 8 bits; on peut éventuellement corriger ça en rajoutant une extension au format AmigaOS).

Maintenant, je n'ai plus trop d'idées de programmes (faudrait que je finisse d'abord tous mes TSR et CS), mais a priori ils seront en kernel

je n'aime pas avoir des versions séparées pour chaque modèle. Jusqu'à présent, c'est ce que j'ai fait car c'était trop dur de développer CS pour les 89 et les 92+ en même temps.

Bon, j'ai vérifié: pas de problème avec les relogements 8 bits (move.b #__ld_calc_const_92_89_93_200,model_number marche), mais moveq #__ld_calc_const_92_89_93_200,d0 bogue quand-même. C'est un bogue qu'il va falloir que je corrige.

Flanker
: je n'aime pas avoir des versions séparées pour chaque modèle.

Franchement, moi non plus.
Bon, alors ce que tu fais est que tu actives la détection de modèle automatique:
__ref_all___detect_calc: xdef __ref_all___detect_calc
et tu as le code du modèle (0=TI-89, 1=TI-92+, 3=V200) en __calculator, et tu peux choisir tes constantes en conséquence.

Kevin Kofler :
Bon, j'ai vérifié: pas de problème avec les relogements 8 bits (move.b #__ld_calc_const_92_89_93_200,model_number marche), mais moveq #__ld_calc_const_92_89_93_200,d0 bogue quand-même. C'est un bogue qu'il va falloir que je corrige.

Bon, je vois ce qui se passe: pour le move.b, un relogement 16 bits est créé. Pour le moveq, le relogement n'est pas créé. Je pense qu'il faudra que je rajoute une extension pour les relogements 8 bits au format AmigaOS pour règler ça proprement. En attendant, avec du .l ou du .w, ça marche parfaitement. Si tu veux absolument utiliser ça avec du .b ou du moveq, utilise GNU as, il gère ça sans problèmes.

ben dites donc, c un collector ce topic !!

snow-tiger devrait penser à passer professionnel, il excellerait en competition

Oué. C'est étonnant que personne ne l'ait smashé (sauf si tu considère le post n°51 comme tel...)

Amusant ce topic.

Bon comme je disais sur IRC à l'instant, est-ce vraiment utile de continuer un débat kernel/_nostub lancé par quelqun qui visiblement n'a pas l'air très au courant de ce qu'il raconte (cf. les énormitées qui jonchent l'integralité de ses posts depuis le début de ce topic) ?

non.

snow-tiger :
OK le bleu de service dit que je suis nioob, lui qui a jamais fait marcher
le moindre jeu TI et se la joue à casser tout le monde tandis que
je parle à PpHd et à Kevin et pas au sale petit morpion inutile et gênant qu'il est.

Ok, moi ça fait 3 ans que je suis ds la communauté TI et que je code dessus. Je pense etre un peu mieux placé que toi pour parler de kernel/nostub (meme si je suis loin de PpHd ou kevin, je ne code pas de kernel moi).

snow t'en as pas marre d'être con ?

kevin> ca m'etonne de toi que tu n'aie pas reagi a cette phrase de snow-tiger:

OK le bleu de service dit que je suis nioob, lui qui a jamais fait marcher
le moindre jeu TI et se la joue à casser tout le monde tandis que
je parle à PpHd et à Kevin et pas au sale petit morpion inutile et
gênant qu'il est.

peut-etre parcequ'il arrete pas de te lecher les burnes depuis le debut du topic?

me demande ce que t'aurais sorti si ca avait ete vark/liquid/moi ou n'importe qui d'autre qui ne partage pas tes opinions qui avait dit ca
"oh mon dieu quelle honteuse attaque personnelle! shocked!"

snow: munis-toi d'une corde, et suspend toi

snow-tiger> heu juste un conseil comme ca, va te cacher, tu fais pitie

#80 > meuh non ce genre de propos qd ça vient d'une sous-merde c un compliment

Vark> j'avais pas vu les choses comme ca

Kevin l'a vu LUI

tandis que je parle à PpHd et à Kevin

ca te fait jouir de leur parler?

mmh parle moi alors

(_)o(_)

Kevin Kofler
:

geogeo
: Certain programme sur TI ne sont pas réalisable en C

Le C est Turing-complete donc tout ce qui est faisable en assembleur est démontrablement faisable aussi en C.

Je croyais plutôt que c'était axiomatiquement ?

démontrablement: absent du larousse
c'est abracadabrantesque ce mot