Re: La VCS et EmuTOS (was: Sécurité sur atari-forum.com)

Bonjour
tu es touchant de naïveté.
Commences déjà à porter ton logiciel en natif pour coldfire et tu auras déjà fait un bon pas, mais déjà là tu coinces depuis plus de 10 ans alors tu incrimines GCC tout cela parce que tu ne veux pas écouter lorsque je t'explique en gros les plus gros problèmes, tu es focus sur l'option -mshort mais ce n'est pas de loin le plus gros problème voir ce n'est pas un problème du tout je pense dans ton cas suffit de ne pas utiliser l'option car mintlib ne supporte plus correctement cette option, mais on en a besoin pour des cas super spéciaux quand tu fais du système mais pour un logiciel normal le soucis est si tu écris sans un code après si tu le passes en PureC celui-ci peut avoir des soucis, dans l'autre sens il n'y a pas de raison qu'il y ai des soucis sauf code foireux où cela marche par erreur (c'est possible) avec un dépassement de capacité soit écrit pour qu'il y ai un dépassement de capacité par simplification de code (perso j'utilise dans MyAES sur un unsigned char pour faire un buffer tournant sans test mais c'est du super tordu!). Après qu'est ce qu'il peut arriver quelques noms de routines dérangeantes (observé dans mint quand j'ai fait le port avec GCC 4, mais cela m'a pris 1 heure à corriger), des warnings en plus (beaucoup parfois), tiens un bug de GCC 2.95 lorsqu'une variable existe en locale et globale il utilisait par erreur la variable globale! Franchement côté compilateur pas grand chose mais il reste une chose et je te l'ai déjà dit, je me répète donc ce sont les librairies qui changent et là cela peut entraîner  de gros dysfonctionnement sans pour autant avoir de warning quelconque, le jours où je suis passé de l'ancienne gemlib à la nouvelle que j'avais corrigé, j'avoue qu'il m'a fallut près d'un mois acharné sur ma librairie gem pour arriver à restabiliser les programmes compilés avec et j'étais bien plus jeune! Je ne pense pas que mintlib te pose soucis (a voir), mais les autres oui (librairie mathématique, gem, quoi d'autre ?). Tiens comme je suis en bonté je vais te donner un truc qui pourrait t'aider, les libs que tu utilises ce ne sont que des archives, tu peux les désarchiver et les réarchiver au nouveau format, le risque c'est qu'il manque des choses pour linker, vaut mieux garder mintlib pense pas que cela fonctionne sans mais pour le reste peut être que cela passerait, pas sûr mais cela peut valoir le coup d'essayer.
Hier tu m'as envoyé un message en privé qui était une copie d'un message que tu as du envoyer à Emutos, très bien mais tu as repris un de tes messages où tu parlais de ta façon de penser que GCC n'était viable que jusque GCC 3, quand tu dis cela en fait tu passes pour quelqu'un qui n'y connaît pas grand choses, les choses ne sont pas si simple, on peut regretter depuis GCC 4 que le post processeur 68K est moins bon que les versions précédentes, mais l'optimisateur du code C est largement meilleur, l'un dans l'autre souvent malgré le soucis le code va plus vite avec GCC 4 que GCC 3, mais sur certaines parties de code il est franchement mauvais. LLVM pour le moment ne fait pas mieux, et il existe une version GCC 6.5 reprise dans le monde Amiga qui est a un post-processeur 68K qui permet de remédier au défaut du post pro officiel.
VBCC donne de bons résultats aussi en terme de code 68K mais n'est pas aussi bon que GCC pour l'optimisation de code et est ma fois assez lent, je ne te conseil pas de porter ton soft avec, si tu n'as déjà pas réussi avec autre chose, son utilisation n'est pas franchement facile et cela apporte bien d'autres incompatibilités.
Donc arrêtes de te bercer d'espoir, car passer au x86 c'est plusieurs cran au dessus même si tu avais Emutos. Je n'arrive pas à comprendre ton intérêt pour un processeur que tu as conspué tellement par le passé, pourquoi pas plutôt un ARM après tout Apple a sorti un très bon processeur certes difficile à utiliser je pense vu qu'Apple bloque autant que possible ses machines, mais il existe un début de fork de Emutos pour ARM, bon ces ARM sont tout aussi "dyslexiques" selon tes termes que les x86 mais bon cela existe
https://github.com/kelihlodversson/pTOS
OL

Salut,
 pascal écrit :

ton fameux projet magique de porter Aranym dessus le jour hypothétique ou tu auras une VCS n'a aucun sens. Tu vas booter sous un Linux quelconque, tu vas lancer Aranym (et même pas le compiler : c'est un PC, c'est déjà fait), puis lancer Eureka dessus, faire des tonnes de copies d'écran, et tu viendras nous expliquer que l'autocollant a boosté ton soft comme jamais.

 Ça n'est pas ce que l'on discutait ces derniers temps ici. Certes le
portage de ARAnyM sous AtariOS, et sa diffusion par le "store ATARI"
permettrait de lancer beaucoup de logiciels GEM. Le portage de Hatari
et sa diffusion sur le portail ATARI permettrait de lancer des jeux
et des démos.
 Mais ce dont on discutait, serait le portage de EmuTOS sur x86, d'où
il provient depuis Digital Research avec le GEM sur Amstrad PC1512 ...
 Si EmuTOS était natif sur ATARI VCS, et que l'on pouvait booter dessus,
cela permettrait de compiler des logiciels comme le mien, à partir des
sources en langage C (pour moi). On obtiendrait une plateforme, qui
permettrait de lancer des softs ATARI, bien plus rapide que ne l'est
ARAnyM, avec un code 68k qui est traduit à la volée, par le compilateur
JIT. C'est à dire que l'on pourrait porter les softs ATARI sur CPU x86.
 Tu vas me dire que ça aurait pu être fait depuis longtemps, non ? Sauf
que le PC du point de vue architectural est une auberge espagnole, et
que MS/Windows qui le supporte est une véritable usine à gaz logicielle.
 L'ATARI VCS a l'avantage d'être une architecture bien définie, et qui
permet de booter toutes sortes de systèmes, alors pourquoi pas EmuTOS ?
 Tu as enfin compris, Pascal ?