Les directives d'assemblage de A68k - Page 2

Une méthode qui fonctionne même sans le HW3Patch se trouve dans les sources de ma version du SIDE de nitro:
http://p079.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=178.topic
En gros, il faut:
* si on a redirigé des interruptions, traps etc., les remettre à leur valeur par défaut,
* utiliser mon code de lancement,
* remettre les interruptions, traps etc. redirigés quand le programme a retourné.
Le code de SIDE est sous GPL normalement, mais étant donné qu'il n'y a pas 10000 manières de contourner la protection de TI, j'accorde la permission d'utiliser le code de lancement (qui est de moi) dans un logiciel quelconque sous n'importe quelle licence, à condition que je sois crédité pour la routine.

Attention, le code tel quel ne marche que pour AMS 2, pour AMS 1 ou PedroM on peut utiliser une technique plus simple (donc il faut un if).

J'ai téléchargé le truc, je vais regarder. Merci !

(En revanche, si tu as des corrections ou améliorations à faire, j'apprécierais de les voir. )

C'est vraiment long et compliqué comme code. Pourquoi tu ne fais pas une fonction int launch(HANDLE exe_hdl) dans TIGCClib ?

Je vais peut-être le faire, mais il y aura une longue liste de trucs auxquels faire attention. Par exemple, USE_INTERNAL_FLINE_EMULATOR va créer des problèmes avec ce code (parce que si le programme appelé veut faire des appels F-Line, il va se heurter à la protection anti-exécution), sauf si je désinstalle le handler F-Line aussi à cet endroit.

Grâce à nos amis de chez TI, le lancement d'un bout de code à partir d'un autre est la chose la plus difficile qui soit sur les TI-68k

(Au passage, Thibaut: est-ce que tu comptes implémenter le super standard de commentaires AMS native, qu'on a défini vers 2002, mais que personne n'a jamais implémenté dans un quelconque explorateur de fichiers ?)

Ouai en plus c'était à l'époque où je développais Einstein que j'ai proposé ce standard.
Mais au final je ne l'ai pas implémenté, je ne sais plus pourquoi. La prochaine release d'Einstein inclura les sources, si y'en a qui ont le courage et l'envie d'ajouter ça, ils pourront.

Lionel Debroux (./38) :
(Au passage, Thibaut: est-ce que tu comptes implémenter le super standard de commentaires AMS native, qu'on a défini vers 2002, mais que personne n'a jamais implémenté dans un quelconque explorateur de fichiers ?)

Si, il y a 2 implémentations: un shell de Flanker, et un convertisseur que j'ai fait qui extrait les informations dans une base de données pour Integrated Desktop (cmmnt2id).

Je comprends pas tout dans la routine que Kevin propose (faut dire que j'ai pas beaucoup cherché) et de toute façon elle est énorme.
Pour lancer un programme en mode kernel, comment fait-on ?

Et pour rendre mon programme kernel, j'ai juste à rajouter #define USE_KERNEL c'est tout ?

Tu as vraiment envie de me faire ch**r, dis-donc!

Qu'est-ce que tu ne comprends pas dans mon code? Je peux t'expliquer. J'avoue que c'est assez compliqué, mais c'est la faute de TI! Et tu n'as pas forcément besoin de tout comprendre pour utiliser le code.

Sinon, tu peux aussi utiliser EXECUTE_IN_GHOST_SPACE, ça demandera le HW3Patch sur HW >=3, mais ça rend le lancement plus simple (il suffit de faire ASM_call(ptr+(HW_VERSION==2?0x40000:0)); dans ce cas). Mais j'aime bien le code portable, moi. L'intérêt de mon code "compliqué" est de marcher sans rien d'installé, ce que le kernel ne satisfait évidemment pas.

Kevin Kofler (./43) :
Tu as vraiment envie de me faire ch**r, dis-donc!

Hein ?
Kevin, c'est de ma faute si GTC se révèle meilleur que TIGCC sur 2 programmes testés pour la taille et 3 routines pour la vitesse ?
Et pourquoi ce serait pour te faire chier si je décidais de rendre Einstein dépendant d'un kernel (càd Qu'est-ce que tu peux en avoir à faire ?)

Enfin bref.

Thibaut (./44) :
Et pourquoi ce serait pour te faire chier si je décidais de rendre Einstein dépendant d'un kernel (càd Qu'est-ce que tu peux en avoir à faire ?)

Le kernel sux, et mon but est de faire en sorte qu'un utilisateur n'ait plus besoin d'en installer un, mais pour ça il faut que tous les programmes qu'il utilise soient en _nostub, c'est pour ça que je suis aussi intolérant sur ce sujet.

