Sit une config récente à base de Intel Core2 Duo et GeForce musclée. Est
installé dessus une Ubuntu 7.04 en 64 bits.
Je souhaite installer un jeu commercial, en l'occurence "Unreal Tournament
2003". Problème : lorsque j'exécute l'installeur Linux, il me jette à cause
de ma glibc 64 bits qui n'est pas supportée. aucun problème, j'installe la
glibc 32 bits qui va bien. problème, l'installeur me jette toujours : il
utilise encore la version 64 bits !
Ma question : comment faire cohabiter les versions 32 et 64 bits des
dépendances nécessaires ?
La machine est destiné à un utilisateur Windowsien qui n'a _jamais_ utilisé LInux et qui m'a demandé de lui faire une install "pour essayer".
Dans ce cas aucune hésitation : installer une distrib 32 bits.
Olivier V
Eric Belhomme
Olivier V wrote in news::
Dans ce cas aucune hésitation : installer une distrib 32 bits.
C'est ce que j'ai finalement fait : j'ai réinstallé Ubuntu, mais en 32
bits. Et bien je ne sais pas si le 64 bits n'apporte rien, mais je suis persuadé que le système etait beaucoup plus réactif avec la version 64 bits d'Ubuntu !
-- Rico
Olivier V <anonyme@free.fr> wrote in
news:2508987.FPvP2UamV1@news.free.fr:
Dans ce cas aucune hésitation : installer une distrib 32 bits.
C'est ce que j'ai finalement fait : j'ai réinstallé Ubuntu, mais en 32
bits. Et bien je ne sais pas si le 64 bits n'apporte rien, mais je suis
persuadé que le système etait beaucoup plus réactif avec la version 64 bits
d'Ubuntu !
Dans ce cas aucune hésitation : installer une distrib 32 bits.
C'est ce que j'ai finalement fait : j'ai réinstallé Ubuntu, mais en 32
bits. Et bien je ne sais pas si le 64 bits n'apporte rien, mais je suis persuadé que le système etait beaucoup plus réactif avec la version 64 bits d'Ubuntu !
-- Rico
BARANGER Emmanuel
Olivier V wrote in news::
Dans ce cas aucune hésitation : installer une distrib 32 bits.
C'est ce que j'ai finalement fait : j'ai réinstallé Ubuntu, mais en 32
bits. Et bien je ne sais pas si le 64 bits n'apporte rien, mais je suis persuadé que le système etait beaucoup plus réactif avec la version 64 bits d'Ubuntu !
Par curiosité j'ai installé ma Mandriva 2008 (et oui déjà 2008) en dual
boot sur ma machine. L'une en 32 bit et l'autre en 64 bit. Il est indéniable que la 64 bit est bien plus réactive tant que les applis utilisées sont aussi en 64 bit ce que je m'efforce de faire. OpenOffice, Firefox, même FligtGear gagne en images par seconde (de 5 à 10 environ par seconde). Bref le tout 64 bit apporte c'est une évidence mais dépend ancore trop d'applis propriétaire uniquement 32 bit pour être très grand publique.
Olivier V <anonyme@free.fr> wrote in
news:2508987.FPvP2UamV1@news.free.fr:
Dans ce cas aucune hésitation : installer une distrib 32 bits.
C'est ce que j'ai finalement fait : j'ai réinstallé Ubuntu, mais en 32
bits. Et bien je ne sais pas si le 64 bits n'apporte rien, mais je suis
persuadé que le système etait beaucoup plus réactif avec la version 64 bits
d'Ubuntu !
Par curiosité j'ai installé ma Mandriva 2008 (et oui déjà 2008) en dual
boot sur ma machine. L'une en 32 bit et l'autre en 64 bit. Il est
indéniable que la 64 bit est bien plus réactive tant que les applis
utilisées sont aussi en 64 bit ce que je m'efforce de faire. OpenOffice,
Firefox, même FligtGear gagne en images par seconde (de 5 à 10 environ
par seconde). Bref le tout 64 bit apporte c'est une évidence mais dépend
ancore trop d'applis propriétaire uniquement 32 bit pour être très grand
publique.
Dans ce cas aucune hésitation : installer une distrib 32 bits.
C'est ce que j'ai finalement fait : j'ai réinstallé Ubuntu, mais en 32
bits. Et bien je ne sais pas si le 64 bits n'apporte rien, mais je suis persuadé que le système etait beaucoup plus réactif avec la version 64 bits d'Ubuntu !
Par curiosité j'ai installé ma Mandriva 2008 (et oui déjà 2008) en dual
boot sur ma machine. L'une en 32 bit et l'autre en 64 bit. Il est indéniable que la 64 bit est bien plus réactive tant que les applis utilisées sont aussi en 64 bit ce que je m'efforce de faire. OpenOffice, Firefox, même FligtGear gagne en images par seconde (de 5 à 10 environ par seconde). Bref le tout 64 bit apporte c'est une évidence mais dépend ancore trop d'applis propriétaire uniquement 32 bit pour être très grand publique.
On Mon, 23 Apr 2007 18:44:42 +0200, BARANGER Emmanuel :
Il est indéniable que la 64 bit est bien plus réactive tant que les applis utilisées sont aussi en 64 bit ce que je m'efforce de faire.
Si j'ai tout bien suivi, c'est parce que les options par défaut de gcc en 32 bits sont optimisées pour un très vieux processeur (genre Pentium 1). Au contraire, les options en 64 bits sont optimisées pour un processeur beaucoup plus récent (Dans le monde PC, un vieux processeur 64 bits, c'est rare...)
On Mon, 23 Apr 2007 18:44:42 +0200, BARANGER Emmanuel
<embaranger@free.fr>:
Il est
indéniable que la 64 bit est bien plus réactive tant que les applis
utilisées sont aussi en 64 bit ce que je m'efforce de faire.
Si j'ai tout bien suivi, c'est parce que les options par défaut de gcc
en 32 bits sont optimisées pour un très vieux processeur (genre
Pentium 1).
Au contraire, les options en 64 bits sont optimisées pour un
processeur beaucoup plus récent (Dans le monde PC, un vieux processeur
64 bits, c'est rare...)
On Mon, 23 Apr 2007 18:44:42 +0200, BARANGER Emmanuel :
Il est indéniable que la 64 bit est bien plus réactive tant que les applis utilisées sont aussi en 64 bit ce que je m'efforce de faire.
Si j'ai tout bien suivi, c'est parce que les options par défaut de gcc en 32 bits sont optimisées pour un très vieux processeur (genre Pentium 1). Au contraire, les options en 64 bits sont optimisées pour un processeur beaucoup plus récent (Dans le monde PC, un vieux processeur 64 bits, c'est rare...)
Nicolas George
Fabien LE LEZ wrote in message :
Si j'ai tout bien suivi, c'est parce que les options par défaut de gcc en 32 bits sont optimisées pour un très vieux processeur (genre Pentium 1). Au contraire, les options en 64 bits sont optimisées pour un processeur beaucoup plus récent (Dans le monde PC, un vieux processeur 64 bits, c'est rare...)
Ce n'est pas tout.
D'une part, même avec les options d'optimisation spécifique au processeur, gcc produit un code moins efficace en 32 bits, parce que même comme ça, il va parfois garder la compatibilité ascendante là où ce n'est pas nécessaire. Il faudrait une réécriture en profondeur de l'optimiseur pour corriger ça.
D'autre part, l'architecture 64 bits introduit quelques nouveautés (en particulier plus de registres) qui ne sont pas utilisables en 32 bits, il me semble.
Enfin, l'architecture 64 bits a une ABI standard qui tire parti des nouvelles fonctionnalités du processeur, ce qui fait que les appels de fonctions et les appels système sont de toutes façons plus efficaces.
Fabien LE LEZ wrote in message
<at1q23demu5sjar95cvk0b4ubasimletbc@4ax.com>:
Si j'ai tout bien suivi, c'est parce que les options par défaut de gcc
en 32 bits sont optimisées pour un très vieux processeur (genre
Pentium 1).
Au contraire, les options en 64 bits sont optimisées pour un
processeur beaucoup plus récent (Dans le monde PC, un vieux processeur
64 bits, c'est rare...)
Ce n'est pas tout.
D'une part, même avec les options d'optimisation spécifique au processeur,
gcc produit un code moins efficace en 32 bits, parce que même comme ça, il
va parfois garder la compatibilité ascendante là où ce n'est pas nécessaire.
Il faudrait une réécriture en profondeur de l'optimiseur pour corriger ça.
D'autre part, l'architecture 64 bits introduit quelques nouveautés (en
particulier plus de registres) qui ne sont pas utilisables en 32 bits, il me
semble.
Enfin, l'architecture 64 bits a une ABI standard qui tire parti des
nouvelles fonctionnalités du processeur, ce qui fait que les appels de
fonctions et les appels système sont de toutes façons plus efficaces.
Si j'ai tout bien suivi, c'est parce que les options par défaut de gcc en 32 bits sont optimisées pour un très vieux processeur (genre Pentium 1). Au contraire, les options en 64 bits sont optimisées pour un processeur beaucoup plus récent (Dans le monde PC, un vieux processeur 64 bits, c'est rare...)
Ce n'est pas tout.
D'une part, même avec les options d'optimisation spécifique au processeur, gcc produit un code moins efficace en 32 bits, parce que même comme ça, il va parfois garder la compatibilité ascendante là où ce n'est pas nécessaire. Il faudrait une réécriture en profondeur de l'optimiseur pour corriger ça.
D'autre part, l'architecture 64 bits introduit quelques nouveautés (en particulier plus de registres) qui ne sont pas utilisables en 32 bits, il me semble.
Enfin, l'architecture 64 bits a une ABI standard qui tire parti des nouvelles fonctionnalités du processeur, ce qui fait que les appels de fonctions et les appels système sont de toutes façons plus efficaces.
BARANGER Emmanuel
Enfin, l'architecture 64 bits a une ABI standard qui tire parti des nouvelles fonctionnalités du processeur, ce qui fait que les appels de fonctions et les appels système sont de toutes façons plus efficaces.
ATTENTION je vais faire appel à ma mémoire sans vraiment vérifier mes dires. Il se peux que je dise de grosses bêtises. A vous de me corriger le cas échéant.
A la grande époque des motorola (famille 68000 16bit) les mots donc étaient codés sur 16 bits pour faire un mot long il fallait donc deux fois 16 bits. Passé au 68030 (32 bit donc) le codage d'un mot long se faisait en une fois. Par contre, de mémoire, il me semble que les mots (voir les octets) étaient toujours codés sur 32 bit. Ce qui donnait, qu'a fréquence égale, un exécutable 68000 tournait plus vite sur 68000 que sur 68030 puisque ce dernier devait déplacer bien plus d'informations à chaque fois. Enfin un truc comme cela, je simplifie. Seuls les exécutable compilées en 030 tiraient profit du 30.
Se pourrait-il qu'il en soit de même pour les X86 passant de 32 bit à 64 bit.
Je sais cela peux paraitre un peu tiré par les cheveux, mais je suis assez fatigué d'entendre des windosiens critiquer le 64 bit alors que la plus grande majorité utilisent un windows 32 bit sur une machine 64 bit. Evidement que dans ce cas le 64 bit n'apporte pas grand chose ;)
Enfin, l'architecture 64 bits a une ABI standard qui tire parti des
nouvelles fonctionnalités du processeur, ce qui fait que les appels de
fonctions et les appels système sont de toutes façons plus efficaces.
ATTENTION je vais faire appel à ma mémoire sans vraiment vérifier mes
dires. Il se peux que je dise de grosses bêtises. A vous de me corriger
le cas échéant.
A la grande époque des motorola (famille 68000 16bit) les mots donc
étaient codés sur 16 bits pour faire un mot long il fallait donc deux
fois 16 bits. Passé au 68030 (32 bit donc) le codage d'un mot long se
faisait en une fois. Par contre, de mémoire, il me semble que les mots
(voir les octets) étaient toujours codés sur 32 bit. Ce qui donnait,
qu'a fréquence égale, un exécutable 68000 tournait plus vite sur 68000
que sur 68030 puisque ce dernier devait déplacer bien plus
d'informations à chaque fois. Enfin un truc comme cela, je simplifie.
Seuls les exécutable compilées en 030 tiraient profit du 30.
Se pourrait-il qu'il en soit de même pour les X86 passant de 32 bit à 64
bit.
Je sais cela peux paraitre un peu tiré par les cheveux, mais je suis
assez fatigué d'entendre des windosiens critiquer le 64 bit alors que la
plus grande majorité utilisent un windows 32 bit sur une machine 64 bit.
Evidement que dans ce cas le 64 bit n'apporte pas grand chose ;)
Enfin, l'architecture 64 bits a une ABI standard qui tire parti des nouvelles fonctionnalités du processeur, ce qui fait que les appels de fonctions et les appels système sont de toutes façons plus efficaces.
ATTENTION je vais faire appel à ma mémoire sans vraiment vérifier mes dires. Il se peux que je dise de grosses bêtises. A vous de me corriger le cas échéant.
A la grande époque des motorola (famille 68000 16bit) les mots donc étaient codés sur 16 bits pour faire un mot long il fallait donc deux fois 16 bits. Passé au 68030 (32 bit donc) le codage d'un mot long se faisait en une fois. Par contre, de mémoire, il me semble que les mots (voir les octets) étaient toujours codés sur 32 bit. Ce qui donnait, qu'a fréquence égale, un exécutable 68000 tournait plus vite sur 68000 que sur 68030 puisque ce dernier devait déplacer bien plus d'informations à chaque fois. Enfin un truc comme cela, je simplifie. Seuls les exécutable compilées en 030 tiraient profit du 30.
Se pourrait-il qu'il en soit de même pour les X86 passant de 32 bit à 64 bit.
Je sais cela peux paraitre un peu tiré par les cheveux, mais je suis assez fatigué d'entendre des windosiens critiquer le 64 bit alors que la plus grande majorité utilisent un windows 32 bit sur une machine 64 bit. Evidement que dans ce cas le 64 bit n'apporte pas grand chose ;)
BARANGER Emmanuel wrote in message <462dd787$0$768$:
A la grande époque des motorola (famille 68000 16bit)
Le 68000 est 32 bits. Ou plus exactement 32/16 : les registres et l'adressage mémoire sont 32 bits, mais le bus mémoire est 16 bits.
Passé au 68030 (32 bit donc)
La nouveauté du 68030 est une MMU, pas le 32 bits.
Par contre, de mémoire, il me semble que les mots (voir les octets) étaient toujours codés sur 32 bit. Ce qui donnait, qu'a fréquence égale, un exécutable 68000 tournait plus vite sur 68000 que sur 68030 puisque ce dernier devait déplacer bien plus d'informations à chaque fois.
Je pense que tu te plantes assez largement.
BARANGER Emmanuel wrote in message
<462dd787$0$768$426a74cc@news.free.fr>:
A la grande époque des motorola (famille 68000 16bit)
Le 68000 est 32 bits. Ou plus exactement 32/16 : les registres et
l'adressage mémoire sont 32 bits, mais le bus mémoire est 16 bits.
Passé au 68030 (32 bit donc)
La nouveauté du 68030 est une MMU, pas le 32 bits.
Par contre, de mémoire, il me semble que les mots
(voir les octets) étaient toujours codés sur 32 bit. Ce qui donnait,
qu'a fréquence égale, un exécutable 68000 tournait plus vite sur 68000
que sur 68030 puisque ce dernier devait déplacer bien plus
d'informations à chaque fois.
BARANGER Emmanuel wrote in message <462dd787$0$768$:
A la grande époque des motorola (famille 68000 16bit)
Le 68000 est 32 bits. Ou plus exactement 32/16 : les registres et l'adressage mémoire sont 32 bits, mais le bus mémoire est 16 bits.
Passé au 68030 (32 bit donc)
La nouveauté du 68030 est une MMU, pas le 32 bits.
Par contre, de mémoire, il me semble que les mots (voir les octets) étaient toujours codés sur 32 bit. Ce qui donnait, qu'a fréquence égale, un exécutable 68000 tournait plus vite sur 68000 que sur 68030 puisque ce dernier devait déplacer bien plus d'informations à chaque fois.
Je pense que tu te plantes assez largement.
BARANGER Emmanuel
BARANGER Emmanuel wrote in message <462dd787$0$768$:
A la grande époque des motorola (famille 68000 16bit)
Le 68000 est 32 bits. Ou plus exactement 32/16 : les registres et l'adressage mémoire sont 32 bits, mais le bus mémoire est 16 bits.
Passé au 68030 (32 bit donc)
La nouveauté du 68030 est une MMU, pas le 32 bits.
Par contre, de mémoire, il me semble que les mots (voir les octets) étaient toujours codés sur 32 bit. Ce qui donnait, qu'a fréquence égale, un exécutable 68000 tournait plus vite sur 68000 que sur 68030 puisque ce dernier devait déplacer bien plus d'informations à chaque fois.
Je pense que tu te plantes assez largement.
Beuh ! Meme pas vrai d'abord ;) Il ne faut pas exagérer tout de meme. Le 68000 n'est pas 32/16 mais 16/32.
Le 68000 est qualifié de 16/32 bits car ses registres ont une largeur de 32 bits et ses instructions acceptent des données de 8, 16 et 32 bits. Toutefois, l'ALU (Unité arithmétique et logique) a une largeur de 16 bits, ce qui fait que les opérations sur 32 bits prennent plus de cycles d'horloge pour être exécutées. En outre, les bus externes ont une largeur de 16 bits pour les données et de 24 bits les adresses.
Il y a des choses que j'ai oublié mais pas tout quand meme, je ne suis pas encore grabataire ;)
BARANGER Emmanuel wrote in message
<462dd787$0$768$426a74cc@news.free.fr>:
A la grande époque des motorola (famille 68000 16bit)
Le 68000 est 32 bits. Ou plus exactement 32/16 : les registres et
l'adressage mémoire sont 32 bits, mais le bus mémoire est 16 bits.
Passé au 68030 (32 bit donc)
La nouveauté du 68030 est une MMU, pas le 32 bits.
Par contre, de mémoire, il me semble que les mots
(voir les octets) étaient toujours codés sur 32 bit. Ce qui donnait,
qu'a fréquence égale, un exécutable 68000 tournait plus vite sur 68000
que sur 68030 puisque ce dernier devait déplacer bien plus
d'informations à chaque fois.
Je pense que tu te plantes assez largement.
Beuh ! Meme pas vrai d'abord ;) Il ne faut pas exagérer tout de meme. Le
68000 n'est pas 32/16 mais 16/32.
Le 68000 est qualifié de 16/32 bits car ses registres ont une largeur de 32 bits et ses instructions acceptent des données de 8, 16 et 32 bits. Toutefois, l'ALU (Unité arithmétique et logique) a une largeur de 16 bits, ce qui fait que les opérations sur 32 bits prennent plus de cycles d'horloge pour être exécutées. En outre, les bus externes ont une largeur de 16 bits pour les données et de 24 bits les adresses.
Il y a des choses que j'ai oublié mais pas tout quand meme, je ne suis
pas encore grabataire ;)
BARANGER Emmanuel wrote in message <462dd787$0$768$:
A la grande époque des motorola (famille 68000 16bit)
Le 68000 est 32 bits. Ou plus exactement 32/16 : les registres et l'adressage mémoire sont 32 bits, mais le bus mémoire est 16 bits.
Passé au 68030 (32 bit donc)
La nouveauté du 68030 est une MMU, pas le 32 bits.
Par contre, de mémoire, il me semble que les mots (voir les octets) étaient toujours codés sur 32 bit. Ce qui donnait, qu'a fréquence égale, un exécutable 68000 tournait plus vite sur 68000 que sur 68030 puisque ce dernier devait déplacer bien plus d'informations à chaque fois.
Je pense que tu te plantes assez largement.
Beuh ! Meme pas vrai d'abord ;) Il ne faut pas exagérer tout de meme. Le 68000 n'est pas 32/16 mais 16/32.
Le 68000 est qualifié de 16/32 bits car ses registres ont une largeur de 32 bits et ses instructions acceptent des données de 8, 16 et 32 bits. Toutefois, l'ALU (Unité arithmétique et logique) a une largeur de 16 bits, ce qui fait que les opérations sur 32 bits prennent plus de cycles d'horloge pour être exécutées. En outre, les bus externes ont une largeur de 16 bits pour les données et de 24 bits les adresses.
Il y a des choses que j'ai oublié mais pas tout quand meme, je ne suis pas encore grabataire ;)
Le 24-04-2007, à propos de Re: cohabitation 32 et 64 bits, Nicolas George écrivait dans fr.comp.os.linux.configuration :
BARANGER Emmanuel wrote in message <462dd787$0$768$:
A la grande époque des motorola (famille 68000 16bit)
Le 68000 est 32 bits. Ou plus exactement 32/16 : les registres et l'adressage mémoire sont 32 bits, mais le bus mémoire est 16 bits.
Registres A : 32 bits dont 24 bits utilisables Les huit bits de poids fort de l'adresse ne sont jamais utilisés parce que le bus d'adresse externe ne fait que 23 bits (le 24e étant toujours nul).
Registres D : 32 bits (envoyés en deux fois sur un bus externe de 16 bits plus deux lignes pour savoir si on a affaire aux 16 bits de poids faible ou fort, signaux d'ailleurs assez capricieux, on aurait AMHA fait mieux d'utiliser A0 à la place de ces deux trucs !).
C'est effectivement un 16/32 bits.
Passé au 68030 (32 bit donc)
La nouveauté du 68030 est une MMU, pas le 32 bits.
J'aurais rajouté _interne_. Je dois encore avoir des 68851 à la cave (et des 68881/2) que je garde dans ma collection de composants.
Par contre, de mémoire, il me semble que les mots (voir les octets) étaient toujours codés sur 32 bit. Ce qui donnait, qu'a fréquence égale, un exécutable 68000 tournait plus vite sur 68000 que sur 68030 puisque ce dernier devait déplacer bien plus d'informations à chaque fois.
Je pense que tu te plantes assez largement.
Moi, je n'ai rien compris même en relisant plusieurs fois. Mais dans mon souvenir (la dernière carte que j'ai réalisée avec un 68k pur jus en céramique et avec le soft embarqué en assembleur datant de 2003), les octets occupent bien seize bits, les huit bits de poids fort étant perdus.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 24-04-2007, à propos de
Re: cohabitation 32 et 64 bits,
Nicolas George écrivait dans fr.comp.os.linux.configuration :
BARANGER Emmanuel wrote in message
<462dd787$0$768$426a74cc@news.free.fr>:
A la grande époque des motorola (famille 68000 16bit)
Le 68000 est 32 bits. Ou plus exactement 32/16 : les registres et
l'adressage mémoire sont 32 bits, mais le bus mémoire est 16 bits.
Registres A : 32 bits dont 24 bits utilisables Les huit bits de poids fort
de l'adresse ne sont jamais utilisés parce que le bus d'adresse externe
ne fait que 23 bits (le 24e étant toujours nul).
Registres D : 32 bits (envoyés en deux fois sur un bus externe de 16
bits plus deux lignes pour savoir si on a affaire aux 16 bits de
poids faible ou fort, signaux d'ailleurs assez capricieux, on aurait
AMHA fait mieux d'utiliser A0 à la place de ces deux trucs !).
C'est effectivement un 16/32 bits.
Passé au 68030 (32 bit donc)
La nouveauté du 68030 est une MMU, pas le 32 bits.
J'aurais rajouté _interne_. Je dois encore avoir des 68851 à la cave
(et des 68881/2) que je garde dans ma collection de composants.
Par contre, de mémoire, il me semble que les mots
(voir les octets) étaient toujours codés sur 32 bit. Ce qui donnait,
qu'a fréquence égale, un exécutable 68000 tournait plus vite sur 68000
que sur 68030 puisque ce dernier devait déplacer bien plus
d'informations à chaque fois.
Je pense que tu te plantes assez largement.
Moi, je n'ai rien compris même en relisant plusieurs fois. Mais dans
mon souvenir (la dernière carte que j'ai réalisée avec un 68k pur
jus en céramique et avec le soft embarqué en assembleur datant de
2003), les octets occupent bien seize bits, les huit bits de poids
fort étant perdus.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 24-04-2007, à propos de Re: cohabitation 32 et 64 bits, Nicolas George écrivait dans fr.comp.os.linux.configuration :
BARANGER Emmanuel wrote in message <462dd787$0$768$:
A la grande époque des motorola (famille 68000 16bit)
Le 68000 est 32 bits. Ou plus exactement 32/16 : les registres et l'adressage mémoire sont 32 bits, mais le bus mémoire est 16 bits.
Registres A : 32 bits dont 24 bits utilisables Les huit bits de poids fort de l'adresse ne sont jamais utilisés parce que le bus d'adresse externe ne fait que 23 bits (le 24e étant toujours nul).
Registres D : 32 bits (envoyés en deux fois sur un bus externe de 16 bits plus deux lignes pour savoir si on a affaire aux 16 bits de poids faible ou fort, signaux d'ailleurs assez capricieux, on aurait AMHA fait mieux d'utiliser A0 à la place de ces deux trucs !).
C'est effectivement un 16/32 bits.
Passé au 68030 (32 bit donc)
La nouveauté du 68030 est une MMU, pas le 32 bits.
J'aurais rajouté _interne_. Je dois encore avoir des 68851 à la cave (et des 68881/2) que je garde dans ma collection de composants.
Par contre, de mémoire, il me semble que les mots (voir les octets) étaient toujours codés sur 32 bit. Ce qui donnait, qu'a fréquence égale, un exécutable 68000 tournait plus vite sur 68000 que sur 68030 puisque ce dernier devait déplacer bien plus d'informations à chaque fois.
Je pense que tu te plantes assez largement.
Moi, je n'ai rien compris même en relisant plusieurs fois. Mais dans mon souvenir (la dernière carte que j'ai réalisée avec un 68k pur jus en céramique et avec le soft embarqué en assembleur datant de 2003), les octets occupent bien seize bits, les huit bits de poids fort étant perdus.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
