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).
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/>
* 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
Ces deux points sont très fâcheux, et semblent signifier qu'on se dirige vers une "vraie" archi ia32, avec BIOS et MBR.
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 <http://alcazar.xbecom.com/videogarage/> Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
Xavier <xavier@groumpf.org> wrote:
* 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
Ces deux points sont très fâcheux, et semblent signifier qu'on se dirige
vers une "vraie" archi ia32, avec BIOS et MBR.
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 <http://alcazar.xbecom.com/videogarage/>
Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
* 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
Ces deux points sont très fâcheux, et semblent signifier qu'on se dirige vers une "vraie" archi ia32, avec BIOS et MBR.
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 <http://alcazar.xbecom.com/videogarage/> Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
Patrick Stadelmann
In article <1gxse37.1kezw8y1n05ig1N%, (Xavier) wrote:
Je ne suis pas convaincu. D'autant plus que dans l'article <http://www.mrbarrett.com/archives/2005/06/mac_os_x_on_int.html>, le type qui avait en main une bécane du lab de tests Apple pense que c'est une carte mère Intel tout ce qu'il y a de standard.
Ca ne veut pas dire que ce sera le cas sur les machines commercialisées.
Patrick -- Patrick Stadelmann
In article <1gxse37.1kezw8y1n05ig1N%xavier@groumpf.org>,
xavier@groumpf.org (Xavier) wrote:
Je ne suis pas convaincu. D'autant plus que dans l'article
<http://www.mrbarrett.com/archives/2005/06/mac_os_x_on_int.html>, le
type qui avait en main une bécane du lab de tests Apple pense que c'est
une carte mère Intel tout ce qu'il y a de standard.
Ca ne veut pas dire que ce sera le cas sur les machines commercialisées.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1gxse37.1kezw8y1n05ig1N%, (Xavier) wrote:
Je ne suis pas convaincu. D'autant plus que dans l'article <http://www.mrbarrett.com/archives/2005/06/mac_os_x_on_int.html>, le type qui avait en main une bécane du lab de tests Apple pense que c'est une carte mère Intel tout ce qu'il y a de standard.
Ca ne veut pas dire que ce sera le cas sur les machines commercialisées.
Patrick -- Patrick Stadelmann
thomas-ml
Pierre-Alain Dorange wrote:
* division par ZERO : fatal sur Intel, pas sur PowerPC
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)
* division par ZERO : fatal sur Intel, pas sur PowerPC
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)
* division par ZERO : fatal sur Intel, pas sur PowerPC
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
Nicolas Falcimaigne
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)
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!
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)
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!
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)
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!
langmc
Nicolas Falcimaigne wrote:
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)
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.
Nicolas Falcimaigne <brasseurarobas@grandefauxpoint.com> wrote:
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)
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.
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)
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.
Schmurtz
(Xavier) wrote:
Pierre-Alain Dorange wrote:
* 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
Ces deux points sont très fâcheux, et semblent signifier qu'on se dirige vers une "vraie" archi ia32, avec BIOS et MBR.
Une archi qui était déja pourrie (au dire des ingénieurs Intel eux-même) lors de sa conception il y a plus de 15 ans.
C'est dommage, l'open firmware était une grande avancée.
Dans le même ordre d'idée, abandonner les nombreux registres du ppc pour travailler en majorité avec la mémoire et les registres qui se battent en duel des ia32, c'est un peu pareil. Dommage qu'ibm ne soit pas à la hauteur dans les techniques de production, l'architecture des ppc était vraiment prometeuse.
* 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
Ces deux points sont très fâcheux, et semblent signifier qu'on se dirige
vers une "vraie" archi ia32, avec BIOS et MBR.
Une archi qui était déja pourrie (au dire des ingénieurs Intel eux-même)
lors de sa conception il y a plus de 15 ans.
C'est dommage, l'open firmware était une grande avancée.
Dans le même ordre d'idée, abandonner les nombreux registres du ppc pour
travailler en majorité avec la mémoire et les registres qui se battent
en duel des ia32, c'est un peu pareil. Dommage qu'ibm ne soit pas à la
hauteur dans les techniques de production, l'architecture des ppc était
vraiment prometeuse.
* 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
Ces deux points sont très fâcheux, et semblent signifier qu'on se dirige vers une "vraie" archi ia32, avec BIOS et MBR.
Une archi qui était déja pourrie (au dire des ingénieurs Intel eux-même) lors de sa conception il y a plus de 15 ans.
C'est dommage, l'open firmware était une grande avancée.
Dans le même ordre d'idée, abandonner les nombreux registres du ppc pour travailler en majorité avec la mémoire et les registres qui se battent en duel des ia32, c'est un peu pareil. Dommage qu'ibm ne soit pas à la hauteur dans les techniques de production, l'architecture des ppc était vraiment prometeuse.
-- Schmurtz
Gilles Vollant
"Schmurtz" a écrit dans le message de news: 42a62cc5$0$14621$
Dans le même ordre d'idée, abandonner les nombreux registres du ppc pour travailler en majorité avec la mémoire et les registres qui se battent en duel des ia32, c'est un peu pareil. Dommage qu'ibm ne soit pas à la hauteur dans les techniques de production, l'architecture des ppc était vraiment prometeuse.
Ce que je ne comprend vraiment pas, c'est qu'a la lecture de ce guide, la plateforme x86 utilisé est 32 bits et non x64.
en x64, le nombre de registre double. Et surtout, si apple passe au x86 32 bits, cela veut dire qu'il faudra remigrer tôt ou tard en 64...
"Schmurtz" <moi@ici.com> a écrit dans le message de news:
42a62cc5$0$14621$636a15ce@news.free.fr...
Dans le même ordre d'idée, abandonner les nombreux registres du ppc pour
travailler en majorité avec la mémoire et les registres qui se battent
en duel des ia32, c'est un peu pareil. Dommage qu'ibm ne soit pas à la
hauteur dans les techniques de production, l'architecture des ppc était
vraiment prometeuse.
Ce que je ne comprend vraiment pas, c'est qu'a la lecture de ce guide, la
plateforme x86 utilisé est 32 bits et non x64.
en x64, le nombre de registre double.
Et surtout, si apple passe au x86 32 bits, cela veut dire qu'il faudra
remigrer tôt ou tard en 64...
"Schmurtz" a écrit dans le message de news: 42a62cc5$0$14621$
Dans le même ordre d'idée, abandonner les nombreux registres du ppc pour travailler en majorité avec la mémoire et les registres qui se battent en duel des ia32, c'est un peu pareil. Dommage qu'ibm ne soit pas à la hauteur dans les techniques de production, l'architecture des ppc était vraiment prometeuse.
Ce que je ne comprend vraiment pas, c'est qu'a la lecture de ce guide, la plateforme x86 utilisé est 32 bits et non x64.
en x64, le nombre de registre double. Et surtout, si apple passe au x86 32 bits, cela veut dire qu'il faudra remigrer tôt ou tard en 64...
Eric Lévénez
Le 11/06/05 16:00, dans <42aaee8e$0$4914$, « Gilles Vollant » a écrit :
Ce que je ne comprend vraiment pas, c'est qu'a la lecture de ce guide, la plateforme x86 utilisé est 32 bits et non x64.
Quand on change d'architecture, on commence par ce qui est simple et on fait évoluer le système. Apple commence en 32 bits, et finira en 64 bits bien sûr. Qui peut en douter ? Il ne faut pas oublier que le kit de développement actuel est la bêta d'un système qui sortira dans un an.
en x64, le nombre de registre double.
Le terme "x64" est impropre. Il fait référence au "x86" où le x voulait dire 1, 2, 3, 4... Le terme "x64" est le terme utilisé par Microsoft pour qualifier ses versions de Windows marchant sur les processeurs 64 bits. Il vaut mieux utiliser le terme IA64 qui au moins ne fait pas référence à Microsoft.
Et surtout, si apple passe au x86 32 bits, cela veut dire qu'il faudra remigrer tôt ou tard en 64...
Il suffit de bien écrire les applis dès maintenant (cela a dû être fait pour ceux qui veulent utiliser le mode 64 bits des G5). Après il suffira de recompiler en fat binaries.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 11/06/05 16:00, dans <42aaee8e$0$4914$636a15ce@news.free.fr>, « Gilles
Vollant » <info@winimage.com> a écrit :
Ce que je ne comprend vraiment pas, c'est qu'a la lecture de ce guide, la
plateforme x86 utilisé est 32 bits et non x64.
Quand on change d'architecture, on commence par ce qui est simple et on fait
évoluer le système. Apple commence en 32 bits, et finira en 64 bits bien
sûr. Qui peut en douter ? Il ne faut pas oublier que le kit de développement
actuel est la bêta d'un système qui sortira dans un an.
en x64, le nombre de registre double.
Le terme "x64" est impropre. Il fait référence au "x86" où le x voulait dire
1, 2, 3, 4... Le terme "x64" est le terme utilisé par Microsoft pour
qualifier ses versions de Windows marchant sur les processeurs 64 bits. Il
vaut mieux utiliser le terme IA64 qui au moins ne fait pas référence à
Microsoft.
Et surtout, si apple passe au x86 32 bits, cela veut dire qu'il faudra
remigrer tôt ou tard en 64...
Il suffit de bien écrire les applis dès maintenant (cela a dû être fait pour
ceux qui veulent utiliser le mode 64 bits des G5). Après il suffira de
recompiler en fat binaries.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 11/06/05 16:00, dans <42aaee8e$0$4914$, « Gilles Vollant » a écrit :
Ce que je ne comprend vraiment pas, c'est qu'a la lecture de ce guide, la plateforme x86 utilisé est 32 bits et non x64.
Quand on change d'architecture, on commence par ce qui est simple et on fait évoluer le système. Apple commence en 32 bits, et finira en 64 bits bien sûr. Qui peut en douter ? Il ne faut pas oublier que le kit de développement actuel est la bêta d'un système qui sortira dans un an.
en x64, le nombre de registre double.
Le terme "x64" est impropre. Il fait référence au "x86" où le x voulait dire 1, 2, 3, 4... Le terme "x64" est le terme utilisé par Microsoft pour qualifier ses versions de Windows marchant sur les processeurs 64 bits. Il vaut mieux utiliser le terme IA64 qui au moins ne fait pas référence à Microsoft.
Et surtout, si apple passe au x86 32 bits, cela veut dire qu'il faudra remigrer tôt ou tard en 64...
Il suffit de bien écrire les applis dès maintenant (cela a dû être fait pour ceux qui veulent utiliser le mode 64 bits des G5). Après il suffira de recompiler en fat binaries.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Vincent Bernat
OoO Vers la fin de l'après-midi du samedi 11 juin 2005, vers 16:59, Eric Lévénez disait:
Ce que je ne comprend vraiment pas, c'est qu'a la lecture de ce guide, la plateforme x86 utilisé est 32 bits et non x64.
Quand on change d'architecture, on commence par ce qui est simple et on fait évoluer le système. Apple commence en 32 bits, et finira en 64 bits bien sûr. Qui peut en douter ? Il ne faut pas oublier que le kit de développement actuel est la bêta d'un système qui sortira dans un an.
Le fait de devoir gérer un système mixte 32 et 64 bits est extrêmement pénalisant aussi bien pour les utilisateurs qui vont avoir des problèmes avec les plugins (et aussi attendre que la version 64 bits soit disponible) que pour les développeurs qui vont devoir gérer le versionnement des librairies.
Vu que la plupart des Unix savent depuis des années tourner sur des plateformes 64 bits, que Mac OS X savait aussi tourner sur une plateforme 64 bits plus compliquée (le PPC) que l'x86-64, j'avoue avoir du mal à comprendre ce choix. -- panic("CPU too expensive - making holiday in the ANDES!"); 2.2.16 /usr/src/linux/arch/mips/kernel/traps.c
OoO Vers la fin de l'après-midi du samedi 11 juin 2005, vers 16:59,
Eric Lévénez <eric@levenez.com> disait:
Ce que je ne comprend vraiment pas, c'est qu'a la lecture de ce guide, la
plateforme x86 utilisé est 32 bits et non x64.
Quand on change d'architecture, on commence par ce qui est simple et on fait
évoluer le système. Apple commence en 32 bits, et finira en 64 bits bien
sûr. Qui peut en douter ? Il ne faut pas oublier que le kit de développement
actuel est la bêta d'un système qui sortira dans un an.
Le fait de devoir gérer un système mixte 32 et 64 bits est extrêmement
pénalisant aussi bien pour les utilisateurs qui vont avoir des
problèmes avec les plugins (et aussi attendre que la version 64 bits
soit disponible) que pour les développeurs qui vont devoir gérer le
versionnement des librairies.
Vu que la plupart des Unix savent depuis des années tourner sur des
plateformes 64 bits, que Mac OS X savait aussi tourner sur une
plateforme 64 bits plus compliquée (le PPC) que l'x86-64, j'avoue
avoir du mal à comprendre ce choix.
--
panic("CPU too expensive - making holiday in the ANDES!");
2.2.16 /usr/src/linux/arch/mips/kernel/traps.c
OoO Vers la fin de l'après-midi du samedi 11 juin 2005, vers 16:59, Eric Lévénez disait:
Ce que je ne comprend vraiment pas, c'est qu'a la lecture de ce guide, la plateforme x86 utilisé est 32 bits et non x64.
Quand on change d'architecture, on commence par ce qui est simple et on fait évoluer le système. Apple commence en 32 bits, et finira en 64 bits bien sûr. Qui peut en douter ? Il ne faut pas oublier que le kit de développement actuel est la bêta d'un système qui sortira dans un an.
Le fait de devoir gérer un système mixte 32 et 64 bits est extrêmement pénalisant aussi bien pour les utilisateurs qui vont avoir des problèmes avec les plugins (et aussi attendre que la version 64 bits soit disponible) que pour les développeurs qui vont devoir gérer le versionnement des librairies.
Vu que la plupart des Unix savent depuis des années tourner sur des plateformes 64 bits, que Mac OS X savait aussi tourner sur une plateforme 64 bits plus compliquée (le PPC) que l'x86-64, j'avoue avoir du mal à comprendre ce choix. -- panic("CPU too expensive - making holiday in the ANDES!"); 2.2.16 /usr/src/linux/arch/mips/kernel/traps.c
verdoux
Eric Lévénez wrote:
Le 11/06/05 16:00, dans <42aaee8e$0$4914$, « Gilles
en x64, le nombre de registre double.
Le terme "x64" est impropre. Il fait référence au "x86" où le x voulait dire 1, 2, 3, 4... Le terme "x64" est le terme utilisé par Microsoft pour qualifier ses versions de Windows marchant sur les processeurs 64 bits. Il vaut mieux utiliser le terme IA64 qui au moins ne fait pas référence à Microsoft.
x86-64 plutôt. IA64, c'est la dénomination Intel pour l'archi des Itanium.
Eric Lévénez wrote:
Le 11/06/05 16:00, dans <42aaee8e$0$4914$636a15ce@news.free.fr>, « Gilles
en x64, le nombre de registre double.
Le terme "x64" est impropre. Il fait référence au "x86" où le x voulait dire
1, 2, 3, 4... Le terme "x64" est le terme utilisé par Microsoft pour
qualifier ses versions de Windows marchant sur les processeurs 64 bits. Il
vaut mieux utiliser le terme IA64 qui au moins ne fait pas référence à
Microsoft.
x86-64 plutôt. IA64, c'est la dénomination Intel pour l'archi des Itanium.
Le 11/06/05 16:00, dans <42aaee8e$0$4914$, « Gilles
en x64, le nombre de registre double.
Le terme "x64" est impropre. Il fait référence au "x86" où le x voulait dire 1, 2, 3, 4... Le terme "x64" est le terme utilisé par Microsoft pour qualifier ses versions de Windows marchant sur les processeurs 64 bits. Il vaut mieux utiliser le terme IA64 qui au moins ne fait pas référence à Microsoft.
x86-64 plutôt. IA64, c'est la dénomination Intel pour l'archi des Itanium.
