encore une chtite question - Page 20

Certes, ça serait pas mal que le prochain TIGCC gère ce genre de trucs.

Bon, je vous relis la définition originale de CALCULATOR:

Zero on TI-89, non-zero on TI-92 Plus.

En d'autres mots, CALCULATOR était défini comme un booléen, et donc utilisé comme tel!

Maintenant, on a:

This pseudo-constant is 0 on the TI-89, 1 on the TI-92 Plus, and 3 on the V200.

Mais le fait que c'est zéro sur TI-89 n'a pas changé et ne changera pas. (Ça correspond toujours à la définition originale <=> compatibilité source.)

Et dans TIGCC, CALCULATOR est un nombre non signé, donc le CALCULATOR<=0 suggéré par PpHd revient au même.

Ensuite, pour votre suggestion, ça y est déjà!
http://tigcc.ticalc.org/doc/compat.html#PSEUDO_CONST_CALC
http://tigcc.ticalc.org/doc/compat.html#PSEUDO_CONST_KBD
http://tigcc.ticalc.org/doc/compat.html#PSEUDO_CONST_SCREEN

Martial Demolins > à ce que j'ai compris, tu donnes l'adresse d'une fonction A comme argument à une fonction B. B pourra comme ça utiliser A, par exemple pour une fonction de tri : tu lui donnes une fonction A callback qui compare juste 2 éléments de n'importe quel type, et la fonction B de tri pourra comme ça trier différents types d'éléments

À l'origine, il ne pouvait valoir que 0 ou 1. Mais on était suffisamment prévoyants pour mettre "non-zero" plutôt que "1" comme l'ont fait les kernels. Ce qui a fait que nous avons pu mettre CALCULATOR à 3 pour la V200 sans soucis, alors que PpHd a été obligé de faire mentir PreOs et de continuer à dire 1 aux vieux programmes, parce qu'on y trouvait du 30+CALCULATOR*20 .

je crois pas que ce soit possible, mais au pire tu définis trop d'arguments et tu ne les utilises pas tous ^^

Bon, encore des trucs dont je voudrais qu'ils soient dits:

Link
: Mais je pense que TIGCC et son linker devraient prendre en compte le kernel.h de PhHd,

Jamais.

et accepter que preOS reste le kernel principal,

Ben, il n'est plus le seul maintenant, puisqu'il y a Iceberg.

titanik et iceberg ayant été, je crois, faits seulement pour la titanium, non?

C'est vrai pour Iceberg 1.00, mais je compte faire un Iceberg 2.00 compatible tous modèles dans les semaines qui viennent.

Et ne plus rouspèter sur la compatibilité avec les anciens kernels... que PreOS soit LE kernel, et qu'il n'y ait plus de concurrence de kernels stupides dues à une fierté mal placée!

