PPC ou Intel comment savoir sur quoi tourne mon appli ?
Math
Membre
Bonjour à tous 
<br />
J'ai créé une application (Objective-c/Cocoa) utilisant un petit prog open source. J'ai compilé cet outil sur mon mac PPC sans aucun problème et je l'utilise dans mon programme.
Sauf que maintenant avec les Mac Intel pour être universal binary je dois avoir deux versions de cet outil. Une version compilée sur PPC et une compilée sur Intel.
Alors la question est, comment savoir si mon application est lancée sur un mac Intel ou sur un mac PPC ? (afin de lancer la bonne version de l'outil).
Merci d'avance.
<br />J'ai créé une application (Objective-c/Cocoa) utilisant un petit prog open source. J'ai compilé cet outil sur mon mac PPC sans aucun problème et je l'utilise dans mon programme.
Sauf que maintenant avec les Mac Intel pour être universal binary je dois avoir deux versions de cet outil. Une version compilée sur PPC et une compilée sur Intel.
Alors la question est, comment savoir si mon application est lancée sur un mac Intel ou sur un mac PPC ? (afin de lancer la bonne version de l'outil).
Merci d'avance.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Un seul exécutable est présent, mais il contient les deux codes.
Va voir ce sujet Compilation i386
[Fichier joint supprimé par l'administrateur]
En fait je voulais dire :
comment savoir avec des lignes de codes si mon application est lancée sur un mac Intel ou sur un mac PPC ?
De telle façon que je fasse un truc du style :
Si je suis sur un mac ppc je lance totoPPC
Sinon je lance totoIntel
Essaye ceci :
Il me semble que c'est ça.
si isBigEndian retourne vrai, alors t'es sur PPC. Sinon t'es sur Intel
@+
Il stocke le short 0x0100 sous forme de short, puis dit ensuite qu'il faut le considérer comme tableau de char plutôt que short, et ainsi en regardant le byte[0] il regarde l'octet de poids fort.
Si le short est stocké en bigEndian (MSB first) byte[0] vaudra 0x01, sinon c'est byte[1] qui vaudra 0X01 et byte[0] 0x00.
Comme les PPC et les proc Intel n'utilisent pas le même endianness, il se base sur cette particularité pour faire la différence.
Enfin bon je trouve ça moyen, pourquoi se compliquer la vie alors qu'une directive de compilation ferait l'affaire ??
Si vraiment tu le veux sous forme de fonction : Lorsque tu vas compiler ce code, si tu le compiles pour PPC il va se compiler comme : et si tu compiles pour Intel il va se compiler ainsi : Cette compilation conditionnelle est automatique grace aux directives #if/#else/#endif qui agissent sur le compilateur. Et si tu compiles en UB, pas de problème, la partie compilée pour PPC dans le UB aura une implémentation de la fonction isOnPPC, et la partie Intel de l'UniversalBinary aura une autre implémentation.
Ca ne dérange pas que les #xxx soient des flags influant sur la compilation et non pas le runtime dans le sens où on peut comme ici les utiliser pour modifier l'implémentation d'une fonction selon qu'elle sera compilée pour intel et PPC, vu qu'après on peut faire appel à cette fonction pendant le Runtime, fonction qui sera implémentée différament si le logiciel tourne sous Intel (et donc que c'est la version compilée pour Intel qui est executée dans le package UB) ou tourne sous PPC
Je ne vois en aucun cas en quoi ça pose problème d'utiliser les #xxx même si tu veux savoir sur quel processeur est exécuté ton code, puisque sur un processeur Intel c'est le code compilé Intel qi s'executera et sur un proc PPC le code PPC.
je comprend les choses beaucoup mieux maintenant
Sauf que...
Que se passe t'il si un développeur utilise ta méthode, compile en ppc (donc fabrique une appli non UB) et fait tourner tout ça sur MacIntel dans Rosetta ?
.
You got me, Bru.
En fait l'idée des flags de compilation est de savoir si on est en train d'executer une version compilée PPC ou une version compilée Intel. Pas de savoir l'architecture courante de la machine.
Dans ce cas tester l'endianness peut être une possibilité, mais je trouve pas ça très pro perso (je sais pas pourquoi, enfin je trouve que ça fait plutôt "hack" que véritable test en fait)
Sinon j'ai trouvé ça dans NSProcessInfo, mais ça donne l'OS et pas le processeur (tiens, d'ailleurs, c'est étonnant ça... Cocoa serait prêt à supporter Windows ou quoi ? bizarre ce truc...)
Sinon j'utiliserais plutôt sysctl ou des trucs du genre pour récupérer les infos sur l'architecture courante.
En creusant je suis sûr qu'on peut récupérer les informations de "Informations Système" avec une API Cocoa plus sympatique, non ?
Que ce soit pour récupérer la version de OSX ou l'architecture de la machine où est executé le programme ? Y'a bien un truc, non ?
En effet, pas propre du tout.
En plus, puisque tu as évoqué sysctl, il existe une clé "hw.byteorder" qui retourne l'information du byte-ordering de manière officielle : 4321 pour big-endian et (sans doute) 1234 pour little-endian.
Effectivement, le truc est d'utiliser ou sysctl ou le gestalt manager.
Pour sysctl, il n'y a pas (par l'instant et d'après la doc) de clé permettant de récupérer l'info sur le type d'architecture. Pourtant, Apple a diffusé une astuce permettant de savoir si le code PPC tourne en natif (donc sur un PowerPc) ou sous Rosetta (donc sous Intel). Cela passe par une clé ajoutée au dictionnaire de sysctl n'existant que sous MacIntel ("sysctl.proc_native").
Pour gestalt, il y a le sélecteur 'sysa' qui retourne l'architecture de la machine. Actuellement cela retourne 1 (gestalt68k) pour 68XXX, 2 (gestaltPowerPC) pour PowerPC, et 10 (gestaltIntel) pour Intel. Par contre, j'ai cru comprendre que si le code tourne dans Rosetta, 'sysa' retourne alors 2 au lieu de 10.
Bref, c'est pas simple pour le moment, et cela montre que chez Apple, c'est encore le flou (du moins dans les docs).
Ma préférence va tout de même pour l'utilisation du gestalt.
.
(il faudra sans doute ajouter le framework Carbon au projet)
.
Salut
man arch
Donc à la limite tu peux tester l'endianness.
Mais du coup pas avec les instructions du préprocesseur, qui sont évaluées lors de la compilation ce qui fait que comme me l'a justement fait remarquer Bru, si on est sous Rosetta, en train de faire tourner la version PPC, c'est le code PPC qui s'executera alors qu'on sera sous Intel.
Et puis de toute façon si jamais on utilise les instructions préprocesseur, autant utilise __ppc__ comme macro plutôt que _BIG_ENDIAN
Par contre, je pensais à un truc : si on fait un UniversalBinary, on ne se trouvera jamais dans le cas où Rosetta fonctionnera, car la version Intel existera donc se lancera, non ?
Ca reste je trouve vraiment une solution un peu bidon, car ça ne répond pas à la question d'origine, mais bon pour le cas qui nous intéresse ça peut dépanner.
Mais je persiste à dire que c'est pas une bonne habitude
Pourquoi savoir ça ?
Tu as peur que pendant l'exécution de ton appli, l'architecture change 1000 fois de PPC à Intel et vice-versa ?
Un appel une seule fois au lancement/initialisation de l'une des méthodes ci-dessus (gestalt ayant ma préférence car c'est la méthode officielle) avec mémorisation du résultat est largement suffisant.
.
La curiosité.
Je suis étonné par le nombre de méthode différentes pour savoir si on fonctionne sur tell ou tell processeur.
Je suis aussi étonné par toutes ces méthodes
Merci à tous.
Hello,
Je ne comprends pas pourquoi ne pas simplement faire un petit exécutable universal binaries ?!
J'ai développé un petit programme qui utilise aussi un petit exécutable binaire (de type standard tool), et je l'ai compilé pour que ça fonctionne sur PPC et Intel.
La solution de compiler 2 binaires et de sélectionner à l'exécution me semble compliquée.
Il s'agit de ce programme : http://www.mt-daapd.org/
Si tu peux me dire comment faire ça serait sympa
Ah oui, en effet, c'est loin d'être aisé ???
Mais ça doit être possible malgré tout :P