encore une chtite question - Page 18

 include "tios.h"
 
 jsr kernel::ExtractFile

Et lire la doc de RAMCALLS.txt
Evidement que si c'est une variable on ne fait pas de jsr dessus

ma méthode n'est pas propre, stou. Le code assemblé sera identique, mais c'est plus lisible d'écrire jsr kernel::LibExec que jsr _RAM_CALL_014 (les noms et valeurs sont au pif)

Euh si c'est de Ibrahim, ça doit dater

apparemment, de 2001
http://perso.wanadoo.fr/scherrer/ben/

Au contraire, nous conseillons d'utiliser le doorsos.h fourni avec TIGCC qui marche très bien. (Tu remarqueras que j'ai changé les libs que j'ai recompilées pour Iceberg pour l'utiliser.)

Bah, si tu veux avoir un truc intégré proprement à TIGCC et qui ne déclare que les RAM_CALLs compatibles avec tous les kernels de la génération AMS 2 (DoorsOS II, TeOS, Universal OS, PreOs, Iceberg), utilise notre doorsos.h qui est dans le répertoire Include fourni. Si tu veux utiliser tous les RAM_CALLs de PreOs au dépens de la compatibilité avec les kernels moins récents, débrouille-toi pour intégrer le fichier de PpHd à TIGCC. Tu devras t'arranger pour l'intégration du fichier (soit le copier dans notre répertoire Include, ce que je juge un hack grossier et sale, vu que ce n'est pas un header de TIGCC, soit le rajouter à tous tes projets, ce qui est lourd) et pour la compatibilité avec notre linker (par exemple, le linker de PpHd donne des noms aux flags kernel, le nôtre des numéros). (Soit dit au passant que MakePrgm n'est même pas un vrai linker, mais un hack pour convertir AmigaOS->AMS qui ne connaît même pas le format COFF et est complètement incapable de linker plus d'un fichier objet à la fois, pris directement du kernel obsolète PlusShell. Il ne gère donc pas les librairies statiques non plus, et il lui manque pas mal d'autres fonctionnalités de ld-tigcc. Donc utiliser le "linker" de PpHd avec TIGCC n'est pas une option.)

Martial Demolins > c'est simple : le pro du kernel, ça reste PpHd, donc c'est sûrement lui qui sait mieux comment programmer en kernel ^^

l'IDE, tu peux l'utiliser, pour le reste je sais pas, perso je l'a inclu à mon projet (c'est le seul fichier externe, je n'utilise rien d'autre comme fichier .h)

ou de ne pas distribuer ses sources

j'ai pas mis à jour, maintenant j'ai qqes centaines de Go en plus et je ne dl rien pour le proc, j'avais hésité mais mon P4 suffit pour tigcc

(et je distribue pas toutes mes sources )

oué, j'ai des copaines qui rippent/dl à ma place ^^ cher en courant ? tu veux dire en électricité ? je paie pas

bn

Martial Demolins
: Tu es le premier à dire AMS 2.0x et inférieurs

/s/2/1/

sont obsolètes, donc utilisons les nouveaux ROM_CALLs, les autres ont qu'à upgrader, etc... Il en va de même pour les kernel, je ne vais pas programmer pour être compaptible avec la génération plusshell et compagnie.

Je ne parle pas de PlusShell et DoorsOS I, mais de DoorsOS II, TeOS et Universal OS. Et ces kernels ne peuvent pas être mis à jour parce qu'il n'y a pas de version plus récente.

PreOs sort avec des fonctionnalités nouvelles, autant les utiliser, sinon ce n'est pas la peine que PpHd se donne du mal à développer et améliorer.

Ben justement, il ne devrait pas.
Mon avis personnel: De toute façon, c'est une erreur de programmer kernel de nos jours, les kernels ne devraient servir plus que pour faire tourner de vieux programmes.

ou avec un bon IDE, mais qui ne me permet pas de preogrammer en kernel...

