Code OS3.x avec Morphos/OS4, etc…
11 sujets de 1 à 11 (sur un total de 11)
-
salut,
Parfois, on demande un port d’un programme en C pour:
– AOS3 avec un materiel du programmeur morphos et/ou aos4
– AOS4 avec un materiel du programmer morphOS
– MorphOS avec un materiel du programmeur AOS4.
et on repond:
– je n’ai pas de compilateur AOS3 sur mon morphOS ???.
– Comment faire, je n’utilise que mon AOS4 ou morphOS ???
– autre exemple.
– ………….
Mes questions sont les suivantes:
– peut on, en C, faire un port pour toutes les machines amiga (classics, aos4, morphOS, aros) facilement avec juste un recompilation (au minimum) avec un programme non specifique ou gourmand en resource ????
– Si oui, merci de dire ici quoi installé sur un morphOS et AOS4 pour compiler un programme sur toutes les plateformes.
(sas, gcc, cubicIDE,……).
Je ne suis pas programmeur, mais il arrive que je demande un port et que l’on me reponds que l’on ne sais pas quoi faire/installer pour compiler en 68k avec un morphos ou AOS4.
Le mieux serait d’avoir sur aminet un compilateur 68k tout fonctionnel pour AOS4 et morphOS, AOS4 pour morphOS et MorphOS pour AOS4, idem pour AROS,etc….
bye
Ah … voila un sujet intéressant
Ce dont tu parles, c’est de la cross-compilation (compilation croisée), c’est à dire compiler pour une cible qui n’est pas celle avec laquelle tu compiles.
Je vois 2 solutions :
– utiliser un outil intégré comme cubicIDE qui doit être livré avec les outils de compilation nécessaire
– encore plus simple : utiliser le compilateur vbcc qui s’installe et s’utilise très facilement. Il faut cependant avec le NDK 3.x (le 3.9 était téléchargeable gratuitement).
Avec vbcc c’est facile, tu es sous OS4 ou MorphOS, tu ajoutes l’option +aos68k et ça génère du code Amiga 680×0. J’ai montré ça à Demoniak à l’Alchimie en adaptant son émulateur CPC.
Ensuite, il peut y avoir des options de compilation à changer ou des appels systèmes à remplacer pour 3.x car ils n’existent pas mais un portage requiert toujours quelques efforts.
Une recompilation d’un programme C sur MorphOS, OS4 et OS3.x doit se faire sans trop de problèmes. Pour AROS, je n’ai pas la compétence pour le dire. Je pense qu’il y a quelques « trucs » à connaître mais le but d’AROS est justement de pouvoir bénéficier des programmes Amiga par simple recompilation.
Salut,
oui, je parle de cross-compilation (une chose d’apprise ce jour). donc, facilement, pour du 68k, pour classics a aprtir de AOS4 et/ou MorphOS:
– CubicIDE
– vbcc+NDK3.9+aos68k
+ adaptations specifiques AOS3.x
– combien de temps (minutes, heurs, jours,…) ???
– Force-t-on le programmeur en lui disant d’utiliser vbcc (dois s’en servir toujours) ou c’est un plugins pour son programme de programmation habituel sur AOS4/MorphOS/Aros ???
Dans le cas de faire un port morphOS avec AOS4 ou l’inverse, s’est possible aussi ou faut il passer par AOS3+emulation ????
Desole pour toutes ses questions
je suis surpris que des programmeur comme chris young ou thomas igracki me disent ne pas savoir comment faire du 68k (ou vouloir). J’imagine qu’avec, vbcc, les exe se creent a la suite (aos4, morphOS, 68k) lorsque l’auteur est sur un projet pouvant tourner sur toutes plateformes.
Je me demande si les programmeurs amiga en general sont tous au courant de vbcc.
bye.
Tu as peut-être déjà vu ce thread (actuellement actif) :
http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=25668&forum=32
Je trouve intéressant de voir comment tokai souffre et doit modifier son source pour porter un truc aussi simple (deux lignes utiles ?).
Recompiler un logiciel peut être difficile et peut nécessiter des changement importants.
Premièrement, si tu utilise un Vbcc, tu n’as pas autant de lib dispo qu’avec GCC, il te faut donc les recompiler et les remettre à la sauce VBCC ce qui peut prendre du temps. De même certaine lib existent pour une machine mais pas pour les autres
Ensuite, si l’auteur de la source a inclu de l’assembleur dans son programme C alors là ça devient vraiment technique car il faut connaître l’assembleur 68K et le PPC.
De plus, même quand tout marche bien au niveau de la recompilation, le fait de passer du PPC au 68K peut engendrer un réel problème de vitesse du programme et dans ce cas l’accéleration du programme passe obligatoirement par une réécriture du ou d’une partie du programme en 68K.
A+
GTI
Salut,
Je vois que ce n’est pas aussi simple .
Y-a-t-il des conseils alors pour s’en sortir et realiser des versions AOS3/MORPHOS ou AOS3/AOS4 ????
(Programmes a utiliser, methode de programmation,….).
CubicIDE + vbcc+asm68k ne permet pas de faire du morphOS/AOS4/AOS3 sans difficultées majeures ???
merci de l’interet a ce thread ou le but final est e bien comprendre le niveau de dificultees lorsqu’un utilisateur lambda comme moi se permet de demander un port 68k d’un programme AOS4 ou morphOS
PS: qu’est ce que cela doit etre avec OWB ou le source ne vient pas du miga au depart (ou alors c’est mieux).
– tiens, est ce mieux de partir de sources linux, ou PC ou autres ???
En même temps, qu’il s’agisse d’un programme de 2 lignes ou de 100 lignes, il y aura toujours un minimum de bricoles à faire.
A titre de comparaison, la version MOS/68k de MysticView se recompile facilement sur OS4 moyennant quelques changements (ouverture/fermetures des interfaces, …). Après, ça dépend du type de programme, des fonctions en jeu, et de la clarté du code d’origine (celui de MV est plutôt clean).
Corto a écrit un guide pour faire du code portable sur les OS Amiga, mais je sais plus où c’est.
je suis désolé mais après avoir comparé les sources 50.1 et 50.5 je vois pas tellement où sont les « souffrances » dont tu parles. Enfin à mon sens rien de bien étonnant et auquel on ne s’attendrait pas d’un source devant être portable AOS3/AOS4/MOS/AROS juste quelques lignes avec des #ifdef au début pour lancer le bousin selon la plateforme (ensuite son code reste identique dans la partie utile)…
Peut-être que ceci n’a rien à voir avec le sujet principal, mais si tu jette un oeil sur mes deux zouaveries de la semaine dernière (usblist et showlib), j’expose comment rendre compatible un bout de code OS4 avec le KS1.1
Le fichier v31lib.h définit des équivalents de fonctions inexistantes dans les vieilles versions, puis au dernier moment on colle un #undef sur les fonctions à remplacer et on redéfinit la fonction par un simple #define.
Bon codage (ou portage, ou compilation)
Les « souffrances » sont dans ses posts
Après, bien sûr, si tu es habitué à foutre des defines partout dans chaque fichier et réécrire la moitié des fonctions pour les remapper vers d’autres et que tu trouves cela normal, alors oui il n’y a rien de bien étonnant.
Je ne dis pas que c’est normal, je dis juste que quand on veut faire un code portable sur plusieurs plateformes il y a des concessions à faire sur certaines de ses règles de bonne programmation
Concernant les defines pour remapper des fonctions, c’est le choix que lui a décidé de faire cela n’a rien d’obligatoire (au passage en général le point d’entrée d’un programme C c’est la fonction main(), utiliser toute autre chose constitue déjà une violation de la portabilité qui entrainera fatalement des problèmes au moment du passage soit à d’autres runtime C soit à d’autres plateformes, d’où les #defines)
11 sujets de 1 à 11 (sur un total de 11)
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › Code OS3.x avec Morphos/OS4, etc…