binaires universels

15 sujets de 1 à 15 (sur un total de 40)

  • serge

      #1958

      Dans l’affaire récente d’Apple, il est question que les futurs

      binaires soient universels PPC et X86.

      Qui saurait résumer de facon simple cette notion d’universel?

      Est ce que les deux codes se retrouvent dans le même fichier ou est ce

      que c’est un mélange des deux?

      merci

      Modération de Bégonia : je ne vois pas ou l’on parle de programmation Amiga dans ce thread. Je le déplace donc dans autres os. Un peu plus et il se retrouvait dans troll. Attention de répondre dans le cadre du sujet…

      RyZen Rulez 😉

      anonyme

        #40324

        « binaires universels », c’est un abus de langage. Juste pour dire que les développeurs MacOSX auront la possibilité (avec XCode) de générer les 2 exécutables PPC et x86 pour le même soft (certainement de façon plus ou moins transparente pour les développeurs et les utilisateurs), tout ça pour la période de transition PPC –> x86 et donc l’ensemble des utilisateurs Mac.

        Par contre, pour que ça soit simple, ils ont intérêt de respecter les standards de programmation (dans leurs codes) qu’impose la pirouette ;)

        Yomgui

          #40325

          Effectivement. Arrêtons de croire au miracle qu’un code unique puisse un jour être exécutée par 2 architectures aux op-codes différents… intrinséquement impossible!

          Je trouve qu’Apple se met bien à devenir un parfais clone de Windows en faisant des effets d’annonces (dans des doc technique en plus!! mais quelle honte!) de ce genre : « binaires universels! »

          Comme le dit Jedi, c’est plutôt 2 binaires (un pour PPC, un pour Intel) dans 1 fichier… binaire lui aussi (mais après tout, tout fichier est binaire, même une page html, dans un certain sens ;-)). d’où l’abus.

          D’ailleur la doc Apple universal_binary.pdf le dit plus où moins directement qu’aucunes solutions miracle existe et que le sujet de cette doc est de montrer comment programmer pour avoir à peu ou prou retoucher son code (c’est une « guideline » donc).

          Comme par exemple, faire gaffe au endianness lors de l’écriture de données mémoire (au format natif donc) vers un média externe au µP (ex: un disque dur)

          Résumons nous par : cette doc ne sert à rappeler qq chose que tout développeur devrait savoir et pratiquer depuis longtemps.

          RTFM

          Lanza

            #40326

            Oué, si tu veux des vrais biniares universels faut se tourner vers java ou .Net . Ceux-là nécéssitent un compilo JIT pour tourner et sont vraiments indépendants du processeur.

            J’ai l’impression à la lecture de la nouvelle doc developpeur d’Apple qu’ils sont allés un peu vite. Je la trouve pas vraiment rassurante cette doc.

            Pourquoi ils font pas un recompilateur, tiens ? Tu transformes un binaire PPC en binaires x86 (ou Universal machin chouette) et zou.

            Ou mieux : un binaire dans un code binaire intermédiare qui serait compilé à l’installation ou la première execution ?

            Il faut un truc comme ça à AROS. Hop, au boulot ! :-D

            serge

              #40327

              vous me rassurez les mecs.

              Je ne voyais vraiment pas comment faire un binaire universel et je finissais par croire qu’apple avait trouvé la ruse qui va bien.

              En réalité, ils jouent sur les mots. C’est pas beau ca de vouloir embobiner les gens.

              En gros, deux programmes dans un seul fichier voila ce qu’ils proposent au mieu.

              OK merci pour les explications.

              RyZen Rulez 😉

              Yomgui

                #40328

                @serge :

                oui, mais je te raconte pas la taille du « binaire » final!

                Si on veut sauver de la place, il faut alors utiliser « Rosetta », l’émulateur PPC sur Intel.

                D’ailleur l’existance de ce soft démontre bien qu’un binaire universel n’existe pas.

                bob1969

                  #40329

                  Les codes sources en C peuvent s’echanger mais les library ?

                  Comment ils vont faire pour ne pas tout réécrire ?

                  Par exemple,les routines bas niveaux dans les ROMs du Mac c’est pas un « compile and run » qui va faire le boulot. faut a mon avis tout reprendre et seules des parties processeur PPc pourront etre recompilé facilement mais le reste j’en doute.

                  Il y a du boulot ! ou alors Apple avait prévus çà depuis plus longtemps.

                  Steves le machiavel

                  bob1969

                  curieux

                  hybrid

                    #40330

                    Non, en fait, ils ont intégrés AmigaDE en guise de noyau au futur Mac ! :-D

                    anonyme

                      #40331

                      bob1969 a écrit :

                      Il y a du boulot ! ou alors Apple avait prévus çà depuis plus longtemps.

                      A priori, une version x86 de MacOSX a toujours existé depuis le début (5 ans)… ça n’empêche pas de devoir porter les softs sur x86 hein, et certainement encore plein d’autres trucs techniques, mais c’est déjà énorme.

                      Pour ça, je tire mon chapeau à Apple et à Steve Jobs d’avoir pris cette précaution (et décision) dès le départ.

                      Dès le départ, ils se sont dits que si il y avait un soucis quelconque avec les PPC et IBM, ils pourraient ainsi migrer plus facilement et rapidement vers l’autre grosse architecture hardware du marché, le x86.

                      ‘Fallait le faire, un sacré choix, et ça prouve aussi la portabilité de MacOSX, excellent :-)

                      Ils ont certainement retenu les leçons du passé (passage du 68k au PPC).

                      Un exemple (premier du genre dans le monde des OS ?), que d’autres devraient (auraient) dû suivre… (l’Amiga le premier, il n’en serait peut-être pas là…).

                      Franchement, sur ce point, il m’a scotché le Steve ;-)

                      D’autant plus que là, ils arrivent avec leur annonce alors que c’est déjà prévu depuis le début, ça change de la façon de procéder sur Amiga ;-) (oui, les moyens ne sont pas les mêmes).

                      JuLieN

                        #40332

                        Je me demande si Apple n’a pas tout simplement l’intention de prévoir pour les prochaines versions d’OSX un nouveau format d’exécutable incorporant à la fois un code objet PPC et un code objet x86. Cela ferait des EXEs deux fois plus gros, mais tournant à la fois sur les deux architectures, pourvu que l’OS soit à jour. L’en-tête du fichier permettrait à l’OS de choisir quel code exécuter suivant l’architecture hôte. Cela simplifierait également aussi le travail des développeurs, qui n’auraient qu’un seul développement et une seule compilation à faire. Ce n’est qu’une hypothèse, bien sûr, mais c’est comme ça que j’ai compris l’annonce d’Apple.

                        J’en profite pour remercier les bien pensants et autres messieurs « je sais tout » qui m’ont tourné en dérision sur l’IRC lorsque j’ai dit, il y a deux mois, que mon VAIO / P4 écrasait n’importe quel PowerPC et qu’il serait judicieux de migrer MorphOS sur PC. Je ne parle même pas du rapport performances/prix qui enterre définitivement les PowerPC.

                        L’argumentation falatieuse que l’ont m’avait sortie était que, sur PC, face à Windows, personne n’irait installer MorphOS. Cette argumentation est absurde, car elle « oublie » que même sur Pegasos, MorphOS ne peut rien face à la concurrence de Linux. On installe et utilise un OS quand il est attractif, l’architecture n’a rien à y voir. Apple vient de le démontrer (en espérant que MacOSX soit aussi intéressant que Longhorn, ce dont je doute…). D’une manière générale, porter MorphOS sur PC n’aurait QUE des avantages : matériel très puissant et évolutif à loisir sans passer par Génémafia, base énorme d’utilisateurs susceptibles de s’intéresser à notre OS, etc…

                        /Me, désabusé

                        jah

                          #40333

                          ils avaient deja utilisé ce « mixage » pour faire des binaires 68k+ppc

                          dit « fat » au moment de la transition vers le ppc

                          thefab

                            #40334

                            @Yomgui:

                            tu parles de la taille des bins mais imagine un peu la taille des ‘updates’, macosx ou l’os qui propose des maj hebdomadaires mamouths de 1go :-D

                            imaginons encore un bug présent dans le code objet x86 et pas dans le code ppc (ou inversement), on est obligé d’updater le bin complet, même celui qui est sain, encore et toujours plus de lourdeur, merci apple de me conforter dans ce que je fuis depuis le début.

                            Yomgui

                              #40335

                              @Julien:

                              Je me demande si Apple n’a pas tout simplement l’intention de prévoir pour les prochaines versions d’OSX un nouveau format d’exécutable incorporant à la fois un code objet PPC et un code objet x86.

                              [correction] et le Mach-O? ne serait-ce pas cela?

                              Fab1

                                #40336

                                Jedi:

                                Avec OSX ils sont partis d’un existant déjà portable sur plein d’architectures, aucun mérite. Ce qui aurait été étonnant c’est que ce ne soit pas portable facilement. :)

                                thefab

                                  #40337

                                  @Fab:

                                  effectivement nombreux semblent oublié que darwin existe également sur x86 depuis belle lurette ;-)

                                15 sujets de 1 à 15 (sur un total de 40)

                                • Vous devez être connecté pour répondre à ce sujet.

                                Forums AmigaOS, MorphOS et AROS Émulation et autres OS binaires universels

                                Amiga Impact