Première lecture de "Universal Binary Guideline"
Le
pdorange
FU2 : <fr.comp.sys.mac.programmation>
Apple a annoncé hier le début du support de processeur Intel pour
l'architecture mac à partir de 2006.
Ce matin Apple a publié pour les développeurs un guide de transition et
fournit d'or et déjà XCode 2.1 qui supporte les 2 architectures
(processeur PowerPC et Intel).
Ce document apporte quelques éclaircissements.
Universal Binary permet de produire un logiciel qui sera à la fois
compatible avec les Mac actuels (PowerPC) et la prochaine génération
(Intel).
<http://developer.apple.com/document...iversal_bi
nary/>
Après une première lecture rapide, voilà les gros points que je relève :
* Pour utiliser "Universal Binary" il faut utiliser le package 10.4.
Mais on peut assigner 2 cibles aux projets : par exemple une cible
"universal Binary" avec 10.4 et aussi une cible "10.3".
* On reconnaitra les logiciel "UB" depuis le Finder (panneau Info, item
Architecture : PowerPC ou Intel ou PowerPC/Untel
* Les développeurs auront accès aux extensions Intel MMX, SSE et SSE2
qui sont "un peu" les équivalents de Altivec
Les principales différences architecturales :
* alignement : le code PowerPC doit être alignés sur 4 octects, pas le
code Intel
* ordonnancement des octects : les 2 architectures utilise un
ordonnancement différents : LITTLE ENDIAN / BIG ENDIAN, cela n'a pas
d'effet direct le plus souvent mais c'est un point important pour la
compatibilité a surveiller avec attention.
Cela touchera les interfaces réseaux bas niveau, les fonctions CallBack
, les GWorld QuickDraw et les textures OpenGL notamment
* appels de fonction : les paramètres de fonctions ne sont pas passés de
la même façon (par registre sur PowerPC, dans la stack pour Intel).
* division par ZERO : fatal sur Intel, pas sur PowerPC
* les partitions disques seront gérés différemment sur les 2
architectures. Cela n'a d'influence que sur les logiciels qui utilise a
un bas niveau les infos de partitions disques
* les Mac a architecture Intel, n'utiliseront pas OpenFirmware
Concernant Altivec et plus généralement les instructions Vectorisés :
* Apple conseille d'utiliser la Framework "Accelerate" introduit avec
10.3 et étendu avec 10.4 qui fournit un niveau d'abstraction qui permet
de s'affranchir des spécificités de la plateforme (PowerPC/Altivec,
Intel/MMX/SSE ou sans accélération vectorielle).
* ou alors un portage complet de Altivec vers MMX ou SSE.
Concernant Rosetta :
Rosetta est un process de traduction qui permet de faire tourner du code
PowerPC sur un futur Mac/Intel.
Rosetta gère tout code PowerPC G3 compilé pour MaxcOS X.
Rosetta ne gère pas :
- le code MacOS 8/9 (Classic)
- le code Altivec
- insersion de panneau de préférences
- code spécifique G4 ou G5
- code relatif au noyau
- extensions Kernel
- Java avec JNI
Rosetta traduit le code à la volée et s'éxecute dans le même process que
le logiciel "émulé". Rosetta utilise un cache pour améliorer les
performances.
Rosetta prend en comme l'ordonnancement des octects.
Depuis le Finder (panneau Info) on pourra forcer un logiciel utilisant
UB a tourner dans Rosetta (PowerPC on Intel).
* dans les annexes de ce document on trouve une partie concernant le
portage de logiciel utilisant le FramWork CodeWarrior : PowerPlant.
A complèter
--
Pierre-Alain Dorange
Vidéo, DV et QuickTime <http://alcazar.xbecom.com/videogarage/>
Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
Apple a annoncé hier le début du support de processeur Intel pour
l'architecture mac à partir de 2006.
Ce matin Apple a publié pour les développeurs un guide de transition et
fournit d'or et déjà XCode 2.1 qui supporte les 2 architectures
(processeur PowerPC et Intel).
Ce document apporte quelques éclaircissements.
Universal Binary permet de produire un logiciel qui sera à la fois
compatible avec les Mac actuels (PowerPC) et la prochaine génération
(Intel).
<http://developer.apple.com/document...iversal_bi
nary/>
Après une première lecture rapide, voilà les gros points que je relève :
* Pour utiliser "Universal Binary" il faut utiliser le package 10.4.
Mais on peut assigner 2 cibles aux projets : par exemple une cible
"universal Binary" avec 10.4 et aussi une cible "10.3".
* On reconnaitra les logiciel "UB" depuis le Finder (panneau Info, item
Architecture : PowerPC ou Intel ou PowerPC/Untel
* Les développeurs auront accès aux extensions Intel MMX, SSE et SSE2
qui sont "un peu" les équivalents de Altivec
Les principales différences architecturales :
* alignement : le code PowerPC doit être alignés sur 4 octects, pas le
code Intel
* ordonnancement des octects : les 2 architectures utilise un
ordonnancement différents : LITTLE ENDIAN / BIG ENDIAN, cela n'a pas
d'effet direct le plus souvent mais c'est un point important pour la
compatibilité a surveiller avec attention.
Cela touchera les interfaces réseaux bas niveau, les fonctions CallBack
, les GWorld QuickDraw et les textures OpenGL notamment
* appels de fonction : les paramètres de fonctions ne sont pas passés de
la même façon (par registre sur PowerPC, dans la stack pour Intel).
* division par ZERO : fatal sur Intel, pas sur PowerPC
* les partitions disques seront gérés différemment sur les 2
architectures. Cela n'a d'influence que sur les logiciels qui utilise a
un bas niveau les infos de partitions disques
* les Mac a architecture Intel, n'utiliseront pas OpenFirmware
Concernant Altivec et plus généralement les instructions Vectorisés :
* Apple conseille d'utiliser la Framework "Accelerate" introduit avec
10.3 et étendu avec 10.4 qui fournit un niveau d'abstraction qui permet
de s'affranchir des spécificités de la plateforme (PowerPC/Altivec,
Intel/MMX/SSE ou sans accélération vectorielle).
* ou alors un portage complet de Altivec vers MMX ou SSE.
Concernant Rosetta :
Rosetta est un process de traduction qui permet de faire tourner du code
PowerPC sur un futur Mac/Intel.
Rosetta gère tout code PowerPC G3 compilé pour MaxcOS X.
Rosetta ne gère pas :
- le code MacOS 8/9 (Classic)
- le code Altivec
- insersion de panneau de préférences
- code spécifique G4 ou G5
- code relatif au noyau
- extensions Kernel
- Java avec JNI
Rosetta traduit le code à la volée et s'éxecute dans le même process que
le logiciel "émulé". Rosetta utilise un cache pour améliorer les
performances.
Rosetta prend en comme l'ordonnancement des octects.
Depuis le Finder (panneau Info) on pourra forcer un logiciel utilisant
UB a tourner dans Rosetta (PowerPC on Intel).
* dans les annexes de ce document on trouve une partie concernant le
portage de logiciel utilisant le FramWork CodeWarrior : PowerPlant.
A complèter
--
Pierre-Alain Dorange
Vidéo, DV et QuickTime <http://alcazar.xbecom.com/videogarage/>
Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
Poser une question
Pas sur du tout, voilà le paragraphe en détail (et an anglais désolé
pour la charte) :
Disk Partitions
---------------
The partition format of the disk on a Macintosh using an Intel
microprocessor differs from that using a PowerPC microprocessor. If your
application depends on the partitioning details of the disk, it may not
behave as expected. Partitioning details can affect tools that examine
the hard disk at a low level.
Open Firmware
-------------
Macintosh computers using Intel microprocessors do not use Open
Firmware. Although many parts of the IO registry are present and work as
expected, information that is provided by Open Firmware on a Macintosh
using a PowerPC microprocessor (such as a complete device tree) is not
available in the IO registry on a Macintosh using an Intel
microprocessor. You can obtain some of the information from IODeviceTree
by using the sysctlbyname or sysctl commands.
--
Pierre-Alain Dorange
Vidéo, DV et QuickTime Clarus, the DogCow
Ca ne veut pas dire que ce sera le cas sur les machines commercialisées.
Patrick
--
Patrick Stadelmann
Dans le même style, à terme, je pense que le détail qui fera revoir le
plus de code aux développeurs Cocoa de "petits utilitaires" qui ne font
pas de calcul avancé ni d'OpenGL ou autres joyeusetés est le
comportement lors de l'envoi de messages à nil en Objective-C.
D'après les specs, le comportement n'a jamais été défini, mais comme sur
PPC l'envoi d'un message à nil renvoyait toujours la valeur 0, beaucoup
de développeurs s'y sont habitués.
Ce ne sera plus le cas sur x86 :
"On a Macintosh using an Intel microprocessor, Objective-C messages sent
to nil return garbage for return values that are typed as float or
double. On a Macintosh using a PowerPC microprocessor
these messages return 0.0." (p. 46)
--
Thomas Deniau
Alors ça veut dire que pour continuer utiliser le mode Classic, il faut
s'équiper d'ici un an! Les plates-formes actuelles sont les plus
compatibles face à la transition: ils permettront de tout utiliser en
natif (codes PPC et UB) et les codes MacOS 8/9 via Classic.
Pourquoi Apple se priverait-elle de continuer le développement des
plateformes PPC d'ici un an?
Personnellement, si je pouvais reporter mon achat d'un an, j'achèterais
un Mac PPC dernier cri en mai 2006!
Comme il semble prévu que ce sera d'abord le Macmini, ibook,Pbook tu
devrai pouvoir attendre jusqu'à janvier 2007, la gamme en Intel sera
complète en juin 2007.
--
Le sage montre la lune, l'imbécile regarde le doigt.