Feelin (sur GuruMed)
-
Ca plante en sortie ? Ca veux dire que ça marche sinon ? C’est déjà un début
Est-ce que ça plante quand tu quittes le prgramme, ou lorsque la bibliothèque est expurgée du système ? (je sais pas quel mot utiliser)Faut faire attention à la taille de la pile du shell. Ca a l’air con comme ça, mais quand j’ai fait le script SETUP tout à coup « prefs » plantait comme une merde à la sortie (justement !). Je me suis dis « diablerie !! qu’est ce que c’est que cette merde »… ben c’était la pile qui par défaut est de *seulement* 4ko. La pile de mon shell de développement est de 200Ko, parce que sinon vbcc me chie dessus
24ko c’est la même taille que pour 68k… étrange mais bon. Tu voudrais pas essayer de lancer « Feelin:Demos/MemoryTest » pour voir ? Si ça roule, c’est que ça vient pas de la bibliothèque…
@gofromiel & rusback:
hier soir, j’ai regardé un peu les sources (050517).
J’ai commencé à analyser le code pour voir les pb possibles, j’ai trafiqué donc les makefile’s puisque sur morphos le sdk c’est GCC et pas SAS/C. Finalement il manque aussi des trucs dans l’archive src comme les Tools/* (F_CreateLib par exemple). Mais je me demande si ça sert au final…
Autre chose à savoir: mon pauvre gofromiel, avec un make 3.76 tu veux aller où? bon en plus, celui de SAS/C et le vrai GNU 3.77 (où + je sais plus, moi j’ai en tout cas le 3.8 geek qui marche le mieux). La plus part des pbs de makefile sont dus à cela.
Bon voilà le taf à faire dans l’ordre (au moins pour le début) pour le port:
1) Refaire les makefiles pour tenir compte de make en 3.77 au moins. Le pb est le suivant: suivant certaine version de make, il faut utiliser des chemins POSIX ou AMIGA ! Avec le make du SDK Mos c’est POSIX, d’où le pb de rusback avec les histoires de ‘%’ dans les targets: les chemins (dans make.header) sont de la forme « Feelin:patati/patata », or cela doit être « /Feelin/patati/patata ».
Cela implique donc faire 2 fichiers différents: un pour GCC et un pour SAS/C (du faite de l’icompatibilité syntaxique des deux)
2) il faut (re)générer les ppcinlines, proto et lib avec cvinclude.pl.
Et faire un mix avec ce qui est déjà écrit pour les protos.
3) Feelin est certe maintenant écrit en C (sauf les Tools/* au passage !) mais il utilise fréquément le binding de variable sur registre: en claire les truc genre « int variable __asm(« a0″) » par exemple, pour affecter une variable à un registre du 68k.
Feelin utilise donc un systèm de Hook à l’instar de MUI 68k… c’est bad, bad, bad
(surtout pour du PPC).Donc:
a) soit on retombe dans une programmation aussi chiante que MUI avec des gate, STRAP code, etc… pour avoir une compatibilité entre classes 68k et PPC.
b) soit on vire tout ça et on fait un code pure natif PPC, incompatible avec la version 68k.
c) soit on trouve une meilleur solution que les hooks !
4) oulalala que de warnings (et encore juste avec le -Wall sur gcc) sur des trucs genre:
if (Bob = Alloc(sizeof(…)))
….
Gofromiel! voyons!!!!! 😮
la dessus, gcc va râler car il manque des parenthéses autour de l’affectation, et cette écriture facilite l’arrivé de bugs.
écrit plutôt cela, il y a moins de risques:
Bob = Alloc(sizeof(…));
if (Bob != NULL)
….
5) ré-écrire le code d’init de la lib car j’ai vu des trucs pas correct comme le signal Henes.
6) continuer l’investigation des pb potentiels.
Désolé mon gofromiel d’être aussi méchant sur ton code, mais il fallait un bon coup de MrPropre pour en faire un hit
/me qui aime bien le coup du semaphore qui s’appel « Henes »
Tu as un mail.
Oui, j’avais vu le nom du sémaphore. Tsss
HookEntry() est l’ami qui t’évite d’émutrapgater tes sources.
Mais les hooks c’est nul pour un truc censé être OO. :-p
@Yomgui Ralala, je crois que je vais pleurer !
M’enfin qu’est ce que c’est que tout ces trucs que je comprends rien ?
Où je trouve cette version 3.77 de make ? Pas sur Aminet en tout cas. Dans « Feelin:Tools/ » il y a un chti prog qui s’appelle F_Make. Il génére automatiquement les makefiles pour les classes à partir du fichier « Project.c » de la classe et du fichier « Feelin:Sources/make-class ». Du si c’est qu’une question de chemin, spa compliqué de modifier F_Make et de refaire les makefile des classes e.g. avec makeall.rexx
2) il faut (re)générer les ppcinlines, proto et lib avec cvinclude.pl.
Je ne sais pas de quoi tu me parles
Note: j’ai un milldeu et WinUAE. Je ne connais rien au monde étrange et fabuleux des autres « amigas ».3) Feelin est certe maintenant écrit en C (sauf les Tools/* au passage !) mais il utilise fréquément le binding de variable sur registre: en claire les truc genre « int variable __asm(« a0″) » par exemple, pour affecter une variable à un registre du 68k.
Ben ui, mais c’est obligatoire pour les fonctions de la bibliothèque. MorphOS passe tout sur la pile ou quoi ? Comment on fait avec le PPC ?? De toute façon c’est pas vraiment un problème, TOUS les hooks sont définis avec les macros F_HOOK et F_HOOKM et sont appelés avec F_CALLHOOK. Donc, au pire, il ne reste qu’à modifier ces macros…
4) oulalala que de warnings (et encore juste avec le -Wall sur gcc) sur des trucs genre: if (Bob = Alloc(sizeof(…)))
Wé ben il est vraiment très con GCC !!?
Bob = Alloc(sizeof(…)); if (Bob != NULL)
Boulala c’est pas gagné ! C’est complétement con ce test ! if (Bob) marche pas ??!! Va faloir que je sorte GCC de sa grotte et que je m’y frotte
BREF… c’est quand même des ptis détails pénibles tout ça… Je sais pas trop par quoi commencer … suggestions ?
BREF… c’est quand même des ptis détails pénibles tout ça… Je sais pas trop par quoi commencer … suggestions ?
suggestion: laisse tomber mon charabia, c’est pour du PPC/Moprhos, de toute façon j’ai commencé! ça vous apprendra! :p
1ere étape: utiliser les classes déjà compilées en 68k et recoder juste la lib feelin elle-même. J’ai les makefiles chez moi, depuis hier soir. Là j’ai recoder lib_OOS.c, je continue.
J’ai donc opté pour la solution « comme MUI », donc compatibilité entre les classes 68k et PPC.
2ème étape: faire marcher cette lib avec des classes PPC ou 68k.
3ème étape: recoder toutes les classes en mode native PPC.
Par contre je vais avoir besoin de l’aide de Henes… qui va pas tarder à recevoir un mail !
/me passe un mouchoir à Gofromiel
Si yomgui passe à l’offensive sur Feelin pour MOS, alors… je va trainer mes guetres ailleurs….
Merci Yomgui, t’es mon héro !
Si tu as la moindre question sur le fonctionnement interne de Feelin n’hésite pas… je suis pas très doué pour les commentaires dans les sources
Si yomgui passe à l’offensive sur Feelin pour MOS, alors… je va trainer mes guetres ailleurs…
Vous voulez pas trainer vos guètres ensmbles ??
Hier j’avais adapté un peu les scripts rexx, généré les ppcinlines tout ça. J’ai compilé qq fichiers, mais ça me fatigue tous ces hooks, ça fait faire des modifs à chaque fois c’est chiant, bien que facile à résoudre.
Le coup de grace pour moi ça a été à 3h du mat sur un « IntuitionBase->champ » qui se plaint.
Le coup de grace pour moi ça a été à 3h du mat sur un « IntuitionBase->champ » qui se plaint.
A ui, c’est sûr que ça va être un problème à la portabilité
Où est-ce que c’est ce trucms ? Dans AppServer ?? M’enfin c’est sûr qu’il y a des choses à adapter pour chaque os… comme la gestion des couleurs par exemple. Même si il n’y a que la méthode FM_Display_AddColor à modifier, il faut quand même le faire un peu En tous cas merci pour vos efforts !! Je vous aimerai toute ma vie !
Ouaip grosses modif à faire de toutes façon, j’ai commencé çà écrire les macros pour, car il faut pour chacune des fonctions s’occuper de l’émulation 68k (récup des valeur des registres A0, D0, etc de REG_A0, REG_D0, etc). et faire des appels avec EmulCall68k() quand il le faut. Plus virer tous les appels aux Forbid() & Co par des P/V sur semaphore.
Sinon moi hier soir je me suis couché direct
Comme quoi il suffit de booster Gofromiel et de parler de sa création pour que les efforts s’amplifient
Toine
- Vous devez être connecté pour répondre à ce sujet.