Et c'est plus simple que ASM_call(ptr+(HW_VERSION==2?0x40000:0)); (qui marche aussi en kernel) comment?

N'empêche, avec la multitude de patchs que TIGCC est obligé d'intégrer aux programmes nostub (afin qu'ils tournent sur toutes les versions d'HW), il devient de plus en plus désavantageux de programmer en nostub. D'ailleurs, le mot nostub ne veut plus rien dire, vu la taille du stub (certains diront "micro-kernel") qui est mis d'office dans chaque programme.

Thibaut (./48) :
D'ailleurs, le mot nostub ne veut plus rien dire

Appelle-le "TIGCC-native" alors, c'est comme ça que ld-tigcc appelle le "_nostub avec code de démarrage" en interne de toute façon.

Martial Demolins (./49) :
Je repense toujours à VTI designé pour HW1 AMS 1.xx qui tounre nickel (pas moins bien, il souffre de bugs depuis toujours) sur HW4 et AMS 3.10.

VTI n'est pas un logiciel pour calculatrice, je suppose que tu voulais dire autre chose.

Martial Demolins (./49) :
Et je vois pas pourquoi tu parles de la difficulter de taper "preos()" comparer à celle de ghostbuster...

GhostBuster n'est pas nécessaire si l'auteur fait son boulot et recompile son programme, ou alors permet aux autres de le faire en fournissant ses sources sous une licence adéquate (c'est à dire permettant au moins le portage aux nouveaux HW/AMS). C'est à cause des auteurs égoïstes qui traîtent la communauté comme une poubelle pour blobs binaires non maintenus que des logiciels comme GhostBuster ou V200ExeP sont nécessaires.

Quant à l'excuse des sources perdues, ça ne peut pas arriver si on sort les sources avec le programme.

Le fait est que, aujoud'hui, la majorité des programmes qu'on trouve sur les sites d'archives datent d'avant 2002. Ils nécessitent donc tous un patch.
Si TIGCC n'avait pas imposé le mode nostub mais qu'il avait promu une utilisation correcte des fonctionnalités des kernels, tous les programmes auraient été codés en mode kernel de façon propre et leur majorité n'aurait pas nécessité un quelconque patch.

Thibaut (./54) :
en mode kernel de façon propre

Bel oxymore! C'est qui qui a promu des hacks come tios::Heap ou tios::kb_vars? La plupart des programmes qui ne fonctionnent plus du tout sont kernel, par exemple ils utilisent des adresses codées en dur ou en qqch. comme LCD_MEM+offset pour kb_vars et co. parce que c'était ce qui se trouvait dans les headers kernel à l'époque. Et la "solution" des kernels plus récents a été de rajouter des RAM_CALLs pour ces adresses (donc du coup c'étaient les kernels qui cassaient régulièrement parce que les RAM_CALLs n'étaient pas corrects) au lieu d'encourager les programmeurs à utiliser les interfaces publiques (les ROM_CALLs) comme TIGCC l'a toujours fait (enfin, depuis TIGCCLIB)!

Vous auriez pû vous attaquer à ces problèmes au lieu de vous orienter vers un mode qui fait que la majorité des programmes ne fonctionnent plus sur les calculatrices du marché actuel et que ceux qui marchent nécessitent un patch ou ton TSR.

Bah, nous ne pouvions pas prévoir les changements matériels. Quand TI a annoncé une nouvelle calculatrice, nous avons fait notre possible (contacts avec des bêta-testeurs de TI etc.) pour faire en sorte que TIGCC gérait les nouveaux modèles encore avant leur sortie, pour que les programmeurs aient le temps de mettre à jour leurs logiciels. Certains l'ont fait, d'autres non, mais du coup ce n'est pas notre problème. Nous avons réagi aussi vite que possible, ce sont les développeurs de logiciels qui n'ont pas toujours fait leur boulot.

Désolé, mais les programmes qui étaient codés, compilés avant la sortie des nouveaux modèles, se trouvent définitivement incompatibles. En développant le principe du kernel et en effaçant ses défauts (RAM_CALLs par ex), vous n'auriez pas mené la communauté dans la situation actuelle

Votre choix a fait gagner TI : ils ont réussit à freiner l'utilisation de programmes sur leurs machines, protection après protection. Enfin bref. Je me tâte à compiler Einstein en mode kernel.

./55 > Kevin, revois ta definition d'oxymore (deux mots opposés d'affilés dans la phrase, exemple : une nuit blanche.)
Quoiqu'il en soit on t'en voudra pas trop

On peut aussi l'utiliser en sens large pour 2 expressions opposées, et c'est le cas là.