On Mon, 08 Sep 2008 23:08:35 +0200, olivier wrote:
Si tous le monde se méttait à bricoler, OS X serait dévalorisé, et ressemblerait plus à un truc de bricoleur comme le pingouin fou
Ca c'est sûr. Il pourrait même y avoir des trucs de bricoleur comme du bsd dedans, c'est dingue.
-- Ed
pehache-tolai
"" a écrit dans le message de news: 48c399a1$0$29584$
N'importe quoi ! a ce moment là, retourne sur un OS 16 bits. justement une application de calcul en 64 bits est capable de tourner bien plus vite qu'en 32 bits.
Euh, non...
-- pehache http://pehache.free.fr/public.html
"Fr@d" <plumachau@free.fr> a écrit dans le message de news:
48c399a1$0$29584$426a74cc@news.free.fr
N'importe quoi ! a ce moment là, retourne sur un OS 16 bits. justement
une application de calcul en 64 bits est capable de tourner bien plus
vite qu'en 32 bits.
"" a écrit dans le message de news: 48c399a1$0$29584$
N'importe quoi ! a ce moment là, retourne sur un OS 16 bits. justement une application de calcul en 64 bits est capable de tourner bien plus vite qu'en 32 bits.
Euh, non...
-- pehache http://pehache.free.fr/public.html
pehache-tolai
"Pascal Hambourg" a écrit dans le message de news: ga14ls$1np6$
Salut,
a écrit :
une application de calcul en 64 bits est capable de tourner bien plus vite qu'en 32 bits.
Ça n'a rien à voir avec l'OS mais avec la taille des registres de données, sauf si le calcul mobilise des quantités de données de plusieurs giga-octets. A titre de comparaison j'utilisais les registres de données 32 bits du 386 dans des applications 16 bits sous MS-DOS.
De même, les applis 32 bits utilisent sans problème les registres flottants 80 bits des processeurs Intel.
-- pehache http://pehache.free.fr/public.html
"Pascal Hambourg" <boite-a-spam@plouf.fr.eu.org> a écrit dans le
message de news: ga14ls$1np6$1@biggoron.nerim.net
Salut,
Fr@d a écrit :
une application de calcul en 64 bits est capable de tourner bien plus
vite qu'en 32 bits.
Ça n'a rien à voir avec l'OS mais avec la taille des registres de
données, sauf si le calcul mobilise des quantités de données de
plusieurs giga-octets. A titre de comparaison j'utilisais les
registres de données 32 bits du 386 dans des applications 16 bits
sous MS-DOS.
De même, les applis 32 bits utilisent sans problème les registres flottants
80 bits des processeurs Intel.
"Pascal Hambourg" a écrit dans le message de news: ga14ls$1np6$
Salut,
a écrit :
une application de calcul en 64 bits est capable de tourner bien plus vite qu'en 32 bits.
Ça n'a rien à voir avec l'OS mais avec la taille des registres de données, sauf si le calcul mobilise des quantités de données de plusieurs giga-octets. A titre de comparaison j'utilisais les registres de données 32 bits du 386 dans des applications 16 bits sous MS-DOS.
De même, les applis 32 bits utilisent sans problème les registres flottants 80 bits des processeurs Intel.
-- pehache http://pehache.free.fr/public.html
Stephan Peccini
Sur fr.comp.os.linux.debats, Pascal Hambourg s'est exprimé ainsi :
Sinon, c'est quoi la différence entre un driver 64 bits et 32 bits ?
L'architecture pour laquelle il a été compilé. Les pilotes Windows sont généralement distribués sous forme binaire.
Mais au niveau du code, quelles sont les différences ?
Pas les mêmes instructions, pas les mêmes opcodes, pas les mêmes tailles d'opérandes...
Désolé, je pose très mal mes questions. Je parlais au niveau du code source. Est-ce qu'il y a beaucoup de différences pour écrire un code qui fonctionnera sur une architecture 64 bits et celui qui fonctionnera sur une architecture 32 bits ? Ou est-ce le compilateur qui prend en charge totalement la différence d'architecture ? En fait, derrière cette question je me demande si finalement il ne suffirait pas de recompiler pour une architecture 64 bits, les drivers existants en 32 bits, ou avec un minimum de modification.
-- Stéphan Peccini Les photos : <URL:http://photonature.fr> Les Pyrénées : <URL:http://photonature.fr/pyrenees> Le blog : <URL:http://pyrenees.peccini.fr>
Sur fr.comp.os.linux.debats, Pascal Hambourg s'est exprimé ainsi :
Sinon, c'est quoi la différence entre un driver 64 bits et 32 bits ?
L'architecture pour laquelle il a été compilé. Les pilotes Windows
sont généralement distribués sous forme binaire.
Mais au niveau du code, quelles sont les différences ?
Pas les mêmes instructions, pas les mêmes opcodes, pas les mêmes
tailles d'opérandes...
Désolé, je pose très mal mes questions. Je parlais au niveau du code
source. Est-ce qu'il y a beaucoup de différences pour écrire un code qui
fonctionnera sur une architecture 64 bits et celui qui fonctionnera sur
une architecture 32 bits ? Ou est-ce le compilateur qui prend en charge
totalement la différence d'architecture ? En fait, derrière cette
question je me demande si finalement il ne suffirait pas de recompiler
pour une architecture 64 bits, les drivers existants en 32 bits, ou avec
un minimum de modification.
--
Stéphan Peccini
Les photos : <URL:http://photonature.fr>
Les Pyrénées : <URL:http://photonature.fr/pyrenees>
Le blog : <URL:http://pyrenees.peccini.fr>
Sur fr.comp.os.linux.debats, Pascal Hambourg s'est exprimé ainsi :
Sinon, c'est quoi la différence entre un driver 64 bits et 32 bits ?
L'architecture pour laquelle il a été compilé. Les pilotes Windows sont généralement distribués sous forme binaire.
Mais au niveau du code, quelles sont les différences ?
Pas les mêmes instructions, pas les mêmes opcodes, pas les mêmes tailles d'opérandes...
Désolé, je pose très mal mes questions. Je parlais au niveau du code source. Est-ce qu'il y a beaucoup de différences pour écrire un code qui fonctionnera sur une architecture 64 bits et celui qui fonctionnera sur une architecture 32 bits ? Ou est-ce le compilateur qui prend en charge totalement la différence d'architecture ? En fait, derrière cette question je me demande si finalement il ne suffirait pas de recompiler pour une architecture 64 bits, les drivers existants en 32 bits, ou avec un minimum de modification.
-- Stéphan Peccini Les photos : <URL:http://photonature.fr> Les Pyrénées : <URL:http://photonature.fr/pyrenees> Le blog : <URL:http://pyrenees.peccini.fr>
Kevin Denis
Le 08-09-2008, Thierry B. a écrit :
J'ai fait contionner un OS X sur un PC et cela très bien
Amha, ce n'est pas une preuve. Contre exemple possible: est-il possible d'installer Freedos ou Minix sur le métal d'un Mac dernière génération ?
Tu installes le machin bootcamp, là, ça t'installes un BIOS. Une slackware 12.1 boote sur le métal d'un Mac sans problème ensuite. Je n'ai pas essayé, mais il y a de grandes chances que ça marche pareil avec les autres systèmes prévu pour du PC. -- Kevin
Le 08-09-2008, Thierry B. <tth@prout.stex.invalid> a écrit :
J'ai fait contionner un OS X sur un PC et cela très bien
Amha, ce n'est pas une preuve. Contre exemple possible: est-il
possible d'installer Freedos ou Minix sur le métal d'un Mac
dernière génération ?
Tu installes le machin bootcamp, là, ça t'installes un BIOS.
Une slackware 12.1 boote sur le métal d'un Mac sans problème ensuite.
Je n'ai pas essayé, mais il y a de grandes chances que ça marche
pareil avec les autres systèmes prévu pour du PC.
--
Kevin
J'ai fait contionner un OS X sur un PC et cela très bien
Amha, ce n'est pas une preuve. Contre exemple possible: est-il possible d'installer Freedos ou Minix sur le métal d'un Mac dernière génération ?
Tu installes le machin bootcamp, là, ça t'installes un BIOS. Une slackware 12.1 boote sur le métal d'un Mac sans problème ensuite. Je n'ai pas essayé, mais il y a de grandes chances que ça marche pareil avec les autres systèmes prévu pour du PC. -- Kevin
Nicolas George
Stephan Peccini , dans le message <ga4u6i$mj0$, a écrit :
Désolé, je pose très mal mes questions. Je parlais au niveau du code source. Est-ce qu'il y a beaucoup de différences pour écrire un code qui fonctionnera sur une architecture 64 bits et celui qui fonctionnera sur une architecture 32 bits ?
Pour du code C propre <vantardise>par exemple comme celui que j'écris</vantardise>, il n'y a aucune différence : un programme qui fonctionne en 32 bits fera exactement la même chose en 64 bits. Mais il y a des pièges à éviter, parfois grossiers, comme apprendre le C dans n'importe quel bouquin autre que le K&R, parfois subtils, comme les détails des extensions de signe.
Stephan Peccini , dans le message <ga4u6i$mj0$1@eweb.domicile>, a
écrit :
Désolé, je pose très mal mes questions. Je parlais au niveau du code
source. Est-ce qu'il y a beaucoup de différences pour écrire un code qui
fonctionnera sur une architecture 64 bits et celui qui fonctionnera sur
une architecture 32 bits ?
Pour du code C propre <vantardise>par exemple comme celui que
j'écris</vantardise>, il n'y a aucune différence : un programme qui
fonctionne en 32 bits fera exactement la même chose en 64 bits. Mais il y a
des pièges à éviter, parfois grossiers, comme apprendre le C dans n'importe
quel bouquin autre que le K&R, parfois subtils, comme les détails des
extensions de signe.
Stephan Peccini , dans le message <ga4u6i$mj0$, a écrit :
Désolé, je pose très mal mes questions. Je parlais au niveau du code source. Est-ce qu'il y a beaucoup de différences pour écrire un code qui fonctionnera sur une architecture 64 bits et celui qui fonctionnera sur une architecture 32 bits ?
Pour du code C propre <vantardise>par exemple comme celui que j'écris</vantardise>, il n'y a aucune différence : un programme qui fonctionne en 32 bits fera exactement la même chose en 64 bits. Mais il y a des pièges à éviter, parfois grossiers, comme apprendre le C dans n'importe quel bouquin autre que le K&R, parfois subtils, comme les détails des extensions de signe.
stephan
On Sep 9, 12:23 pm, Nicolas George <nicolas$ wrote:
Pour du code C propre <vantardise>par exemple comme celui que j'écris</vantardise>, il n'y a aucune différence : un programme qui fonctionne en 32 bits fera exactement la même chose en 64 bits.
Même pour les pilotes de périphériques ?
-- Stéphan
On Sep 9, 12:23 pm, Nicolas George <nicolas$geo...@salle-s.org> wrote:
Pour du code C propre <vantardise>par exemple comme celui que
j'écris</vantardise>, il n'y a aucune différence : un programme qui
fonctionne en 32 bits fera exactement la même chose en 64 bits.
On Sep 9, 12:23 pm, Nicolas George <nicolas$ wrote:
Pour du code C propre <vantardise>par exemple comme celui que j'écris</vantardise>, il n'y a aucune différence : un programme qui fonctionne en 32 bits fera exactement la même chose en 64 bits.
Même pour les pilotes de périphériques ?
-- Stéphan
Nicolas George
, dans le message , a écrit :
Même pour les pilotes de périphériques ?
Oh, c'est vrai, j'avais oublié de répondre à cet aspect de la question.
Pour les pilotes de périphériques, il est souvent nécessaire de faire des choses moins portables, comme accéder à des adresses spécifiques, ou respecter des temporisations précises. Cependant, pour des architectures assez similaires, telles que le sont x86_32 et x86_64, il est assez facile de regrouper les parties non-portables dans un petit nombre de fonctions de bas niveau, et de rendre le reste du code totalement portable.
D'ailleurs, un exemple sur un noyau Linux pris au hasard, il suffit de mesurer les tailles respectives des répertoires : 5 Mo pour arch/x86 (qui est déjà commun à x86_63 et x86_64 ; les autres architectures s'échelonnent entre 350 ko et 10 Mo), contre 134 Mo dans drivers : l'essentiel des drivers sont parfaitement portables.
stephan@photonature.fr, dans le message
<e53f1ebe-d028-4bd8-93ce-8a20e3308a3f@y38g2000hsy.googlegroups.com>, a
écrit :
Même pour les pilotes de périphériques ?
Oh, c'est vrai, j'avais oublié de répondre à cet aspect de la question.
Pour les pilotes de périphériques, il est souvent nécessaire de faire des
choses moins portables, comme accéder à des adresses spécifiques, ou
respecter des temporisations précises. Cependant, pour des architectures
assez similaires, telles que le sont x86_32 et x86_64, il est assez facile
de regrouper les parties non-portables dans un petit nombre de fonctions de
bas niveau, et de rendre le reste du code totalement portable.
D'ailleurs, un exemple sur un noyau Linux pris au hasard, il suffit de
mesurer les tailles respectives des répertoires : 5 Mo pour arch/x86 (qui
est déjà commun à x86_63 et x86_64 ; les autres architectures s'échelonnent
entre 350 ko et 10 Mo), contre 134 Mo dans drivers : l'essentiel des drivers
sont parfaitement portables.
Oh, c'est vrai, j'avais oublié de répondre à cet aspect de la question.
Pour les pilotes de périphériques, il est souvent nécessaire de faire des choses moins portables, comme accéder à des adresses spécifiques, ou respecter des temporisations précises. Cependant, pour des architectures assez similaires, telles que le sont x86_32 et x86_64, il est assez facile de regrouper les parties non-portables dans un petit nombre de fonctions de bas niveau, et de rendre le reste du code totalement portable.
D'ailleurs, un exemple sur un noyau Linux pris au hasard, il suffit de mesurer les tailles respectives des répertoires : 5 Mo pour arch/x86 (qui est déjà commun à x86_63 et x86_64 ; les autres architectures s'échelonnent entre 350 ko et 10 Mo), contre 134 Mo dans drivers : l'essentiel des drivers sont parfaitement portables.
stephan
On Sep 9, 4:49 pm, Nicolas George <nicolas$ wrote:
... des explications intéressantes.
Merci.
On Sep 9, 4:49 pm, Nicolas George <nicolas$geo...@salle-s.org> wrote:
On Sep 9, 4:49 pm, Nicolas George <nicolas$ wrote:
... des explications intéressantes.
Merci.
Ed
On Tue, 09 Sep 2008 06:31:16 +0200, Stephan Peccini wrote:
Sur fr.comp.os.linux.debats, Pascal Hambourg s'est exprimé ainsi :
Sinon, c'est quoi la différence entre un driver 64 bits et 32 bits ?
L'architecture pour laquelle il a été compilé. Les pilotes Windows sont généralement distribués sous forme binaire.
Mais au niveau du code, quelles sont les différences ?
Pas les mêmes instructions, pas les mêmes opcodes, pas les mêmes tailles d'opérandes...
Désolé, je pose très mal mes questions. Je parlais au niveau du code source. Est-ce qu'il y a beaucoup de différences pour écrire un code qui fonctionnera sur une architecture 64 bits et celui qui fonctionnera sur une architecture 32 bits ? Ou est-ce le compilateur qui prend en charge totalement la différence d'architecture ? En fait, derrière cette question je me demande si finalement il ne suffirait pas de recompiler pour une architecture 64 bits, les drivers existants en 32 bits, ou avec un minimum de modification.
Tant qu'il n'y a pas d'hypothèse implicite (ou explicite, d'ailleurs) sur la taille des types entiers et des pointeurs, il n'y a normalement pas de problèmes.
Pour les OS déjà multi-architectures 32/64 bits et little/big endian, les problèmes de drivers sont globalement réglés de facto, s'ils sont partagés entre architectures.
Le gros du travail tourne bien autour du processeur lui-même.
-- Ed
On Tue, 09 Sep 2008 06:31:16 +0200, Stephan Peccini wrote:
Sur fr.comp.os.linux.debats, Pascal Hambourg s'est exprimé ainsi :
Sinon, c'est quoi la différence entre un driver 64 bits et 32 bits ?
L'architecture pour laquelle il a été compilé. Les pilotes Windows
sont généralement distribués sous forme binaire.
Mais au niveau du code, quelles sont les différences ?
Pas les mêmes instructions, pas les mêmes opcodes, pas les mêmes
tailles d'opérandes...
Désolé, je pose très mal mes questions. Je parlais au niveau du code
source. Est-ce qu'il y a beaucoup de différences pour écrire un code qui
fonctionnera sur une architecture 64 bits et celui qui fonctionnera sur
une architecture 32 bits ? Ou est-ce le compilateur qui prend en charge
totalement la différence d'architecture ? En fait, derrière cette
question je me demande si finalement il ne suffirait pas de recompiler
pour une architecture 64 bits, les drivers existants en 32 bits, ou avec
un minimum de modification.
Tant qu'il n'y a pas d'hypothèse implicite (ou explicite, d'ailleurs) sur
la taille des types entiers et des pointeurs, il n'y a normalement pas de
problèmes.
Pour les OS déjà multi-architectures 32/64 bits et little/big endian, les
problèmes de drivers sont globalement réglés de facto, s'ils sont
partagés entre architectures.
Le gros du travail tourne bien autour du processeur lui-même.
On Tue, 09 Sep 2008 06:31:16 +0200, Stephan Peccini wrote:
Sur fr.comp.os.linux.debats, Pascal Hambourg s'est exprimé ainsi :
Sinon, c'est quoi la différence entre un driver 64 bits et 32 bits ?
L'architecture pour laquelle il a été compilé. Les pilotes Windows sont généralement distribués sous forme binaire.
Mais au niveau du code, quelles sont les différences ?
Pas les mêmes instructions, pas les mêmes opcodes, pas les mêmes tailles d'opérandes...
Désolé, je pose très mal mes questions. Je parlais au niveau du code source. Est-ce qu'il y a beaucoup de différences pour écrire un code qui fonctionnera sur une architecture 64 bits et celui qui fonctionnera sur une architecture 32 bits ? Ou est-ce le compilateur qui prend en charge totalement la différence d'architecture ? En fait, derrière cette question je me demande si finalement il ne suffirait pas de recompiler pour une architecture 64 bits, les drivers existants en 32 bits, ou avec un minimum de modification.
Tant qu'il n'y a pas d'hypothèse implicite (ou explicite, d'ailleurs) sur la taille des types entiers et des pointeurs, il n'y a normalement pas de problèmes.
Pour les OS déjà multi-architectures 32/64 bits et little/big endian, les problèmes de drivers sont globalement réglés de facto, s'ils sont partagés entre architectures.
Le gros du travail tourne bien autour du processeur lui-même.