Tu peux programmer kernel, c'est juste que nous nous soucions de la compatibilité contrairement à PpHd qui n'en a rien à f**tre (cf. aussi sa graphlib incompatible avec les programmes TitaniK).

>Mais mets-toi à ma place, Kevin, deux 'pros' me donnent deux conseils différents, lequel suis-je sensé suivre ?
Le mien. Kevin est outdated. Tu te rends compte ? doorsos.h ? C'est depasse ce header.

>Bah, si tu veux avoir un truc intégré proprement à TIGCC et qui ne déclare que les RAM_CALLs compatibles avec tous les kernels de la génération AMS 2 (DoorsOS II, TeOS, Universal OS, PreOs, Iceberg), utilise notre doorsos.h qui est dans le répertoire Include fourni.
Quel interet ? Il vaut mieux tout definir. L'utilisateur sait parfaitement a partir de quel kernel les ramcalls existent. C'est dans la doc.

>Si tu veux utiliser tous les RAM_CALLs de PreOs au dépens de la compatibilité avec les kernels moins récents, débrouille-toi pour intégrer le fichier de PpHd à TIGCC.
Tu te rends compte ? Copier tios.h dans include/asm ! Trop dur. Il faut un Phd pour le faire

>Tu devras t'arranger pour l'intégration du fichier (soit le copier dans notre répertoire Include, ce que je juge un hack grossier et sale, vu que ce n'est pas un header de TIGCC, soit le rajouter à tous tes projets, ce qui est lourd)
Un hack ? Tu en as d'autres ?
De toute facon, perso j'ai enleve tous vos headers obsoletes et depasses. Meme dans include/c.

> et pour la compatibilité avec notre linker (par exemple, le linker de PpHd donne des noms aux flags kernel, le nôtre des numéros). (Soit dit au passant que MakePrgm n'est même pas un vrai linker, mais un hack pour convertir AmigaOS->AMS qui ne connaît même pas le format COFF et est complètement incapable de linker plus d'un fichier objet à la fois, pris directement du kernel obsolète PlusShell. Il ne gère donc pas les librairies statiques non plus, et il lui manque pas mal d'autres fonctionnalités de ld-tigcc. Donc utiliser le "linker" de PpHd avec TIGCC n'est pas une option.)
Depuis quand makeprgm est un linkeur ? C'est juste un convertisser, et ca n'a pas d'autres but que de convertir un fichier objet Amiga OS en fichier .89z/.9xz ou .v2z...

>Tu es le premier à dire AMS 2.0x et inférieurs sont obsolètes, donc utilisons les nouveaux ROM_CALLs, les autres ont qu'à upgrader, etc...
Non. Il vaut mieux etre compatible toutes AMS. Perso je trouve pas AMS 1.0x obsolete.

>Il en va de même pour les kernel, je ne vais pas programmer pour être compaptible avec la génération plusshell et compagnie. PreOs sort avec des fonctionnalités nouvelles, autant les utiliser, sinon ce n'est pas la peine que PpHd se donne du mal à développer et améliorer.
100% d'accord.

>Maintenant pour ce qui est de la compatibilité de TIGCC et de PreOs, je mets sans scrupule le header de PpHd dans votre \include, ceux qui ne sont pas contents n'ont qu'à faire des progs qui ont un minimum de compatibilité entre eux.


>Faire des gros projets assez aboutis, c'est très bien, félicitations. Mais je suis bien embêté avec toutes vos histoires.
Bah en assembleur il n'y a aucun probleme de compatibilite. En C, c'est autre chose.

>oui, mais après ce que dis Kevin, je ne sais plus si je peux utiliser l'IDE, le linker, les libs statiques (les miennes, qui sont pas grosses), tout en programmant en kernel avec tios.h
Y'a aucun probleme.

>Je ne parle pas de PlusShell et DoorsOS I, mais de DoorsOS II, TeOS et Universal OS. Et ces kernels ne peuvent pas être mis à jour parce qu'il n'y a pas de version plus récente.
Les sources de PlusShell, DoorsOS II et Teos sont disponibles. Qu'attends-tu pour les mettre a jour ?

>Mon avis personnel: De toute façon, c'est une erreur de programmer kernel de nos jours, les kernels ne devraient servir plus que pour faire tourner de vieux programmes.
Le kernel c'est l'avenir ? Regarde la Titanium : aucune recompilation et ca marche directement. Juste mettre le kernel a jour, et pouf ca roule. Du point de vue du programmeur, c'est bien plus sur (pas besoin de resortir une nouvelle version), et utilisateur, c'est bien plus convivial.

>Tu peux programmer kernel, c'est juste que nous nous soucions de la compatibilité contrairement à PpHd qui n'en a rien à f**tre.
Je me preoccupe de la compatibilite bien plus que vous !
Mais si vous voulez etre Has been, c'est votre probleme.

> (cf. aussi sa graphlib incompatible avec les programmes TitaniK).
Avec les 2 programmes Titanik qui n'ont aucun lieux d'etre.

PpHd :
>Si tu veux utiliser tous les RAM_CALLs de PreOs au dépens de la compatibilité avec les kernels moins récents, débrouille-toi pour intégrer le fichier de PpHd à TIGCC.
Tu te rends compte ? Copier tios.h dans include/asm ! Trop dur. Il faut un Phd pour le faire

Et l'histoire des flags linker que tu définis dans ton header et qui ne sont pas les bons pour notre linker? Je compte au moins:

_ti89ti

N'existe pas dans notre linker. Pour avoir ton flag inutile, c'est:
_flag_6: xdef _flag_6
Sinon, ben _ti89ti == _ti89.

_mistub

N'existe pas sous TIGCC.

_readonly

C'est _flag_3 sous TIGCC.

_install_preos

N'existe pas sous TIGCC.

De toute facon, perso j'ai enleve tous vos headers obsoletes et depasses. Meme dans include/c.

<SARCASM>Merci de traîter TIGCCLIB en entier d'"obsolète et dépassé", c'est très sympa pour Zeljko et tous les autres (y compris moi) qui ont travaillé dessus.</SARCASM>

Depuis quand makeprgm est un linkeur ? C'est juste un convertisser, et ca n'a pas d'autres but que de convertir un fichier objet Amiga OS en fichier .89z/.9xz ou .v2z...

C'est bien ce que je lui reproche.

>Tu es le premier à dire AMS 2.0x et inférieurs sont obsolètes, donc utilisons les nouveaux ROM_CALLs, les autres ont qu'à upgrader, etc... Non. Il vaut mieux etre compatible toutes AMS. Perso je trouve pas AMS 1.0x obsolete.

Bizarre. Et pourtant AMS 1 est dépassé depuis nettement plus longtemps que les kernels que tu veux jeter. AMS 2.03: décembre 1999. PreOs 0.54: février 2002. Il y a plus de 2 ans de différence.

>Je ne parle pas de PlusShell et DoorsOS I, mais de DoorsOS II, TeOS et Universal OS. Et ces kernels ne peuvent pas être mis à jour parce qu'il n'y a pas de version plus récente.
Les sources de PlusShell, DoorsOS II et Teos sont disponibles. Qu'attends-tu pour les mettre a jour ?

J'ai autre chose à faire. Et puis pour moi, "mettre à jour" != "rajouter les RAM_CALLs que tu as rajoutés au format sans demander rien à personne". Le format kernel aurait dû être freezé après DoorsOS II. Tous tes ajouts ne créent que des problèmes de compatibilité.

>Mon avis personnel: De toute façon, c'est une erreur de programmer kernel de nos jours, les kernels ne devraient servir plus que pour faire tourner de vieux programmes. Le kernel c'est l'avenir ? Regarde la Titanium : aucune recompilation et ca marche directement.

Parce que tu patches les programmes sans rien demander à personne. Tu sais, je pourrais faire ça avec le _nostub aussi (trap 11 fonction 15). Si je ne fais pas d'autopatcheur (même dans Iceberg), c'est parce que je trouve que c'est une très mauvaise idée de patcher les programmes à chaque exécution. C'est beaucoup plus simple si l'utilisateur a le choix de patcher ses programmes si et quand il a envie, et GhostBuster fait ça très bien. (Au passage, ton autopatcheur rate pas mal des corrections faites par GhostBuster!)

>Tu peux programmer kernel, c'est juste que nous nous soucions de la compatibilité contrairement à PpHd qui n'en a rien à f**tre. Je me preoccupe de la compatibilite bien plus que vous !

Pfff... Arrête de raconter n'importe quoi... Tu as fait quoi pour la compatibilité? Rajouter des RAM_CALLs pour que les programmes ne tournent plus qu'avec PreOs? Sinon, je ne vois vraiment pas d'effort de compatibilité. Par exemples, tu te permets de donner une valeur négative à CALCULATOR sur Titanium alors que:
* CALCULATOR a toujours été documenté comme une valeur unsigned.
* CALCULATOR a été documenté comme valant 0 sur Titanium par TIGCC dès la sortie de la première bêta compatible Titanium.
* TitaniK et Iceberg suivent la convention de TIGCC.
Donc tu te fous complètement de ce que font les autres kernels et ce que documente TIGCC, tu donnes la valeur que tu veux sans rien demander à personne. Et quand j'ai eu la nouvelle (un peu par hasard, comme d'habitude chez toi), je t'ai même dit explicitement bien avant la sortie de PreOs 0.70 de ne pas le faire, tu l'as fait quand-même. Pour distinguer une Titanium d'une 89 normale, c'est simple, HW_VERSION est là exactement pour ça! Et utiliser HW_VERSION plutôt que CALCULATOR pour détecter le HW3 est certainement une idée meilleure, parce que ça donne des programmes qui marcheront sur la V200 HW3 qui va sans doûte sortir à un moment. <SARCASM>Vive tes efforts de compatibilité!</SARCASM>