Donc je devrais accepter PreOs comme le monopole? Il y a toujours eu une multitude de kernels compatibles entre eux dans l'histoire des TI-89/92+/V200, je ne vois pas pourquoi ça devrait changer maintenant. Et je ne vois pas non plus pourquoi PpHd se permet de rajouter des trucs sans me demander mon avis, pourquoi en tant qu'auteur de Iceberg (et co-auteur de PreOs, même, d'ailleurs!) je serais moins important que les auteurs de DoorsOS, TeOS et Universal OS auxquels il a demandé leur avis (même si c'était juste pour avoir la confirmation qu'ils s'en foutent et qu'ils lui donnent carte blanche)?

Mais les formats Kernel ne sont pas obsolètes,

Si.

Ximoon :
>Bon, c'est vrai qu'ils s'en foutaient.
>Mais là, pour PreOs 0.70, tu n'as pas du tout demandé l'avis de l'auteur de Iceberg (moi) avant de rajouter tes trucs... Tu as même mis des trucs que j'ai explicitement rejetés (GHOST_SPACE).

Iceberg est un fork de PreOs, c'est toi qui t'écarte du tronc, pas lui

Pollux :
Mdr, donc forker un kernel te donne le droit de limiter les évolutions du kernel ?

Dites-donc, vous avez lu au moins la doc pour savoir de quoi je parle, tous les deux? GHOST_SPACE est un RAM_CALL visé à permettre de continuer ce hack affreux:
move.l foo,GHOST_SPACE+0x64
au lieu d'utiliser la méthode propre:
bclr.b #2,0x600001
move.l foo,0x64
bset.b #2,0x600001
En plus, avec le relogement du RAM_CALL, ce n'est même plus intéressant en taille, c'est juste un hack qui ne sert strictement à rien. Et évidemment, PpHd utilise ça dans la graphlib de PreOs 0.70 au lieu d'utiliser la méthode propre comme je l'ai fait dans Iceberg.

Ximoon :
>Compatibilité des nouveaux programmes avec les anciens kernels. Sous TeOS, ils planteront même s'ils utilisent tes RAM_CALLs!

Quelle idée d'utilier TeOs... La meilleure solution est de laisser tomber ce kernel obsolète.

Je voudrais bien, mais je ne peux pas empêcher aux utilisateurs de l'avoir, et des programmes qui plantent sous quelles conditions que ce soit ne sont pas acceptables pour TIGCC. S'il y avait un moyen fiable de détecter un kernel dépassé comme on le fait pour les AMS dépassés, ça se discuterait, mais là, on ne peut rien faire à part ne pas utiliser le RAM_CALL si on ne veut pas que ça plante.

Ximoon :
>Sur Titanium, ben je l'ai fait avant toi.

Si tu as eu des beta-testeurs et un ams 3.00 à disposition avant lui c'était pas dur

Bah, il aurait suffi de demander à Samuel, il aurait certainement été à sa disposition pour PreOs autant qu'il l'a été à la mienne pour Iceberg.

Dites-donc, vous avez lu au moins la doc pour savoir de quoi je parle, tous les deux? GHOST_SPACE est un RAM_CALL visé à permettre de continuer ce hack affreux:
move.l foo,GHOST_SPACE+0x64
au lieu d'utiliser la méthode propre:
bclr.b #2,0x600001
move.l foo,0x64 bset.b #2,0x600001

est-ce que ce n'est pas ce "hack affreux" qui a été utilisé dans TIGCC pdt pas mal de temps, contrairement à ce que certains conseillaient, et qui a causé des problèmes d'incompatibilité, justement ?

C'est vrai pour Iceberg 1.00, mais je compte faire un Iceberg 2.00 compatible tous modèles dans les semaines qui viennent.

je ne vois toujours pas l'intérêt d'un Iceberg 2.00, à part faire emmerder tout le monde en faisant deux kernels incompatibles entre eux (enfin, faire une version light et sans toutes les fonctions et une version complète).
Enfin, si on m'avait dit qu'un jour tu te mettrais à programmer des kernels, j'avoue que je ne l'aurais sûrement pas cru

Ben, il n'est plus le seul maintenant, puisqu'il y a Iceberg.

n'empêche qu'il reste le kernel le plus utilisé

Il y a toujours eu une multitude de kernels compatibles entre eux dans l'histoire des TI-89/92+/V200, je ne vois pas pourquoi ça devrait changer maintenant.

Et tu veux arranger les choses en faisant un kernel incompatible avec PreOS 0.70 ?

en tout cas, si on t'écoutait, on serait resté à l'âge de pierre :/

squale92 :
est-ce que ce n'est pas ce "hack affreux" qui a été utilisé dans TIGCC pdt pas mal de temps, contrairement à ce que certains conseillaient, et qui a causé des problèmes d'incompatibilité, justement ?

C'est vrai, mais ce hack provenait des kernels, et justement, si j'ai éradiqué ce hack de TIGCC, ce n'est pas pour que monsieur PpHd le réintroduise partout à travers PreOs!

Et en plus, même lui documente même GHOST_SPACE comme "deprecated". Je ne comprends pas pourquoi il rajoute un nouveau RAM_CALL s'il est "deprecated" dès le départ! Ni pourquoi il utilise un RAM_CALL "deprecated" dans sa graphlib, d'ailleurs.

>C'est vrai, mais ce hack provenait des kernels, et justement, si j'ai éradiqué ce hack de TIGCC, ce n'est pas pour que monsieur PpHd le réintroduise partout à travers PreOs!

Quel hypocrite !
Dans un topic ici même, quelques jours avant l'arrivée de la 89ti tu soutenais contre moi qu'il vallait mieux utiliser ce hack pour des raisons d'économie de place ! Et maintenant tu fous ça sur le dos des kernels, qui en sont à l'originr pour des raisons purement historiques (bah oui, ils étaient là les premiers, forcément les routines nostub ont été stupidement copiées dessus...).

Jamais

C'est un peu faible, ça comme argumentation...
Tu avais beau avoir raison pour CALCULATOR, maintenant, à force d'être intransigeant comme ça, tu as tord!

On essaie de concilier deux personnes et il y en a toujours une qui refuse la moindre concession...
Le conflit israélo-palestinien risque de se terminer avant ce différend...

la question complète est bien 'qu'un handle en mémoire pour y stocker ses données" ? si cest le cas, bah c'est le kernel qui s'occupe des relogements (de l'attribution du handle, etc...) et comme ça tu pourras utiliser des adresses absolues directement dans le handle, sans bloquer un registre pour y mettre l'adresse du handle

Oui, mais en général en nostub on en perd de la place justement, car le code d'allocation/initialisation du segment BSS est inclus dans le programme (enfin dans tous les programmes que j'ai testés ça s'est vérifié, je généralise peut être trop ...)

Le code de démarrage est très compact! Ce qui prend de la place, ce sont surtout les relogements absolus que ça crée.

Les faits demeurent.

>Monsieur "j'utilise le non-linkeur obsolète du kernel le plus obsolète existant sur TI-89/92+ et je lui apporte quelques quick hacks" traîte notre linker puissant et évolué de "has been". Tu n'en as pas d'autres?
Heu... J'utilise a68k aussi. Ca te va ?

>Mais là, pour PreOs 0.70, tu n'as pas du tout demandé l'avis de l'auteur de Iceberg (moi) avant de rajouter tes trucs... Tu as même mis des trucs que j'ai explicitement rejetés (GHOST_SPACE).
Tu m'a deconseille vaguement de le faire. Et je l'ai declare expres "outdated".

>Compatibilité des nouveaux programmes avec les anciens kernels. Sous TeOS, ils planteront même s'ils utilisent tes RAM_CALLs!
Je sens que je vais sortir une nelle version de Teos avec ca de corriger...
T'es lourd lorsque tu veux. Mais c'est pour ca que je t'aime bien.

>N'importe quoi, pratiquement tout ce que patche GhostBuster peut aussi se trouver dans un programme kernel.
Theoriquement oui. Pratiquement non.

>Notamment, le bogue de ROM_base avec 0x600000 se trouve dans tous les programmes kernel en C avec niveaux de gris compilés avec une vieille release de TIGCC.
Ca existe ?

>Et puis tu montres là un désavantage des packs archive, pas de GhostBuster.
>GhostBuster patche parfaitement les librairies.
Tu as raison. C'est hyper user-friendly pour un utilisateur de patcher toutes les libraries d'un programme.
Deja faut qu'il trouve les libraries du programme, puis qu'il pense qu'elles peuvent etre compresses, qu'il les decompresse, qu'il les patche, ...
T'en as d'autres

>Depuis quand tu prend les utilisateurs pour des idiots?
Depuis que je discute avec toi

> S'il est capable d'installer un kernel, il est aussi capable d'utiliser un patcheur, ce n'est pas plus compliqué.
Si! Car il faut donner des arguments.

>Avec mon entrée de FAQ, ça passe très bien.
Mmm. C'est pour ca que l'on recoit tant de messages sur les forums ?

>Pas pour tous les programmes kernel...
Exemples ?

>Sur V200, c'était une adaptation minime de PreOs, plus une fonction "lie about CALCULATOR" pour les programmes qui utilisaient des trucs débiles comme CALCULATOR*30. Pas dur, franchement.
Oue, mais indispensable.

>Je n'y peux rien si ton header ne suit pas la documentation de TIGCC.
Je ne dirais pas que c'est fait pour.

>On n'avait pas de choix. Comme je viens de le dire sur ticalc.org:
>As far as TIGCC is concerned, the Titanium is just a TI-89 HW3.
J'ai jamais dit que vos arguments etaient faux. Je pense juste que les miens sont plus importants.

>En plus, cette valeur a été prise en concertation avec les kernels existants (TitaniK et Iceberg),


>et elle a été discutée sur le forum de la TICT aussi, donc je pensais que tu étais au courant.
Elle n'a pas ete discutee. Il y a une ebauche de debat. Puis avant que le debat commence, vous sortez the new Tigcc avec CALCULATOR a 0....

>Notre incapacité à communiquer et à discuter???


>Je n'ai appris de ton intention de mettre CALCULATOR==-1 que par pur hasard, en parlant de complètement autre chose,
Tu crois encore au hazard

>et ce n'était que bien après que la décision de TIGCC avait été prise. Il était trop tard de changer, et de toute façon, même au départ,
> on n'avait pas le choix pour les raisons de compatibilité source évoquées.
Trop gros pour moi. Je ne mords pas.

> C'est aussi pour ça que je ne t'ai pas contacté pour te demander ton avis:
> je savais qu'on n'avait pas le choix pour TIGCC quoi qui se passe et je pensais donc même qu'il était évident que CALCULATOR allait valoir
>0 sur Titanium, j'ai été évitré quand j'ai appris que tu allais mettre -1.
Ben c'est une nouvelle calculatrice. Donc un nouvelle valeur pour CALCULATOR.

>Bah, et nous on se fout de ce que tu fais maintenant...
C'etait pas le cas avant ?

>De toute façon, pour nous, le flag Titanium n'existe pas (pour nous, la Titanium est une TI-89), donc ce sera couvert par ton système
>"lie about CALCULATOR" que tu appelles prétentieusement "émulation". Tant pis si PreOs ruine les programmes en les patchant,
>la solution sera "utilisez Iceberg qui ne patche pas les programmes sans vous demander votre avis".
Ben si Tigcc est pas foutu de faire des Kernel Programs pour Titanium, c'est son probleme. Pas le mien.

>Je peux aussi faire un Iceberg 2.00 basé sur PreOs 0.70,


> mais en supprimant ou réversant tous les changements néfastes que tu y as apportés (autopatcheur, flag Titanium, CALCULATOR==-1, peut-être aussi le RAM_CALL GHOST_SPACE qui ne devrait vraiment pas exister, peut-être même les RAM_CALLs de TSRs)
Du moment que tu es propre a ce niveau la, pas de probleme (ie ne remplace la signification d'une RAM_CALL par une autre).

>et rajoutant à nouveau les changements de Iceberg 1.00 (sauvegarde de l'écran, compatibilité TitaniK,
Ok.

>correction du stack leak dans l'anticrash _nostub dont je me suis plaint il y a des années et que tu as refusé de corriger,
?? Tu veux dire les 4 octets de moins dans l'user stack ?? Je t'ai explique pourquoi je le laissait, et tu avais l'air d'etre d'accord.

>méthode propre de gérer le problème des fontes, en prenant compte du derelogement contrairement à ton autopatchage foireux)
Ca prend de la place. Mais c'est sur que ca serait mieux.

>et peut-être d'autres (meilleur anticrash pour les programmes _nostub, ...).
Dur dur.

>Bah si, tu t'es foutu complètement de ce qu'a fait Iceberg pour CALCULATOR.
Ben non. Il supporte pas le flag, donc pas de probleme.

><SARCASM>Très intelligent.</SARCASM> Sous quels termes veux-tu qu'on discute encore avec toi si tu nous parles comme ça?
A coup de Troll ? Pourquoi cette question ?

> Et penses-tu vraiment que ce soit bien pour la communauté si le principal kernel (enfin, peut-être plus longtemps si je fais Iceberg 2.00 ) est en conflit avec le principal outil de développement???
Ca mettra un peu de piquant.

> Pourquoi ne peux-tu pas discuter avec nous avant de changer des valeurs en commun entre nos projets comme CALCULATOR?!
Parce que vous n'ecoutez pas

>Exprès de ne pas nous notifier à temps??? Ou alors tu veux dire "exprès de nous notifier"?
>Mais alors le problème était que c'était beaucoup trop tard pour changer quoi que ce soit dans TIGCC!
>Il aurait fallu y penser avant. (Et en plus, il y a aussi le problème de compatibilité source dont je parle plus haut.)
Oui. Mais moi je l'ai appris apres la release de TIGCC. Pas avant. Je suis pas aussi vache que vous.


>> Rappelle moi la valeur de hardwareID sur Titanium ?
>gateArray==3. C'est la valeur testée par AMS quand on lui demande la version matérielle, donc c'est ça que doit contenir HW_VERSION.
Tu confondrais pas gateArray et HardwareID ?

>"Faire l'idiot"??? Tu deviens de plus en plus arrogant et insolent!
Ben c'est un Troll

>Pourquoi veux tu pouvoir faire un if (TI89_TITANIUM)?
>a. Touches, écrans? -> Pas besoin, la TI-89 est identique.
>b. Protection, ghost spaces, USB, matériel horloge? -> C'est lié à HW_VERSION.
Parce que c'est une nouvelle calculatrice.

>Cette méthode de lecture de claviers est la plus sale qui existe!
Mais non.

> Tu vas fouiller directement dans les variables globales privées de AMS au lieu d'appeler les ROM_CALLs faits pour.
Oui et ? Vous faites pareil

> Beurk! Voilà exactement pourquoi je trouve que le système de RAM_CALLs des kernels est néfaste, il encourage ce genre de programmation sale en mettant ces variables privées à disposition des programmes.
Ca marche.

>"Has Been", "Has Been", "Has Been", tu n'en as pas d'autres?
>C'est surtout PreOs qui sera "Has Been" si je sors Iceberg 2.00.
Oue Preos 0.70 sera Has Been par un kernel qui ne fait que reprendre ces sources



>Vous devriez vous mettre d'accord, et éviter de mettre volontairement des incompatibilités les uns envers les autres par pur esprit
>d' "incommunicabilité" ou de contradiction.... Franchement ce serait cool d'avoir un bon kernel compatible avec toutes les TI, et sur lequel on peut
> programmer avec TI-GCC sans utiliser des programmes auxiliaires...
Ben c'est deja le cas. TI-GCC + kernel.h

>Mais je pense que TIGCC et son linker devraient prendre en compte le kernel.h de PhHd,
Alors la ca risque pas

>et accepter que preOS reste le kernel principal, titanik et iceberg ayant été, je crois, faits seulement pour la titanium, non?
Je ne suis pas contre un autre kernel.

>Je pense que PpHd devrait accepter les problèmes de compatibilité de preOS (graphlib, CALCULATOR)
Le probleme de graphlib est un faux probleme: Pour faire marcher SMQ et mario92 avec Titanick, Kevin a du les patcher. Il a aussi du recompiler graphlib en modifiant le systeme de bank switching (ie ne pas recopier tout l'ecran) car une partie de l'ecran sert comme tranpoline pour faire la communication inter-libraries. Preos 0.70 fait fonctionner SMQ et Mario92 directement. Pour faire fonctionner les versions patchers, il suffit d'utiliser graphlib fournit avec Titanick. Elle marche parfaitement avec PreOS 0.70.
Au sujet de CALCULATOR, y'a pas de probleme puisque Iceberg et Titanik ne gere pas le nouveau flag.

> Quand je le dis, ça parait tellement simple... Mais je sais qu'il n'est pas facile de s'entendre.. Mais je voudrais bien que ces disputent cessent...
C'est pas une dispute. C'est un Troll.


> J'avoue que je ne comprends pas trop pourquoi PpHd a choisi -1 comme valeur de CALCULATOR pour TI-89 Titanium
Parce que c'est le plus rapide a patcher.
Une valuer > 4 aurait pose de gros problemes dans les programmes assembleurs.
Tandis que que -1 permet de faire migrer un code:
tst.b CALCULATOR
bne.s \92p
en
tst.b CALCULATOR
bge.s \92p
Simplement. Il suffit de faire un grep CALCULATOR, puis mettre a jour ces branchements pour que ca marche.
Et puis c'est loin d'etre le plus dur (Y'a aussi le ghost space).


>c'est qu'aucun des aspects de la calc n'a été séparé de CALCULATOR et que si une nouvelle calc apparaissait, il n'y avait aucun moyen de savoir
>quelles propriétés elle avait : il aurait fallu définir des pseudo-constantes SCREEN89, KEYBOARD89, ROMADDR89, etc...
Tu devrais relire les ramcalls. SCREEN89 et ROMADDR89 existent.

>Au pire, même si un programme supposait effectivement que l'écran a une résolution de 89 ou de 92 et que la TI-95 sortait avec un écran
>de 256 pixels de haut, il aurait suffi de voir où SCREEN89 était utilisé...
Mais aucun programme n'est fait pour.

>C'est vrai pour Iceberg 1.00, mais je compte faire un Iceberg 2.00 compatible tous modèles dans les semaines qui viennent.
J'attend avec impatience

>Donc je devrais accepter PreOs comme le monopole?
Le monopole, c'est mal

> Il y a toujours eu une multitude de kernels compatibles entre eux dans l'histoire des TI-89/92+/V200, je ne vois pas pourquoi ça devrait changer maintenant.
Tout a fait d'accord.

> Et je ne vois pas non plus pourquoi PpHd se permet de rajouter des trucs sans me demander mon avis,
Je te l'ai demande...

>pourquoi en tant qu'auteur de Iceberg (et co-auteur de PreOs, même, d'ailleurs!) je serais moins important que les auteurs de DoorsOS, TeOS et Universal OS auxquels il a demandé leur avis (même si c'était juste pour avoir la confirmation qu'ils s'en foutent et qu'ils lui donnent carte blanche)?
Ben ton avis importe. Mais moins que le mien.

>Dites-donc, vous avez lu au moins la doc pour savoir de quoi je parle, tous les deux? GHOST_SPACE est un RAM_CALL visé
>à permettre de continuer ce hack affreux:
>move.l foo,GHOST_SPACE+0x64
>au lieu d'utiliser la méthode propre:
>bclr.b #2,0x600001
>move.l foo,0x64
>bset.b #2,0x600001
Rien ne dit que la seconde methode soit plus sure a l'avenir que la premiere...
Il aurait fallu faire un InstallVector. Mais c'est assez orthogonal a un GHOST_SPACE.

>En plus, avec le relogement du RAM_CALL, ce n'est même plus intéressant en taille, c'est juste un hack qui ne sert strictement à rien.
Le but n'est pas d'etre interressant en taille.

>Et évidemment, PpHd utilise ça dans la graphlib de PreOs 0.70 au lieu d'utiliser la méthode propre comme je l'ai fait dans Iceberg.
Plus rapide a modifier.

>Je voudrais bien, mais je ne peux pas empêcher aux utilisateurs de l'avoir, et des programmes qui plantent sous quelles conditions que ce soit ne sont
>pas acceptables pour TIGCC.
Dites. Si vous pouvez aussi les faire marcher sous PlusShell 0.9, ca serait bien. Ou DoorsOS 1.00

>S'il y avait un moyen fiable de détecter un kernel dépassé comme on le fait pour les AMS dépassés, ça se discuterait, mais là, on ne peut rien faire à part ne pas utiliser le RAM_CALL si on ne veut pas que ça plante.
Qu'est-ce que tu proposes ?



>est-ce que ce n'est pas ce "hack affreux" qui a été utilisé dans TIGCC pdt pas mal de temps, contrairement à ce que certains conseillaient, et qui a causé des problèmes d'incompatibilité, justement ?
Ben oui.


>Je ne vois toujours pas l'intérêt d'un Iceberg 2.00, à part faire emmerder tout le monde en faisant deux kernels incompatibles entre eux
>(enfin, faire une version light et sans toutes les fonctions et une version complète).
>Enfin, si on m'avait dit qu'un jour tu te mettrais à programmer des kernels, j'avoue que je ne l'aurais sûrement pas cru
C'est ca le plus fort dans l'histoire

>n'empêche qu'il reste le kernel le plus utilisé
Ca n'est pas une raison.

>Et tu veux arranger les choses en faisant un kernel incompatible avec PreOS 0.70 ?
Nan juste sans les nouvelles ramcalls.


>Et en plus, même lui documente même GHOST_SPACE comme "deprecated". Je ne comprends pas pourquoi il rajoute un nouveau RAM_CALL
> s'il est "deprecated" dès le départ! Ni pourquoi il utilise un RAM_CALL "deprecated" dans sa graphlib, d'ailleurs.
Parce que c'est plus rapide pour porter les programmes mais que ca reste pas top


>Quel est l'avantage d'utiliser une section BSS plutôt qu'un handle en mémoire?
Pas de gestion de l'allocation / desallocation. Puis le segment est mis a 0 automatiquement aussi.

PpHd :
> J'avoue que je ne comprends pas trop pourquoi PpHd a choisi -1 comme valeur de CALCULATOR pour TI-89 Titanium
Parce que c'est le plus rapide a patcher.
Une valuer > 4 aurait pose de gros problemes dans les programmes assembleurs.
Tandis que que -1 permet de faire migrer un code:
tst.b CALCULATOR
bne.s \92p
en
tst.b CALCULATOR
bge.s \92p Simplement. Il suffit de faire un grep CALCULATOR, puis mettre a jour ces branchements pour que ca marche.

Mais si tu as my_table[CALCULATOR], ou si tu as (my_calc=CALCULATOR, my_calc?x:y) ? Ca doit poser plus de pb d'avoir un CALCULATOR différent, surtout que c pas seulement un pb qu'il faudra patcher au runtime, c un pb qui va passer silencieusement à la recompilation...

Franchement, je comprends pas l'intérêt PRATIQUE de séparer CALCULATOR entre 89 et 89t

Et puis c'est loin d'etre le plus dur (Y'a aussi le ghost space).

Oui, mais pas mal de prog ne doivent pas s'en servir (ou alors seulement via TIGCC)

>c'est qu'aucun des aspects de la calc n'a été séparé de CALCULATOR et que si une nouvelle calc apparaissait, il n'y avait aucun moyen de savoir
>quelles propriétés elle avait : il aurait fallu définir des pseudo-constantes SCREEN89, KEYBOARD89, ROMADDR89, etc... Tu devrais relire les ramcalls. SCREEN89 et ROMADDR89 existent.

On attend tjs un header qui permette d'utiliser les ramcalls tout en utilisant tigcclib

>Au pire, même si un programme supposait effectivement que l'écran a une résolution de 89 ou de 92 et que la TI-95 sortait avec un écran
>de 256 pixels de haut, il aurait suffi de voir où SCREEN89 était utilisé...
Mais aucun programme n'est fait pour.

Non, je ne parle pas de patch automatique, je parle de mise à jour manuelle...

PpHd, finalement, comment tu vas gérer ceux qui font "CALCULATOR ? a : b" ? En patchant les programmes comme tu l'a montré au ./594?
A ce moment-là ça te fait CALCULATOR>0 pour les 92p, et <=0 pour les 89 ?
Intelligent, je n'y avais pas pensé...

Edit:Cross avec Pollux...

>Mais si tu as my_table[CALCULATOR], ou si tu as (my_calc=CALCULATOR, my_calc?x:y) ?
Ben c'est au developpeur de le porter. Pas dur du tout.

> Ca doit poser plus de pb d'avoir un CALCULATOR différent, surtout que c pas seulement un pb qu'il faudra patcher au runtime, c un pb qui va passer silencieusement à la recompilation...
La responsabilite du developpeur.

>Franchement, je comprends pas l'intérêt PRATIQUE de séparer CALCULATOR entre 89 et 89t
Ben c'est une autre calculatrice.

>Oui, mais pas mal de prog ne doivent pas s'en servir (ou alors seulement via TIGCC)
Tu sais que la plupart des progs kernels sont en ASM ?

>On attend tjs un header qui permette d'utiliser les ramcalls tout en utilisant tigcclib
Alors que Tigcclib evite de foutre la merde avec les ramcalls, et je pourrais m'inclure proprement.

PpHd :
>Mais si tu as my_table[CALCULATOR], ou si tu as (my_calc=CALCULATOR, my_calc?x:y) ?
Ben c'est au developpeur de le porter. Pas dur du tout.

> Ca doit poser plus de pb d'avoir un CALCULATOR différent, surtout que c pas seulement un pb qu'il faudra patcher au runtime, c un pb qui va passer silencieusement à la recompilation...
La responsabilite du developpeur.

>Franchement, je comprends pas l'intérêt PRATIQUE de séparer CALCULATOR entre 89 et 89t
Ben c'est une autre calculatrice.

Ben moi ça me semblerait plus logique de prendre la même valeur que sur 89, et ça éviterait de se prendre la tête pour un chgt inutile...

>On attend tjs un header qui permette d'utiliser les ramcalls tout en utilisant tigcclib Alors que Tigcclib evite de foutre la merde avec les ramcalls, et je pourrais m'inclure proprement.

C quoi déjà le pb ?

>Ben moi ça me semblerait plus logique de prendre la même valeur que sur 89, et ça éviterait de se prendre la tête pour un chgt inutile...
Ben c'est ton point de vue. Mais helas le debat a ete clos avant de commencer. Donc ca sert a rien.

>C quoi déjà le pb ?
Leur maniere de definir les ramcalls.