Si on lit bien ce que tu dis, ce serait plus intéressant d'avoir un
processeur avec plus de registres qu'un processeur avec plus de bits
Si on lit bien ce que tu dis, ce serait plus intéressant d'avoir un
processeur avec plus de registres qu'un processeur avec plus de bits
Si on lit bien ce que tu dis, ce serait plus intéressant d'avoir un
processeur avec plus de registres qu'un processeur avec plus de bits
Il est donc surprenant que Apple n'exploite que le mode 32 bits, ce
Tu parles de quoi ? Des kits de développement ? Quelle rapport avec les Mac
qui sortirons dans un ou deux ans ?
qui obligera de nouveau à une migration des applications.
Pourquoi cela ?
À moins que
ce soit prévu dès maintenant et que les binaires FAT contiennent à la
fois la version 32 bits et la version 64 bits.
C'est déjà le cas sous Tiger pour certaines applis PPC. Ce sera la même
chose sous x86.
Il est donc surprenant que Apple n'exploite que le mode 32 bits, ce
Tu parles de quoi ? Des kits de développement ? Quelle rapport avec les Mac
qui sortirons dans un ou deux ans ?
qui obligera de nouveau à une migration des applications.
Pourquoi cela ?
À moins que
ce soit prévu dès maintenant et que les binaires FAT contiennent à la
fois la version 32 bits et la version 64 bits.
C'est déjà le cas sous Tiger pour certaines applis PPC. Ce sera la même
chose sous x86.
Il est donc surprenant que Apple n'exploite que le mode 32 bits, ce
Tu parles de quoi ? Des kits de développement ? Quelle rapport avec les Mac
qui sortirons dans un ou deux ans ?
qui obligera de nouveau à une migration des applications.
Pourquoi cela ?
À moins que
ce soit prévu dès maintenant et que les binaires FAT contiennent à la
fois la version 32 bits et la version 64 bits.
C'est déjà le cas sous Tiger pour certaines applis PPC. Ce sera la même
chose sous x86.
Si on lit bien ce que tu dis, ce serait plus intéressant d'avoir un
processeur avec plus de registres qu'un processeur avec plus de bits
(les concours de bits, ce que j'en pense ...).
Si on lit bien ce que tu dis, ce serait plus intéressant d'avoir un
processeur avec plus de registres qu'un processeur avec plus de bits
(les concours de bits, ce que j'en pense ...).
Si on lit bien ce que tu dis, ce serait plus intéressant d'avoir un
processeur avec plus de registres qu'un processeur avec plus de bits
(les concours de bits, ce que j'en pense ...).
OoO Vers la fin de l'après-midi du samedi 11 juin 2005, vers 16:46,
Eric Lévénez disait:Il est donc surprenant que Apple n'exploite que le mode 32 bits, ce
Tu parles de quoi ? Des kits de développement ? Quelle rapport avec les Mac
qui sortirons dans un ou deux ans ?
Ils feront tourner des programmes 32 bits qui ne pourront donc pas
exploiter la partie 64 bits des PC.
qui obligera de nouveau à une migration des applications.
Pourquoi cela ?
Parce qu'un programme 32 bits ne peut pas exploiter les registres
supplémentaires disponibles en 64 bits sans une recompilation.
À moins que
ce soit prévu dès maintenant et que les binaires FAT contiennent à la
fois la version 32 bits et la version 64 bits.
C'est déjà le cas sous Tiger pour certaines applis PPC. Ce sera la même
chose sous x86.
Non, c'est différent. Sous PPC, seules quelques applications ont
intérêt à être compilées pour 64 bits car toutes les autres auront des
performances moindres en 64 bits qu'en 32 bits (c'est aussi le cas
pour les Sparc par exemple). Sous PC, toutes les applications
bénéficient d'une vitesse accrue grâce à l'augmentation du nombre de
registres si elles sont compilées en 64 bits.
Si le kit de développement fourni par Apple ne fonctionne qu'en 32
bits, les développeurs font fournir des applications 32 bits
uniquement.
Dans un an, quand les versions 64 bits du matériel d'Apple
sortiront, il faudra recompiler.
Le gain en vitesse est à mon avis un
argument commercial pour refaire payer l'acheteur.
De plus, c'est extrêmement bloquant de se trimballer des applis 32
bits et 64 bits sur le même système :
plusieurs compilos,
plusieurs
versions des libs,
non compatibilité binaire
entre les applis
donc
problèmes avec les plugins.
Si Apple choisit un proc compatible EMT64,
c'est vraiment dommage de ne pas choisir directement une toolchain
entièrement 64 bits vu qu'il n'y a en général que des gains au niveau
des performances.
OoO Vers la fin de l'après-midi du samedi 11 juin 2005, vers 16:46,
Eric Lévénez <eric@levenez.com> disait:
Il est donc surprenant que Apple n'exploite que le mode 32 bits, ce
Tu parles de quoi ? Des kits de développement ? Quelle rapport avec les Mac
qui sortirons dans un ou deux ans ?
Ils feront tourner des programmes 32 bits qui ne pourront donc pas
exploiter la partie 64 bits des PC.
qui obligera de nouveau à une migration des applications.
Pourquoi cela ?
Parce qu'un programme 32 bits ne peut pas exploiter les registres
supplémentaires disponibles en 64 bits sans une recompilation.
À moins que
ce soit prévu dès maintenant et que les binaires FAT contiennent à la
fois la version 32 bits et la version 64 bits.
C'est déjà le cas sous Tiger pour certaines applis PPC. Ce sera la même
chose sous x86.
Non, c'est différent. Sous PPC, seules quelques applications ont
intérêt à être compilées pour 64 bits car toutes les autres auront des
performances moindres en 64 bits qu'en 32 bits (c'est aussi le cas
pour les Sparc par exemple). Sous PC, toutes les applications
bénéficient d'une vitesse accrue grâce à l'augmentation du nombre de
registres si elles sont compilées en 64 bits.
Si le kit de développement fourni par Apple ne fonctionne qu'en 32
bits, les développeurs font fournir des applications 32 bits
uniquement.
Dans un an, quand les versions 64 bits du matériel d'Apple
sortiront, il faudra recompiler.
Le gain en vitesse est à mon avis un
argument commercial pour refaire payer l'acheteur.
De plus, c'est extrêmement bloquant de se trimballer des applis 32
bits et 64 bits sur le même système :
plusieurs compilos,
plusieurs
versions des libs,
non compatibilité binaire
entre les applis
donc
problèmes avec les plugins.
Si Apple choisit un proc compatible EMT64,
c'est vraiment dommage de ne pas choisir directement une toolchain
entièrement 64 bits vu qu'il n'y a en général que des gains au niveau
des performances.
OoO Vers la fin de l'après-midi du samedi 11 juin 2005, vers 16:46,
Eric Lévénez disait:Il est donc surprenant que Apple n'exploite que le mode 32 bits, ce
Tu parles de quoi ? Des kits de développement ? Quelle rapport avec les Mac
qui sortirons dans un ou deux ans ?
Ils feront tourner des programmes 32 bits qui ne pourront donc pas
exploiter la partie 64 bits des PC.
qui obligera de nouveau à une migration des applications.
Pourquoi cela ?
Parce qu'un programme 32 bits ne peut pas exploiter les registres
supplémentaires disponibles en 64 bits sans une recompilation.
À moins que
ce soit prévu dès maintenant et que les binaires FAT contiennent à la
fois la version 32 bits et la version 64 bits.
C'est déjà le cas sous Tiger pour certaines applis PPC. Ce sera la même
chose sous x86.
Non, c'est différent. Sous PPC, seules quelques applications ont
intérêt à être compilées pour 64 bits car toutes les autres auront des
performances moindres en 64 bits qu'en 32 bits (c'est aussi le cas
pour les Sparc par exemple). Sous PC, toutes les applications
bénéficient d'une vitesse accrue grâce à l'augmentation du nombre de
registres si elles sont compilées en 64 bits.
Si le kit de développement fourni par Apple ne fonctionne qu'en 32
bits, les développeurs font fournir des applications 32 bits
uniquement.
Dans un an, quand les versions 64 bits du matériel d'Apple
sortiront, il faudra recompiler.
Le gain en vitesse est à mon avis un
argument commercial pour refaire payer l'acheteur.
De plus, c'est extrêmement bloquant de se trimballer des applis 32
bits et 64 bits sur le même système :
plusieurs compilos,
plusieurs
versions des libs,
non compatibilité binaire
entre les applis
donc
problèmes avec les plugins.
Si Apple choisit un proc compatible EMT64,
c'est vraiment dommage de ne pas choisir directement une toolchain
entièrement 64 bits vu qu'il n'y a en général que des gains au niveau
des performances.
Tu parles de quoi ? Des kits de développement ? Quelle rapport avec les Mac
qui sortirons dans un ou deux ans ?
Ils feront tourner des programmes 32 bits qui ne pourront donc pas
exploiter la partie 64 bits des PC.
Hein ? Où donc as-tu vu que les futurs Mac/Intel ne seront pas 64
bits ?
qui obligera de nouveau à une migration des applications.
Pourquoi cela ?
Parce qu'un programme 32 bits ne peut pas exploiter les registres
supplémentaires disponibles en 64 bits sans une recompilation.
Alors pour toi "migration", c'est pareil que "recompilation" ? Les applis 32
bits G4 peuvent exploiter les registres 64 bits du G5 sans recompilation si
elles utilisent les bibliothèques Apple.
Dans un an, quand les versions 64 bits du matériel d'Apple
sortiront, il faudra recompiler.
Et alors ? C'est dur de cliquer ?
Et dans un an, qui te dit que Mac OS X/Intel ne sera pas
64 bits ?
Le gain en vitesse est à mon avis un argument commercial pour
refaire payer l'acheteur.
Là je pense que tu ne parles pas d'Apple, mais de société comme Quark, je
pense.
De plus, c'est extrêmement bloquant de se trimballer des applis 32
bits et 64 bits sur le même système :
Ah ? Faudra que j'en parle à mon NeXTSTEP qui gérer les quad-binaries sans
problème.
plusieurs versions des libs,
Si tu parles des sections dans un seul et même exécutable (comme
c'est déjà actuellement le cas dans Tiger, je le regrêt de te
l'apprendre), alors oui.
non compatibilité binaire entre les applis
Hein ? Quelle rapport entre les internes des applications et les
IPC ?
donc problèmes avec les plugins.
Cela dépend de l'architecture. Apple a indiqué que l'on pourrait très bien
avoir une appli Intel utilisant des plugins PPC à travers Rosetta. Alors toi
tu as peur des Plugins incompatibles Intel ? C'est vrai ?
Si Apple choisit un proc compatible EMT64,
c'est vraiment dommage de ne pas choisir directement une toolchain
Une "toolchain", whao. Tu voudrais qu'Apple abandonne Xcode juste parce que
le premier kit de développement d'un OS qui sortira dans un an, n'a pas
toutes les fonctionnalités que tu attends de gcc ?
Tu parles de quoi ? Des kits de développement ? Quelle rapport avec les Mac
qui sortirons dans un ou deux ans ?
Ils feront tourner des programmes 32 bits qui ne pourront donc pas
exploiter la partie 64 bits des PC.
Hein ? Où donc as-tu vu que les futurs Mac/Intel ne seront pas 64
bits ?
qui obligera de nouveau à une migration des applications.
Pourquoi cela ?
Parce qu'un programme 32 bits ne peut pas exploiter les registres
supplémentaires disponibles en 64 bits sans une recompilation.
Alors pour toi "migration", c'est pareil que "recompilation" ? Les applis 32
bits G4 peuvent exploiter les registres 64 bits du G5 sans recompilation si
elles utilisent les bibliothèques Apple.
Dans un an, quand les versions 64 bits du matériel d'Apple
sortiront, il faudra recompiler.
Et alors ? C'est dur de cliquer ?
Et dans un an, qui te dit que Mac OS X/Intel ne sera pas
64 bits ?
Le gain en vitesse est à mon avis un argument commercial pour
refaire payer l'acheteur.
Là je pense que tu ne parles pas d'Apple, mais de société comme Quark, je
pense.
De plus, c'est extrêmement bloquant de se trimballer des applis 32
bits et 64 bits sur le même système :
Ah ? Faudra que j'en parle à mon NeXTSTEP qui gérer les quad-binaries sans
problème.
plusieurs versions des libs,
Si tu parles des sections dans un seul et même exécutable (comme
c'est déjà actuellement le cas dans Tiger, je le regrêt de te
l'apprendre), alors oui.
non compatibilité binaire entre les applis
Hein ? Quelle rapport entre les internes des applications et les
IPC ?
donc problèmes avec les plugins.
Cela dépend de l'architecture. Apple a indiqué que l'on pourrait très bien
avoir une appli Intel utilisant des plugins PPC à travers Rosetta. Alors toi
tu as peur des Plugins incompatibles Intel ? C'est vrai ?
Si Apple choisit un proc compatible EMT64,
c'est vraiment dommage de ne pas choisir directement une toolchain
Une "toolchain", whao. Tu voudrais qu'Apple abandonne Xcode juste parce que
le premier kit de développement d'un OS qui sortira dans un an, n'a pas
toutes les fonctionnalités que tu attends de gcc ?
Tu parles de quoi ? Des kits de développement ? Quelle rapport avec les Mac
qui sortirons dans un ou deux ans ?
Ils feront tourner des programmes 32 bits qui ne pourront donc pas
exploiter la partie 64 bits des PC.
Hein ? Où donc as-tu vu que les futurs Mac/Intel ne seront pas 64
bits ?
qui obligera de nouveau à une migration des applications.
Pourquoi cela ?
Parce qu'un programme 32 bits ne peut pas exploiter les registres
supplémentaires disponibles en 64 bits sans une recompilation.
Alors pour toi "migration", c'est pareil que "recompilation" ? Les applis 32
bits G4 peuvent exploiter les registres 64 bits du G5 sans recompilation si
elles utilisent les bibliothèques Apple.
Dans un an, quand les versions 64 bits du matériel d'Apple
sortiront, il faudra recompiler.
Et alors ? C'est dur de cliquer ?
Et dans un an, qui te dit que Mac OS X/Intel ne sera pas
64 bits ?
Le gain en vitesse est à mon avis un argument commercial pour
refaire payer l'acheteur.
Là je pense que tu ne parles pas d'Apple, mais de société comme Quark, je
pense.
De plus, c'est extrêmement bloquant de se trimballer des applis 32
bits et 64 bits sur le même système :
Ah ? Faudra que j'en parle à mon NeXTSTEP qui gérer les quad-binaries sans
problème.
plusieurs versions des libs,
Si tu parles des sections dans un seul et même exécutable (comme
c'est déjà actuellement le cas dans Tiger, je le regrêt de te
l'apprendre), alors oui.
non compatibilité binaire entre les applis
Hein ? Quelle rapport entre les internes des applications et les
IPC ?
donc problèmes avec les plugins.
Cela dépend de l'architecture. Apple a indiqué que l'on pourrait très bien
avoir une appli Intel utilisant des plugins PPC à travers Rosetta. Alors toi
tu as peur des Plugins incompatibles Intel ? C'est vrai ?
Si Apple choisit un proc compatible EMT64,
c'est vraiment dommage de ne pas choisir directement une toolchain
Une "toolchain", whao. Tu voudrais qu'Apple abandonne Xcode juste parce que
le premier kit de développement d'un OS qui sortira dans un an, n'a pas
toutes les fonctionnalités que tu attends de gcc ?
Oui. C'est le gros gain de l'architecture AMD 64. Le nombre de
registres bénéficient à toutes les applications.
Oui. C'est le gros gain de l'architecture AMD 64. Le nombre de
registres bénéficient à toutes les applications.
Oui. C'est le gros gain de l'architecture AMD 64. Le nombre de
registres bénéficient à toutes les applications.
In article ,
Vincent Bernat wrote:Oui. C'est le gros gain de l'architecture AMD 64. Le nombre de
registres bénéficient à toutes les applications.
Et c'est là qu'on regrette le Z80 et ses 2 jeux de registres. Ah ! Je
n'aurais jamais du me séparer de mon Amstrad CPC464...
Ok, je sors ;o)
In article <m38y1gu2si.fsf@neo.luffy.cx>,
Vincent Bernat <bernat@luffy.cx> wrote:
Oui. C'est le gros gain de l'architecture AMD 64. Le nombre de
registres bénéficient à toutes les applications.
Et c'est là qu'on regrette le Z80 et ses 2 jeux de registres. Ah ! Je
n'aurais jamais du me séparer de mon Amstrad CPC464...
Ok, je sors ;o)
In article ,
Vincent Bernat wrote:Oui. C'est le gros gain de l'architecture AMD 64. Le nombre de
registres bénéficient à toutes les applications.
Et c'est là qu'on regrette le Z80 et ses 2 jeux de registres. Ah ! Je
n'aurais jamais du me séparer de mon Amstrad CPC464...
Ok, je sors ;o)
OoO En cette soirée bien amorcée du samedi 11 juin 2005, vers 22:03,
Eric Lévénez disait:Tu parles de quoi ? Des kits de développement ? Quelle rapport avec les Mac
qui sortirons dans un ou deux ans ?
Ils feront tourner des programmes 32 bits qui ne pourront donc pas
exploiter la partie 64 bits des PC.
Hein ? Où donc as-tu vu que les futurs Mac/Intel ne seront pas 64
bits ?
Je ne dis pas qu'ils ne seront pas 64 bits, je dis qu'ils auront dans
un premier temps des programmes 32 bits à se mettre sous la dent.
qui obligera de nouveau à une migration des applications.
Pourquoi cela ?
Parce qu'un programme 32 bits ne peut pas exploiter les registres
supplémentaires disponibles en 64 bits sans une recompilation.
Alors pour toi "migration", c'est pareil que "recompilation" ? Les applis 32
bits G4 peuvent exploiter les registres 64 bits du G5 sans recompilation si
elles utilisent les bibliothèques Apple.
Une bibliothèque peut permettre d'abstraire certaines primitives. Elle
ne permettra jamais au programme d'accéder à un nombre supérieur de
registres, principale optimisation que l'on attend du passage 32 à 64
bits sur un PC. Elle ne permettra pas non plus d'utiliser l'espace
d'adressage du 64 bits. Les bibliothèques d'Apple sont essentiellement
destinées au calcul vectoriel et donc plus orientées vers
l'utilisation d'Altivec. Dans tous les cas, leur usage est très
spécifique :
Dans un an, quand les versions 64 bits du matériel d'Apple
sortiront, il faudra recompiler.
Et alors ? C'est dur de cliquer ?
Non, encore faut-il que le possesseur du code source le fasse.
Et
absolument rien ne dit qu'il le fera.
Par exemple, il voudra être payé
pour (donc nouvelle version payante).
Ou alors, il ne voudra tout
simplement pas acheter le kit de compilation à 999$. Ou encore, il
n'en aura pas le temps. Ou encore, le programme est abandonné.
Et dans un an, qui te dit que Mac OS X/Intel ne sera pas
64 bits ?
Cela fait quelques messages que j'évoque le problème de la migration
32 vers 64 bits. C'est sans doute parce que je pense qu'effectivement
Apple passera au 64 bits.
Le gain en vitesse est à mon avis un argument commercial pour
refaire payer l'acheteur.
Là je pense que tu ne parles pas d'Apple, mais de société comme Quark, je
pense.
Pas seulement. Apple pourrait bien commercialiser dans un premier
temps une version partiellement 64 bits de Mac OS X. Avec par exemple
iMovie en 32 bits. Et la prochaine version entièrement 64 bits sera
une autre version majeure. Passage à la caisse.
De plus, c'est extrêmement bloquant de se trimballer des applis 32
bits et 64 bits sur le même système :
Ah ? Faudra que j'en parle à mon NeXTSTEP qui gérer les quad-binaries sans
problème.
Ai-je dit que cela était impossible ?
plusieurs versions des libs,
Si tu parles des sections dans un seul et même exécutable (comme
c'est déjà actuellement le cas dans Tiger, je le regrêt de te
l'apprendre), alors oui.
Je parle des libs qui devront être fournies en 32 et en 64 bits. Tu
développes un produit pour Mac OS X Intel aujourd'hui en utilisant une
librairie d'un éditeur tierce. Tout est en 32 bits. Dans un an, tu
veux une appli 64 bits. Pas de chance, il faut attendre que l'éditeur
tierce sorte la version 64 bits de sa librairie.
D'autant que Apple ne communique absolument pas là-dessus, cela ne va
pas aider à la préparation du passage.
non compatibilité binaire entre les applis
Hein ? Quelle rapport entre les internes des applications et les
IPC ?
Gni ? Une appli 64 bits ne peut pas se greffer sur une appli 32 bits
au niveau binaire. Le cas le plus courant est celui des
plugins. C'est déjà le problème actuellement quand Apple explique
qu'une appli native qui utilise un plugin PPC devra tourner
entièrement sous Rosetta.donc problèmes avec les plugins.
Cela dépend de l'architecture. Apple a indiqué que l'on pourrait très bien
avoir une appli Intel utilisant des plugins PPC à travers Rosetta. Alors toi
tu as peur des Plugins incompatibles Intel ? C'est vrai ?
Tu as mal lu.
L'intégralité de l'application se met à tourner à
travers Rosetta. Je te renvoie directement sur le site d'Apple à ce
sujet :
<URL:http://developer.apple.com/documentation/MacOSX/Conceptual/universal_bina
ry/universal_binary_exec_a/chapter_7_section_4.html#//apple_ref/doc/uid/TP4000
2217-CH210-236785>Si Apple choisit un proc compatible EMT64,
c'est vraiment dommage de ne pas choisir directement une toolchain
Une "toolchain", whao. Tu voudrais qu'Apple abandonne Xcode juste parce que
le premier kit de développement d'un OS qui sortira dans un an, n'a pas
toutes les fonctionnalités que tu attends de gcc ?
Que je sache, la toolchain est toujours gcc. Xcode est un
environnement de développement qui inclut une toolchain. Et
actuellement, il contient bien entre autres une toolchain PPC 64. Il
me semble que tu t'emportes sans t'être réellement documenté.
La grosse différence entre le passage PPC vers Intel et IA-32 vers
x86-64, c'est que dans le second cas, il n'y aura pas besoin de
Rosetta. Tout le reste sera à refaire.
OoO En cette soirée bien amorcée du samedi 11 juin 2005, vers 22:03,
Eric Lévénez <eric@levenez.com> disait:
Tu parles de quoi ? Des kits de développement ? Quelle rapport avec les Mac
qui sortirons dans un ou deux ans ?
Ils feront tourner des programmes 32 bits qui ne pourront donc pas
exploiter la partie 64 bits des PC.
Hein ? Où donc as-tu vu que les futurs Mac/Intel ne seront pas 64
bits ?
Je ne dis pas qu'ils ne seront pas 64 bits, je dis qu'ils auront dans
un premier temps des programmes 32 bits à se mettre sous la dent.
qui obligera de nouveau à une migration des applications.
Pourquoi cela ?
Parce qu'un programme 32 bits ne peut pas exploiter les registres
supplémentaires disponibles en 64 bits sans une recompilation.
Alors pour toi "migration", c'est pareil que "recompilation" ? Les applis 32
bits G4 peuvent exploiter les registres 64 bits du G5 sans recompilation si
elles utilisent les bibliothèques Apple.
Une bibliothèque peut permettre d'abstraire certaines primitives. Elle
ne permettra jamais au programme d'accéder à un nombre supérieur de
registres, principale optimisation que l'on attend du passage 32 à 64
bits sur un PC. Elle ne permettra pas non plus d'utiliser l'espace
d'adressage du 64 bits. Les bibliothèques d'Apple sont essentiellement
destinées au calcul vectoriel et donc plus orientées vers
l'utilisation d'Altivec. Dans tous les cas, leur usage est très
spécifique :
Dans un an, quand les versions 64 bits du matériel d'Apple
sortiront, il faudra recompiler.
Et alors ? C'est dur de cliquer ?
Non, encore faut-il que le possesseur du code source le fasse.
Et
absolument rien ne dit qu'il le fera.
Par exemple, il voudra être payé
pour (donc nouvelle version payante).
Ou alors, il ne voudra tout
simplement pas acheter le kit de compilation à 999$. Ou encore, il
n'en aura pas le temps. Ou encore, le programme est abandonné.
Et dans un an, qui te dit que Mac OS X/Intel ne sera pas
64 bits ?
Cela fait quelques messages que j'évoque le problème de la migration
32 vers 64 bits. C'est sans doute parce que je pense qu'effectivement
Apple passera au 64 bits.
Le gain en vitesse est à mon avis un argument commercial pour
refaire payer l'acheteur.
Là je pense que tu ne parles pas d'Apple, mais de société comme Quark, je
pense.
Pas seulement. Apple pourrait bien commercialiser dans un premier
temps une version partiellement 64 bits de Mac OS X. Avec par exemple
iMovie en 32 bits. Et la prochaine version entièrement 64 bits sera
une autre version majeure. Passage à la caisse.
De plus, c'est extrêmement bloquant de se trimballer des applis 32
bits et 64 bits sur le même système :
Ah ? Faudra que j'en parle à mon NeXTSTEP qui gérer les quad-binaries sans
problème.
Ai-je dit que cela était impossible ?
plusieurs versions des libs,
Si tu parles des sections dans un seul et même exécutable (comme
c'est déjà actuellement le cas dans Tiger, je le regrêt de te
l'apprendre), alors oui.
Je parle des libs qui devront être fournies en 32 et en 64 bits. Tu
développes un produit pour Mac OS X Intel aujourd'hui en utilisant une
librairie d'un éditeur tierce. Tout est en 32 bits. Dans un an, tu
veux une appli 64 bits. Pas de chance, il faut attendre que l'éditeur
tierce sorte la version 64 bits de sa librairie.
D'autant que Apple ne communique absolument pas là-dessus, cela ne va
pas aider à la préparation du passage.
non compatibilité binaire entre les applis
Hein ? Quelle rapport entre les internes des applications et les
IPC ?
Gni ? Une appli 64 bits ne peut pas se greffer sur une appli 32 bits
au niveau binaire. Le cas le plus courant est celui des
plugins. C'est déjà le problème actuellement quand Apple explique
qu'une appli native qui utilise un plugin PPC devra tourner
entièrement sous Rosetta.
donc problèmes avec les plugins.
Cela dépend de l'architecture. Apple a indiqué que l'on pourrait très bien
avoir une appli Intel utilisant des plugins PPC à travers Rosetta. Alors toi
tu as peur des Plugins incompatibles Intel ? C'est vrai ?
Tu as mal lu.
L'intégralité de l'application se met à tourner à
travers Rosetta. Je te renvoie directement sur le site d'Apple à ce
sujet :
<URL:http://developer.apple.com/documentation/MacOSX/Conceptual/universal_bina
ry/universal_binary_exec_a/chapter_7_section_4.html#//apple_ref/doc/uid/TP4000
2217-CH210-236785>
Si Apple choisit un proc compatible EMT64,
c'est vraiment dommage de ne pas choisir directement une toolchain
Une "toolchain", whao. Tu voudrais qu'Apple abandonne Xcode juste parce que
le premier kit de développement d'un OS qui sortira dans un an, n'a pas
toutes les fonctionnalités que tu attends de gcc ?
Que je sache, la toolchain est toujours gcc. Xcode est un
environnement de développement qui inclut une toolchain. Et
actuellement, il contient bien entre autres une toolchain PPC 64. Il
me semble que tu t'emportes sans t'être réellement documenté.
La grosse différence entre le passage PPC vers Intel et IA-32 vers
x86-64, c'est que dans le second cas, il n'y aura pas besoin de
Rosetta. Tout le reste sera à refaire.
OoO En cette soirée bien amorcée du samedi 11 juin 2005, vers 22:03,
Eric Lévénez disait:Tu parles de quoi ? Des kits de développement ? Quelle rapport avec les Mac
qui sortirons dans un ou deux ans ?
Ils feront tourner des programmes 32 bits qui ne pourront donc pas
exploiter la partie 64 bits des PC.
Hein ? Où donc as-tu vu que les futurs Mac/Intel ne seront pas 64
bits ?
Je ne dis pas qu'ils ne seront pas 64 bits, je dis qu'ils auront dans
un premier temps des programmes 32 bits à se mettre sous la dent.
qui obligera de nouveau à une migration des applications.
Pourquoi cela ?
Parce qu'un programme 32 bits ne peut pas exploiter les registres
supplémentaires disponibles en 64 bits sans une recompilation.
Alors pour toi "migration", c'est pareil que "recompilation" ? Les applis 32
bits G4 peuvent exploiter les registres 64 bits du G5 sans recompilation si
elles utilisent les bibliothèques Apple.
Une bibliothèque peut permettre d'abstraire certaines primitives. Elle
ne permettra jamais au programme d'accéder à un nombre supérieur de
registres, principale optimisation que l'on attend du passage 32 à 64
bits sur un PC. Elle ne permettra pas non plus d'utiliser l'espace
d'adressage du 64 bits. Les bibliothèques d'Apple sont essentiellement
destinées au calcul vectoriel et donc plus orientées vers
l'utilisation d'Altivec. Dans tous les cas, leur usage est très
spécifique :
Dans un an, quand les versions 64 bits du matériel d'Apple
sortiront, il faudra recompiler.
Et alors ? C'est dur de cliquer ?
Non, encore faut-il que le possesseur du code source le fasse.
Et
absolument rien ne dit qu'il le fera.
Par exemple, il voudra être payé
pour (donc nouvelle version payante).
Ou alors, il ne voudra tout
simplement pas acheter le kit de compilation à 999$. Ou encore, il
n'en aura pas le temps. Ou encore, le programme est abandonné.
Et dans un an, qui te dit que Mac OS X/Intel ne sera pas
64 bits ?
Cela fait quelques messages que j'évoque le problème de la migration
32 vers 64 bits. C'est sans doute parce que je pense qu'effectivement
Apple passera au 64 bits.
Le gain en vitesse est à mon avis un argument commercial pour
refaire payer l'acheteur.
Là je pense que tu ne parles pas d'Apple, mais de société comme Quark, je
pense.
Pas seulement. Apple pourrait bien commercialiser dans un premier
temps une version partiellement 64 bits de Mac OS X. Avec par exemple
iMovie en 32 bits. Et la prochaine version entièrement 64 bits sera
une autre version majeure. Passage à la caisse.
De plus, c'est extrêmement bloquant de se trimballer des applis 32
bits et 64 bits sur le même système :
Ah ? Faudra que j'en parle à mon NeXTSTEP qui gérer les quad-binaries sans
problème.
Ai-je dit que cela était impossible ?
plusieurs versions des libs,
Si tu parles des sections dans un seul et même exécutable (comme
c'est déjà actuellement le cas dans Tiger, je le regrêt de te
l'apprendre), alors oui.
Je parle des libs qui devront être fournies en 32 et en 64 bits. Tu
développes un produit pour Mac OS X Intel aujourd'hui en utilisant une
librairie d'un éditeur tierce. Tout est en 32 bits. Dans un an, tu
veux une appli 64 bits. Pas de chance, il faut attendre que l'éditeur
tierce sorte la version 64 bits de sa librairie.
D'autant que Apple ne communique absolument pas là-dessus, cela ne va
pas aider à la préparation du passage.
non compatibilité binaire entre les applis
Hein ? Quelle rapport entre les internes des applications et les
IPC ?
Gni ? Une appli 64 bits ne peut pas se greffer sur une appli 32 bits
au niveau binaire. Le cas le plus courant est celui des
plugins. C'est déjà le problème actuellement quand Apple explique
qu'une appli native qui utilise un plugin PPC devra tourner
entièrement sous Rosetta.donc problèmes avec les plugins.
Cela dépend de l'architecture. Apple a indiqué que l'on pourrait très bien
avoir une appli Intel utilisant des plugins PPC à travers Rosetta. Alors toi
tu as peur des Plugins incompatibles Intel ? C'est vrai ?
Tu as mal lu.
L'intégralité de l'application se met à tourner à
travers Rosetta. Je te renvoie directement sur le site d'Apple à ce
sujet :
<URL:http://developer.apple.com/documentation/MacOSX/Conceptual/universal_bina
ry/universal_binary_exec_a/chapter_7_section_4.html#//apple_ref/doc/uid/TP4000
2217-CH210-236785>Si Apple choisit un proc compatible EMT64,
c'est vraiment dommage de ne pas choisir directement une toolchain
Une "toolchain", whao. Tu voudrais qu'Apple abandonne Xcode juste parce que
le premier kit de développement d'un OS qui sortira dans un an, n'a pas
toutes les fonctionnalités que tu attends de gcc ?
Que je sache, la toolchain est toujours gcc. Xcode est un
environnement de développement qui inclut une toolchain. Et
actuellement, il contient bien entre autres une toolchain PPC 64. Il
me semble que tu t'emportes sans t'être réellement documenté.
La grosse différence entre le passage PPC vers Intel et IA-32 vers
x86-64, c'est que dans le second cas, il n'y aura pas besoin de
Rosetta. Tout le reste sera à refaire.
"Gilles Vollant" wrote:Cela rend le portage d'application plus complexe. En effet, un source C
peut
parfois être dépendant de l'"endianness"
...tu es sur de ce que tu avance là ?
assembleur d'accord, mais c, je ne vois pas
"Gilles Vollant" <info@winimage.com> wrote:
Cela rend le portage d'application plus complexe. En effet, un source C
peut
parfois être dépendant de l'"endianness"
...tu es sur de ce que tu avance là ?
assembleur d'accord, mais c, je ne vois pas
"Gilles Vollant" wrote:Cela rend le portage d'application plus complexe. En effet, un source C
peut
parfois être dépendant de l'"endianness"
...tu es sur de ce que tu avance là ?
assembleur d'accord, mais c, je ne vois pas
Je ne dis pas qu'ils ne seront pas 64 bits, je dis qu'ils auront dans
un premier temps des programmes 32 bits à se mettre sous la dent.
Mais tu affirmes cela juste parce que le kit de développement d'un système,
a, un an avant la sortie du premier système, que du 32 bits.
Les bibliothèques d'Apple ne permettent pas, bien sûr ,d'optimiser
tout un programme, mais j'expliquais juste qu'une application
pouvait être optimisée sans recompilation, même si cette
optimisation ne vaut pas une recompilation (qui est une action
triviale).
Dans un an, quand les versions 64 bits du matériel d'Apple
sortiront, il faudra recompiler.
Et alors ? C'est dur de cliquer ?
Non, encore faut-il que le possesseur du code source le fasse.
Si un développeur commence aujourd'hui le portage d'un code pour Mac OS
X/Intel, c'est qu'il veut sortir son code (dans un an), et donc il cliquera
sur le bouton de recompilation dans un an moins un jour.
Par exemple, il voudra être payé pour (donc nouvelle version
payante).
Argument totalement hors de propos, on parle d'optimisation 32 vs 64 bits
pour Mac OS X/Intel lié au kit de développement actuel.
Et dans un an, qui te dit que Mac OS X/Intel ne sera pas
64 bits ?
Cela fait quelques messages que j'évoque le problème de la migration
32 vers 64 bits. C'est sans doute parce que je pense qu'effectivement
Apple passera au 64 bits.
Mais il y a aussi une chance qu'Apple saute le mode 32 bits Intel.
Pas seulement. Apple pourrait bien commercialiser dans un premier
temps une version partiellement 64 bits de Mac OS X. Avec par exemple
iMovie en 32 bits. Et la prochaine version entièrement 64 bits sera
une autre version majeure. Passage à la caisse.
Encore des suppositions.
plusieurs versions des libs,
Si tu parles des sections dans un seul et même exécutable (comme
c'est déjà actuellement le cas dans Tiger, je le regrêt de te
l'apprendre), alors oui.
Je parle des libs qui devront être fournies en 32 et en 64 bits. Tu
développes un produit pour Mac OS X Intel aujourd'hui en utilisant une
librairie d'un éditeur tierce. Tout est en 32 bits. Dans un an, tu
veux une appli 64 bits. Pas de chance, il faut attendre que l'éditeur
tierce sorte la version 64 bits de sa librairie.
Aucun éditeur ne sortira un soft pour Mac OS X/Intel avant la sortie
officielle de Mac OS X/Intel car Apple peut changer un détail au dernier
moment qui fera que le programme ne sera pas compatible. Voir par exemple
Rhapsody.
D'autant que Apple ne communique absolument pas là-dessus, cela ne va
pas aider à la préparation du passage.
Parce que un an, c'est long, et que beaucoup de choses peuvent changer d'ici
là du côté d'Apple et d'Intel.
Une "toolchain", whao. Tu voudrais qu'Apple abandonne Xcode juste parce que
le premier kit de développement d'un OS qui sortira dans un an, n'a pas
toutes les fonctionnalités que tu attends de gcc ?
Que je sache, la toolchain est toujours gcc. Xcode est un
environnement de développement qui inclut une toolchain. Et
actuellement, il contient bien entre autres une toolchain PPC 64. Il
me semble que tu t'emportes sans t'être réellement documenté.
"toochain" ne veut rien dire et pas spécifiquement "gcc".
Bien sûr ta "toolchain" gcc sait compiler en PPC 64, qui en
douterait ? La cross-compilation avec gcc existe depuis pratiquement
l'origine de cette "toolchain". Et quelle "toochain" proposes-tu qui
fasse de l'Objective-C, du C, du C++, de l'Objective-C++ sur PPC 32,
64, et Intel 32 et 64 et qui sait générer du code Mach-O ?
Le problème du passage en mode 64 bits sur Intel ne vient en rien de
la "toolchain" gcc, mais juste de Mac OS X lui-même (de ses
programmes et bibliothèques).
Je ne dis pas qu'ils ne seront pas 64 bits, je dis qu'ils auront dans
un premier temps des programmes 32 bits à se mettre sous la dent.
Mais tu affirmes cela juste parce que le kit de développement d'un système,
a, un an avant la sortie du premier système, que du 32 bits.
Les bibliothèques d'Apple ne permettent pas, bien sûr ,d'optimiser
tout un programme, mais j'expliquais juste qu'une application
pouvait être optimisée sans recompilation, même si cette
optimisation ne vaut pas une recompilation (qui est une action
triviale).
Dans un an, quand les versions 64 bits du matériel d'Apple
sortiront, il faudra recompiler.
Et alors ? C'est dur de cliquer ?
Non, encore faut-il que le possesseur du code source le fasse.
Si un développeur commence aujourd'hui le portage d'un code pour Mac OS
X/Intel, c'est qu'il veut sortir son code (dans un an), et donc il cliquera
sur le bouton de recompilation dans un an moins un jour.
Par exemple, il voudra être payé pour (donc nouvelle version
payante).
Argument totalement hors de propos, on parle d'optimisation 32 vs 64 bits
pour Mac OS X/Intel lié au kit de développement actuel.
Et dans un an, qui te dit que Mac OS X/Intel ne sera pas
64 bits ?
Cela fait quelques messages que j'évoque le problème de la migration
32 vers 64 bits. C'est sans doute parce que je pense qu'effectivement
Apple passera au 64 bits.
Mais il y a aussi une chance qu'Apple saute le mode 32 bits Intel.
Pas seulement. Apple pourrait bien commercialiser dans un premier
temps une version partiellement 64 bits de Mac OS X. Avec par exemple
iMovie en 32 bits. Et la prochaine version entièrement 64 bits sera
une autre version majeure. Passage à la caisse.
Encore des suppositions.
plusieurs versions des libs,
Si tu parles des sections dans un seul et même exécutable (comme
c'est déjà actuellement le cas dans Tiger, je le regrêt de te
l'apprendre), alors oui.
Je parle des libs qui devront être fournies en 32 et en 64 bits. Tu
développes un produit pour Mac OS X Intel aujourd'hui en utilisant une
librairie d'un éditeur tierce. Tout est en 32 bits. Dans un an, tu
veux une appli 64 bits. Pas de chance, il faut attendre que l'éditeur
tierce sorte la version 64 bits de sa librairie.
Aucun éditeur ne sortira un soft pour Mac OS X/Intel avant la sortie
officielle de Mac OS X/Intel car Apple peut changer un détail au dernier
moment qui fera que le programme ne sera pas compatible. Voir par exemple
Rhapsody.
D'autant que Apple ne communique absolument pas là-dessus, cela ne va
pas aider à la préparation du passage.
Parce que un an, c'est long, et que beaucoup de choses peuvent changer d'ici
là du côté d'Apple et d'Intel.
Une "toolchain", whao. Tu voudrais qu'Apple abandonne Xcode juste parce que
le premier kit de développement d'un OS qui sortira dans un an, n'a pas
toutes les fonctionnalités que tu attends de gcc ?
Que je sache, la toolchain est toujours gcc. Xcode est un
environnement de développement qui inclut une toolchain. Et
actuellement, il contient bien entre autres une toolchain PPC 64. Il
me semble que tu t'emportes sans t'être réellement documenté.
"toochain" ne veut rien dire et pas spécifiquement "gcc".
Bien sûr ta "toolchain" gcc sait compiler en PPC 64, qui en
douterait ? La cross-compilation avec gcc existe depuis pratiquement
l'origine de cette "toolchain". Et quelle "toochain" proposes-tu qui
fasse de l'Objective-C, du C, du C++, de l'Objective-C++ sur PPC 32,
64, et Intel 32 et 64 et qui sait générer du code Mach-O ?
Le problème du passage en mode 64 bits sur Intel ne vient en rien de
la "toolchain" gcc, mais juste de Mac OS X lui-même (de ses
programmes et bibliothèques).
Je ne dis pas qu'ils ne seront pas 64 bits, je dis qu'ils auront dans
un premier temps des programmes 32 bits à se mettre sous la dent.
Mais tu affirmes cela juste parce que le kit de développement d'un système,
a, un an avant la sortie du premier système, que du 32 bits.
Les bibliothèques d'Apple ne permettent pas, bien sûr ,d'optimiser
tout un programme, mais j'expliquais juste qu'une application
pouvait être optimisée sans recompilation, même si cette
optimisation ne vaut pas une recompilation (qui est une action
triviale).
Dans un an, quand les versions 64 bits du matériel d'Apple
sortiront, il faudra recompiler.
Et alors ? C'est dur de cliquer ?
Non, encore faut-il que le possesseur du code source le fasse.
Si un développeur commence aujourd'hui le portage d'un code pour Mac OS
X/Intel, c'est qu'il veut sortir son code (dans un an), et donc il cliquera
sur le bouton de recompilation dans un an moins un jour.
Par exemple, il voudra être payé pour (donc nouvelle version
payante).
Argument totalement hors de propos, on parle d'optimisation 32 vs 64 bits
pour Mac OS X/Intel lié au kit de développement actuel.
Et dans un an, qui te dit que Mac OS X/Intel ne sera pas
64 bits ?
Cela fait quelques messages que j'évoque le problème de la migration
32 vers 64 bits. C'est sans doute parce que je pense qu'effectivement
Apple passera au 64 bits.
Mais il y a aussi une chance qu'Apple saute le mode 32 bits Intel.
Pas seulement. Apple pourrait bien commercialiser dans un premier
temps une version partiellement 64 bits de Mac OS X. Avec par exemple
iMovie en 32 bits. Et la prochaine version entièrement 64 bits sera
une autre version majeure. Passage à la caisse.
Encore des suppositions.
plusieurs versions des libs,
Si tu parles des sections dans un seul et même exécutable (comme
c'est déjà actuellement le cas dans Tiger, je le regrêt de te
l'apprendre), alors oui.
Je parle des libs qui devront être fournies en 32 et en 64 bits. Tu
développes un produit pour Mac OS X Intel aujourd'hui en utilisant une
librairie d'un éditeur tierce. Tout est en 32 bits. Dans un an, tu
veux une appli 64 bits. Pas de chance, il faut attendre que l'éditeur
tierce sorte la version 64 bits de sa librairie.
Aucun éditeur ne sortira un soft pour Mac OS X/Intel avant la sortie
officielle de Mac OS X/Intel car Apple peut changer un détail au dernier
moment qui fera que le programme ne sera pas compatible. Voir par exemple
Rhapsody.
D'autant que Apple ne communique absolument pas là-dessus, cela ne va
pas aider à la préparation du passage.
Parce que un an, c'est long, et que beaucoup de choses peuvent changer d'ici
là du côté d'Apple et d'Intel.
Une "toolchain", whao. Tu voudrais qu'Apple abandonne Xcode juste parce que
le premier kit de développement d'un OS qui sortira dans un an, n'a pas
toutes les fonctionnalités que tu attends de gcc ?
Que je sache, la toolchain est toujours gcc. Xcode est un
environnement de développement qui inclut une toolchain. Et
actuellement, il contient bien entre autres une toolchain PPC 64. Il
me semble que tu t'emportes sans t'être réellement documenté.
"toochain" ne veut rien dire et pas spécifiquement "gcc".
Bien sûr ta "toolchain" gcc sait compiler en PPC 64, qui en
douterait ? La cross-compilation avec gcc existe depuis pratiquement
l'origine de cette "toolchain". Et quelle "toochain" proposes-tu qui
fasse de l'Objective-C, du C, du C++, de l'Objective-C++ sur PPC 32,
64, et Intel 32 et 64 et qui sait générer du code Mach-O ?
Le problème du passage en mode 64 bits sur Intel ne vient en rien de
la "toolchain" gcc, mais juste de Mac OS X lui-même (de ses
programmes et bibliothèques).