> (cf. aussi sa graphlib incompatible avec les programmes TitaniK).
Avec les 2 programmes Titanik qui n'ont aucun lieux d'etre.

C'est <SARCASM>génial</SARCASM>, tu n'aimes pas TitaniK, donc tu fais exprès de casser la compatibilité avec... Je dis bien que tu fais exprès. J'ai une version de graphlib qui tourne sur toutes les calculatrices et qui fait tourner les programmes TitaniK sur 89 normale et Titanium. Ça m'a pris moins d'une heure de la faire, donc ce n'est vraiment pas sorcier. Et si tu la veux, je peux te l'envoyer, et tu peux donc l'intégrer à PreOs 0.71 sans aucun effort. (Elle sera intégré dans la prochaîne release de Iceberg en tout cas.) Si tu refuses, c'est que tu fais vraiment exprès.

Le format kernel aurait dû être freezé après DoorsOS II. Tous tes ajouts ne créent que des problèmes de compatibilité.

les TI-68k auraient du être freezée après la TI-92 1. Toutes les nouvelles ne créent que des problèmes de compatibilité
Les AMS auraient du être freezés après la ROM1.00. Tous les ajouts dans les nouvelles ne créent que des problèmes de compatibilité

c'est exactement la même chose...
certes, il y a des problèmes de compatibilité ; mais il y a aussi de nouvelles fonctionnalités... TI a fait le choix de faire passer les fonctionnalités avant la compatibilité... pourquoi est-ce que PpHd ne le ferait pas lui aussi ?
(désolé pour le semi-HS)

De même, tigcc 0.95 n'est pas 100% compatible avec tigcc 0.94.