2 questions sur la migration Intel (endianness et 64 bits)
36 réponses
Gilles Vollant
Je me pose deux questions au sujet du portage de MacOS sur processeur Intel
1) Jusqu'à maintenant, les processeurs Macintosh (les 680x0 comme les
PowerPC dans le mode utilisé par macos) sont big endian, et le x86 est
little endian
Cela rend le portage d'application plus complexe. En effet, un source C peut
parfois être dépendant de l'"endianness"
pour plus de détails:
http://www.nationmaster.com/encyclopedia/Endianness
2) Apple utilisera-t-il le mode 64 bits des x86 (EM64T) ? Cela paraiterait
logique, puisque cela éviterais une nouvelle migration à relativement courte
échéance.
Je serai intéressé par un pointeur sur les portages réalisés. La seule grosse application portée sur place dont j'ai eu vent est Firefox, qui tourne déjà sur au moins 12 architectures différentes. On peut sans doute trouver plus difficile à porter.
Voir le message que j'ai posté Vendredi :
Message-ID: <1gxybhg.7culd1t7z1q7N%
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime <http://www.garage-video.com/> Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
Vincent Bernat <bernat@luffy.cx> wrote:
Je serai intéressé par un pointeur sur les portages réalisés. La seule
grosse application portée sur place dont j'ai eu vent est Firefox, qui
tourne déjà sur au moins 12 architectures différentes. On peut sans
doute trouver plus difficile à porter.
Je serai intéressé par un pointeur sur les portages réalisés. La seule grosse application portée sur place dont j'ai eu vent est Firefox, qui tourne déjà sur au moins 12 architectures différentes. On peut sans doute trouver plus difficile à porter.
Voir le message que j'ai posté Vendredi :
Message-ID: <1gxybhg.7culd1t7z1q7N%
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime <http://www.garage-video.com/> Clarus, the DogCow <http://clarus.chez.tiscali.fr/>
Vincent Bernat
OoO En cette matinée ensoleillée du mardi 14 juin 2005, vers 09:34, Stephane Madrau disait:
Au niveau compilation, le passage 1->2 est plus simple car généralement, il y a des chances que ça compile. Au niveau de l'exécution, c'est l'inverse à cause des problèmes d'endianess ou du fait qu'un caractère soit signé ou non par défaut.
Une fois ces problèmes réglés lors d'un passage PPC->i386, il n'y aura plus à les régler pour refaire une version i686-64. C'est pour ça que je vois le portage éventuel vers d'autres architectures encore plus facile, une fois celui-ci fait.
Ce ne sont pas les mêmes problèmes, bien que je n'en sois pas sûr. Il me semble que le signe de char reste identique sur AMD 64. Pour l'endianess, c'est le même. Mais je t'accorde qu'il y aura aussi eu une phase d'assainissement du code qui aidera au portage. -- /* After several hours of tedious analysis, the following hash * function won. Do not mess with it... -DaveM */ 2.2.16 /usr/src/linux/fs/buffer.c
OoO En cette matinée ensoleillée du mardi 14 juin 2005, vers 09:34,
Stephane Madrau <stephane@madrau.com> disait:
Au niveau compilation, le passage 1->2 est plus simple car
généralement, il y a des chances que ça compile. Au niveau de
l'exécution, c'est l'inverse à cause des problèmes d'endianess ou du
fait qu'un caractère soit signé ou non par défaut.
Une fois ces problèmes réglés lors d'un passage PPC->i386, il n'y aura
plus à les régler pour refaire une version i686-64. C'est pour ça que je
vois le portage éventuel vers d'autres architectures encore plus facile,
une fois celui-ci fait.
Ce ne sont pas les mêmes problèmes, bien que je n'en sois pas sûr. Il
me semble que le signe de char reste identique sur AMD 64. Pour
l'endianess, c'est le même. Mais je t'accorde qu'il y aura aussi eu
une phase d'assainissement du code qui aidera au portage.
--
/* After several hours of tedious analysis, the following hash
* function won. Do not mess with it... -DaveM
*/
2.2.16 /usr/src/linux/fs/buffer.c
OoO En cette matinée ensoleillée du mardi 14 juin 2005, vers 09:34, Stephane Madrau disait:
Au niveau compilation, le passage 1->2 est plus simple car généralement, il y a des chances que ça compile. Au niveau de l'exécution, c'est l'inverse à cause des problèmes d'endianess ou du fait qu'un caractère soit signé ou non par défaut.
Une fois ces problèmes réglés lors d'un passage PPC->i386, il n'y aura plus à les régler pour refaire une version i686-64. C'est pour ça que je vois le portage éventuel vers d'autres architectures encore plus facile, une fois celui-ci fait.
Ce ne sont pas les mêmes problèmes, bien que je n'en sois pas sûr. Il me semble que le signe de char reste identique sur AMD 64. Pour l'endianess, c'est le même. Mais je t'accorde qu'il y aura aussi eu une phase d'assainissement du code qui aidera au portage. -- /* After several hours of tedious analysis, the following hash * function won. Do not mess with it... -DaveM */ 2.2.16 /usr/src/linux/fs/buffer.c
Stephane Madrau
Benoit Leraillez wrote:
Surtout que si tu n'as qu'un shareware à tester il te suffira de croiser un développeur qui veut bien que tu viennes jeter un oeil sur la machine pour que tu vérifies le tout.
Reste à croiser un développeur, sur MacOS X qui plus est. ça ne court pas les rues ici (ou alors ils se cachent)...
Maintenant reste à savoir quelles sont les conditions exactes du contrat Apple en ce qui concerne cette location.
N'étant même pas membre Select, je n'en ai aucune idée, les contrats de location doivent eux même être sous NDA.
-- Stéphane
Benoit Leraillez wrote:
Surtout que si tu n'as qu'un shareware à tester il te suffira de
croiser un développeur qui veut bien que tu viennes jeter un oeil sur la
machine pour que tu vérifies le tout.
Reste à croiser un développeur, sur MacOS X qui plus est. ça ne court
pas les rues ici (ou alors ils se cachent)...
Maintenant reste à savoir quelles
sont les conditions exactes du contrat Apple en ce qui concerne cette
location.
N'étant même pas membre Select, je n'en ai aucune idée, les contrats de
location doivent eux même être sous NDA.
Surtout que si tu n'as qu'un shareware à tester il te suffira de croiser un développeur qui veut bien que tu viennes jeter un oeil sur la machine pour que tu vérifies le tout.
Reste à croiser un développeur, sur MacOS X qui plus est. ça ne court pas les rues ici (ou alors ils se cachent)...
Maintenant reste à savoir quelles sont les conditions exactes du contrat Apple en ce qui concerne cette location.
N'étant même pas membre Select, je n'en ai aucune idée, les contrats de location doivent eux même être sous NDA.
-- Stéphane
Gilles Vollant
"Eric L é v é nez" a écrit dans le message de news: BED3855A.397AC%
Bien sûr que si. Si actuellement le portage PPC vers x86 se fait en un clic de souris, ce n'est pas grâce aux développeurs, c'est uniquement grâce à NeXT/Apple. Apple a fait tout le travail, les développeurs utilisent ce travail. Le portage de l'application du développeur, c'est trivial si le développeur a bien conçu son programme et isolé les parties non portables, comme cela doit être enseigné dans toute école d'info.
Dans la pratique, avec la neccessité de retester sur chaque plateforme (et dans les grands projets logiciels, le test est important), chaque plateforme coute.
On voit la même chose dans le monde Windows. De nombreuse applications ecrite en C++ avec le compilateur Microsoft n'ont pas été porté sur NT4 Risc en leur temps (Dec Alpha, Mips R4000 et... Windows NT pour PowerPC) ou sur Itanium actuellement parce ce que le marché est jugé trop petit par rapport au coût de test/validation.
"Eric L é v é nez" <eric@levenez.com> a écrit dans le message de news:
BED3855A.397AC%eric@levenez.com...
Bien sûr que si. Si actuellement le portage PPC vers x86 se fait en un
clic
de souris, ce n'est pas grâce aux développeurs, c'est uniquement grâce à
NeXT/Apple. Apple a fait tout le travail, les développeurs utilisent ce
travail. Le portage de l'application du développeur, c'est trivial si le
développeur a bien conçu son programme et isolé les parties non portables,
comme cela doit être enseigné dans toute école d'info.
Dans la pratique, avec la neccessité de retester sur chaque plateforme (et
dans les grands projets logiciels, le test est important), chaque plateforme
coute.
On voit la même chose dans le monde Windows. De nombreuse applications
ecrite en C++ avec le compilateur Microsoft n'ont pas été porté sur NT4 Risc
en leur temps (Dec Alpha, Mips R4000 et... Windows NT pour PowerPC) ou sur
Itanium actuellement parce ce que le marché est jugé trop petit par rapport
au coût de test/validation.
"Eric L é v é nez" a écrit dans le message de news: BED3855A.397AC%
Bien sûr que si. Si actuellement le portage PPC vers x86 se fait en un clic de souris, ce n'est pas grâce aux développeurs, c'est uniquement grâce à NeXT/Apple. Apple a fait tout le travail, les développeurs utilisent ce travail. Le portage de l'application du développeur, c'est trivial si le développeur a bien conçu son programme et isolé les parties non portables, comme cela doit être enseigné dans toute école d'info.
Dans la pratique, avec la neccessité de retester sur chaque plateforme (et dans les grands projets logiciels, le test est important), chaque plateforme coute.
On voit la même chose dans le monde Windows. De nombreuse applications ecrite en C++ avec le compilateur Microsoft n'ont pas été porté sur NT4 Risc en leur temps (Dec Alpha, Mips R4000 et... Windows NT pour PowerPC) ou sur Itanium actuellement parce ce que le marché est jugé trop petit par rapport au coût de test/validation.
Lamballais Pierre-Louis
kurtz le pirate wrote:
"Gilles Vollant" wrote:
Cela rend le portage d'application plus complexe. En effet, un source C peut parfois être dépendant de l'"endianness" Bonjour,
Cela commence a faire quelques mois que je n'ai pas touché à l'ASM PPC, mais votre discution a reveillé quelques neurones. :-) Je ne sais pas si c'est toujours valable sur les "derniers proc" mais le PPC dans son architecture de base, supporte à la fois le "big" et le "little" endian. On fait passer automatiquement le processeur d'un mode à l'autre en réglant le bit LM du registre HIDO. Etant donné que c'était défini dans l'architecture PowerPC, je pense que ça doit toujours exister dans le G4 et le G5.
Amitiés à tous PL
kurtz le pirate <kurtzlepirate@yahoo.fr> wrote:
"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"
Bonjour,
Cela commence a faire quelques mois que je n'ai pas touché à l'ASM PPC,
mais votre discution a reveillé quelques neurones. :-)
Je ne sais pas si c'est toujours valable sur les "derniers proc" mais le
PPC dans son architecture de base, supporte à la fois le "big" et le
"little" endian.
On fait passer automatiquement le processeur d'un mode à l'autre en
réglant le bit LM du registre HIDO. Etant donné que c'était défini dans
l'architecture PowerPC, je pense que ça doit toujours exister dans le G4
et le G5.
Cela rend le portage d'application plus complexe. En effet, un source C peut parfois être dépendant de l'"endianness" Bonjour,
Cela commence a faire quelques mois que je n'ai pas touché à l'ASM PPC, mais votre discution a reveillé quelques neurones. :-) Je ne sais pas si c'est toujours valable sur les "derniers proc" mais le PPC dans son architecture de base, supporte à la fois le "big" et le "little" endian. On fait passer automatiquement le processeur d'un mode à l'autre en réglant le bit LM du registre HIDO. Etant donné que c'était défini dans l'architecture PowerPC, je pense que ça doit toujours exister dans le G4 et le G5.
Amitiés à tous PL
Gilles Vollant
"Lamballais Pierre-Louis" a écrit dans le message de news: 42c8dc20$0$25036$
Je ne sais pas si c'est toujours valable sur les "derniers proc" mais le PPC dans son architecture de base, supporte à la fois le "big" et le "little" endian. C'est ce qui a permi d'avoir un Windows NT 4 pour PowerPC il y a quelques
années
On fait passer automatiquement le processeur d'un mode à l'autre en réglant le bit LM du registre HIDO. Etant donné que c'était défini dans l'architecture PowerPC, je pense que ça doit toujours exister dans le G4 et le G5.
http://mindprod.com/jgloss/endian.html " The endian-agnostic pseudo-little-endian mode has been dropped. This caused Microsoft Virtual PC a major headache in emulating the Pentium on a Mac Power PC G5. "
http://en.wikipedia.org/wiki/PowerPC " Support for operation as in both Big-Endian and Little-Endian modes; the PowerPC can switch from one mode to the other at run-time (see below). This feature is not supported in the PowerPC G5. (This was the reason why Virtual PC took so long to be made functional on G5-based Macintoshes.) "
"Lamballais Pierre-Louis" <pl.lamballais@flashover.fr> a écrit dans le
message de news: 42c8dc20$0$25036$8fcfb975@news.wanadoo.fr...
Je ne sais pas si c'est toujours valable sur les "derniers proc" mais le
PPC dans son architecture de base, supporte à la fois le "big" et le
"little" endian.
C'est ce qui a permi d'avoir un Windows NT 4 pour PowerPC il y a quelques
années
On fait passer automatiquement le processeur d'un mode à l'autre en
réglant le bit LM du registre HIDO. Etant donné que c'était défini dans
l'architecture PowerPC, je pense que ça doit toujours exister dans le G4
et le G5.
http://mindprod.com/jgloss/endian.html
" The endian-agnostic pseudo-little-endian mode has been dropped. This
caused Microsoft Virtual PC a major headache in emulating the Pentium on a
Mac Power PC G5. "
http://en.wikipedia.org/wiki/PowerPC
" Support for operation as in both Big-Endian and Little-Endian modes; the
PowerPC can switch from one mode to the other at run-time (see below). This
feature is not supported in the PowerPC G5. (This was the reason why Virtual
PC took so long to be made functional on G5-based Macintoshes.) "
"Lamballais Pierre-Louis" a écrit dans le message de news: 42c8dc20$0$25036$
Je ne sais pas si c'est toujours valable sur les "derniers proc" mais le PPC dans son architecture de base, supporte à la fois le "big" et le "little" endian. C'est ce qui a permi d'avoir un Windows NT 4 pour PowerPC il y a quelques
années
On fait passer automatiquement le processeur d'un mode à l'autre en réglant le bit LM du registre HIDO. Etant donné que c'était défini dans l'architecture PowerPC, je pense que ça doit toujours exister dans le G4 et le G5.
http://mindprod.com/jgloss/endian.html " The endian-agnostic pseudo-little-endian mode has been dropped. This caused Microsoft Virtual PC a major headache in emulating the Pentium on a Mac Power PC G5. "
http://en.wikipedia.org/wiki/PowerPC " Support for operation as in both Big-Endian and Little-Endian modes; the PowerPC can switch from one mode to the other at run-time (see below). This feature is not supported in the PowerPC G5. (This was the reason why Virtual PC took so long to be made functional on G5-based Macintoshes.) "
