Je me demande si nitro me connaît vraiment et sait vraiment ce que je fais...
> Super ! et tu te prends pour qui pour avoir l'audace de dicter à tous les programmeurs de la communauté ce qu'ils doivent faire ou ne pas faire ? Le maitre du monde ?
Kevin a déjà répondu.
> Depuis le commencement de l'assembleur sur TI des gens bien plus doués que toi ont toujours employé des méthodes "non standard" pour exploiter au mieux les capacités des machines.
D'une, j'ai déjà dit que je n'étais pas le programmeur le plus doué. De deux, moi aussi j'emploie des méthodes "non standard" pour exploiter au mieux les capacités des machines... Qui a fait au moins une dizaine de wrappers pour que des fonctions qui sont dans la jump table seulement sous AMS 2.xx, marchent aussi sous AMS 1.xx (j'ai dit AMS, les hacks sont sûrs sous AMS; la protection anti-OS non officiel sera obligatoire si on veut utiliser ces hacks normalement) ? C'est sûrement nitro, le plus grand programmeur de tous les temps la communauté TI...
Exploiter au mieux les capacités des machines: exploitons d'abord au maximum AMS, ce qui n'est pas fait, et ce que je contribue à faire, cf plus bas.
> Si tu es trop borné pour te rendre compte que AMS c'est pas le saint-graal, laisse faire les autres... eux au moins ils savent ce que c'est qu'innover.
Je suis presque prêt à parier que je connais des horreurs d'AMS au niveau du code que tu ne connais pas (une séquence de cinq instructions dont trois sont inutiles, du code horrible quand on travaille à travers un pointeur vers une structure, lui-même imbriqué dans une structure).
J'ai découvert des dizaines de ROM_CALLs qui n'avaient même pas de nom (et certains n'en ont toujours pas)... Alors pour le fait que je ne sache pas ce que c'est qu'innover, tu repasseras. C'est plutôt toi, kerneleux et pro-PedroM, qui ne sais pas ce qu'est innover: croire en un système dont les fonctions exportées sont dépassées depuis plus de quatre ans ne me paraît pas être "savoir ce que c'est qu'innover"...
> Et je te ferais remarquer que tigcc lui-même utilise de nombreux hacks non standard.
Vas-y, cite-les tous. On attend...
Et aurais-tu malencontreusement par le plus grand des hasard oublié que les kernels font plus de hacks plus sales que ceux de TIGCC, PpHd le sait très bien ?
> Donc selon toi, on devrait utiliser tigcc pour faire des programmes pour PedroM, et TIFS (le compilateur standard) pour AMS. Bref, n'importe quoi.
Arrête ton délire. Je me doute d'où tu extrapoles ça, mais c'est du n'importe quoi de ta part.
Utiliser TIGCC pour faire des programmes pour PedroM, pourquoi pas ? Utiliser #define UNOFFICIAL_OS_SUPPORT devrait suffire. Mais vive les fonctions non disponibles pour cause de a) obsolescence et incomplétion de la jump table et b) non- ou mauvaise réimplémentation des fonctions d'AMS qui empêche les hacks de fonctionner...
Utiliser TIFS, le compilateur standard, pour AMS, est ce que fait TI. Ca n'est pas une réussite, ce que j'ai déjà dit à de nombreuses reprises. Il est fort possible qu'ils ne puissent pas changer de compilateur ou changer le compilateur, par contrat. C'est bien dommage... Il est trivial d'nlever des KB à AMS juste en supprimant les plus grosses stupidités dans l'optimisation (doubles/triples swaps, branchements stupides) et les instructions inutiles.
© XDanger 
) tout vos Hack tomberon a l'eau.. Deja que pour certain truc si on veux faire du compatible tout AMS on est obligé de se trainer 2x plus de code avec 1 pour ams1 et l'autre pour ams2, autent interdire directement certaines fonctions sous ams 1 comme sa c'est plus simple et surtout beaucou plus propre !!!
