Bonsoir à tous,
Pour optimiser la place en mémoire, j'ai toujours l'habitude de choisir les
variables les plus petites possibles.
par exemple
char i;
for(i=0;i<100;i++) {
etc...
}
Qu'en est il de l'optimisation sur les PC 32 bits actuels?
Est ce que i n'occupe réellement que un octet ?
Et si oui est ce que la vitesse d'exécution n'est pas pénalisée ?
MOVSX/MOVZX est plus cher qu'un simple MOV (dépend processeur), et coûte 1 ou 2 octets de code en plus
Comment ? Pas un seul compilo encore capable d'utiliser les registres 8 bits de l'intel ?
La misère de voir 32 beaux bits gachés alors qu'avec un code plus compact, on aurait pu utiliser AL *et* AH, BL *et* BH, etc...
Utiliser AX, AH, AL, en même temps que EAX peut causer un "partial register stall" sur certains processeurs. Par exemple dans ce genre de code :
MOV AL, 42 ADD ECX, EAX
Cela crée un ralentissement notable de l'exécution.
-- Richard
Antoine Leca
En 40f65c72$0$16280$, cedric va escriure:
Antoine Leca wrote:
Et en version char, tu vas avoir
MOVsX EXX, i ADD a, EXX
MOVSX/MOVZX est plus cher qu'un simple MOV (dépend processeur), et coûte 1 ou 2 octets de code en plus
Comment ? Pas un seul compilo encore capable d'utiliser les registres 8 bits de l'intel ?
Si tu déclares
int a; char i; a = a + i;
il faut des compilos passablement intelligents pour s'apercevoir qu'il n'y a jamais de débordement, ou bien que le débordement n'a pas de conséquences pratiques.
La misère de voir 32 beaux bits gachés alors qu'avec un code plus compact, on aurait pu utiliser AL *et* AH, BL *et* BH, etc...
Tu m'expliqueras comment utiliser les 16 bits de poids fort de EAX indépendament de AL/AH/AX, autrement qu'au prix de contortions genre rotations sur 16 bits qui te font perdre en octets de code dix fois ce que tu gagnes en espace de stockage, et un rapport 100 au niveau des cycles processeur.
Antoine
En 40f65c72$0$16280$626a14ce@news.free.fr, cedric va escriure:
Antoine Leca wrote:
Et en version char, tu vas avoir
MOVsX EXX, i
ADD a, EXX
MOVSX/MOVZX est plus cher qu'un simple MOV (dépend processeur), et
coûte 1 ou 2 octets de code en plus
Comment ? Pas un seul compilo encore capable d'utiliser les registres
8 bits de l'intel ?
Si tu déclares
int a; char i;
a = a + i;
il faut des compilos passablement intelligents pour s'apercevoir qu'il n'y a
jamais de débordement, ou bien que le débordement n'a pas de conséquences
pratiques.
La misère de voir 32 beaux bits gachés alors qu'avec un code plus
compact, on aurait pu utiliser AL *et* AH, BL *et* BH, etc...
Tu m'expliqueras comment utiliser les 16 bits de poids fort de EAX
indépendament de AL/AH/AX, autrement qu'au prix de contortions genre
rotations sur 16 bits qui te font perdre en octets de code dix fois ce que
tu gagnes en espace de stockage, et un rapport 100 au niveau des cycles
processeur.
MOVSX/MOVZX est plus cher qu'un simple MOV (dépend processeur), et coûte 1 ou 2 octets de code en plus
Comment ? Pas un seul compilo encore capable d'utiliser les registres 8 bits de l'intel ?
Si tu déclares
int a; char i; a = a + i;
il faut des compilos passablement intelligents pour s'apercevoir qu'il n'y a jamais de débordement, ou bien que le débordement n'a pas de conséquences pratiques.
La misère de voir 32 beaux bits gachés alors qu'avec un code plus compact, on aurait pu utiliser AL *et* AH, BL *et* BH, etc...
Tu m'expliqueras comment utiliser les 16 bits de poids fort de EAX indépendament de AL/AH/AX, autrement qu'au prix de contortions genre rotations sur 16 bits qui te font perdre en octets de code dix fois ce que tu gagnes en espace de stockage, et un rapport 100 au niveau des cycles processeur.
Antoine
cedric
Antoine Leca wrote:
Tu m'expliqueras comment utiliser les 16 bits de poids fort de EAX indépendament de AL/AH/AX, autrement qu'au prix de contortions genre rotations sur 16 bits qui te font perdre en octets de code dix fois ce que tu gagnes en espace de stockage, et un rapport 100 au niveau des cycles processeur.
Evidement. Mais si tu as juste 8 chars à manipuler, c'est possible élégament sur cette plateforme avec les registres 8 bits sans rien stoquer en mémoire.
Antoine Leca wrote:
Tu m'expliqueras comment utiliser les 16 bits de poids fort de EAX
indépendament de AL/AH/AX, autrement qu'au prix de contortions genre
rotations sur 16 bits qui te font perdre en octets de code dix fois ce que
tu gagnes en espace de stockage, et un rapport 100 au niveau des cycles
processeur.
Evidement.
Mais si tu as juste 8 chars à manipuler, c'est possible élégament sur
cette plateforme avec les registres 8 bits sans rien stoquer en mémoire.
Tu m'expliqueras comment utiliser les 16 bits de poids fort de EAX indépendament de AL/AH/AX, autrement qu'au prix de contortions genre rotations sur 16 bits qui te font perdre en octets de code dix fois ce que tu gagnes en espace de stockage, et un rapport 100 au niveau des cycles processeur.
Evidement. Mais si tu as juste 8 chars à manipuler, c'est possible élégament sur cette plateforme avec les registres 8 bits sans rien stoquer en mémoire.
Alexandre Bacquart
Antoine Leca wrote:
En 40f65c72$0$16280$, cedric va escriure:
Antoine Leca wrote:
Et en version char, tu vas avoir
MOVsX EXX, i ADD a, EXX
MOVSX/MOVZX est plus cher qu'un simple MOV (dépend processeur), et coûte 1 ou 2 octets de code en plus
Comment ? Pas un seul compilo encore capable d'utiliser les registres 8 bits de l'intel ?
Si tu déclares
int a; char i; a = a + i;
il faut des compilos passablement intelligents pour s'apercevoir qu'il n'y a jamais de débordement, ou bien que le débordement n'a pas de conséquences pratiques.
La misère de voir 32 beaux bits gachés alors qu'avec un code plus compact, on aurait pu utiliser AL *et* AH, BL *et* BH, etc...
Tu m'expliqueras comment utiliser les 16 bits de poids fort de EAX indépendament de AL/AH/AX, autrement qu'au prix de contortions genre rotations sur 16 bits qui te font perdre en octets de code dix fois ce que tu gagnes en espace de stockage, et un rapport 100 au niveau des cycles processeur.
Heu... y'a pas une mnémonique genre SWAP sur x86 ?...
'fin bon, ca prend toujours un peu de temps et c'est plus du C...
-- Tek
Antoine Leca wrote:
En 40f65c72$0$16280$626a14ce@news.free.fr, cedric va escriure:
Antoine Leca wrote:
Et en version char, tu vas avoir
MOVsX EXX, i
ADD a, EXX
MOVSX/MOVZX est plus cher qu'un simple MOV (dépend processeur), et
coûte 1 ou 2 octets de code en plus
Comment ? Pas un seul compilo encore capable d'utiliser les registres
8 bits de l'intel ?
Si tu déclares
int a; char i;
a = a + i;
il faut des compilos passablement intelligents pour s'apercevoir qu'il n'y a
jamais de débordement, ou bien que le débordement n'a pas de conséquences
pratiques.
La misère de voir 32 beaux bits gachés alors qu'avec un code plus
compact, on aurait pu utiliser AL *et* AH, BL *et* BH, etc...
Tu m'expliqueras comment utiliser les 16 bits de poids fort de EAX
indépendament de AL/AH/AX, autrement qu'au prix de contortions genre
rotations sur 16 bits qui te font perdre en octets de code dix fois ce que
tu gagnes en espace de stockage, et un rapport 100 au niveau des cycles
processeur.
Heu... y'a pas une mnémonique genre SWAP sur x86 ?...
'fin bon, ca prend toujours un peu de temps et c'est plus du C...
MOVSX/MOVZX est plus cher qu'un simple MOV (dépend processeur), et coûte 1 ou 2 octets de code en plus
Comment ? Pas un seul compilo encore capable d'utiliser les registres 8 bits de l'intel ?
Si tu déclares
int a; char i; a = a + i;
il faut des compilos passablement intelligents pour s'apercevoir qu'il n'y a jamais de débordement, ou bien que le débordement n'a pas de conséquences pratiques.
La misère de voir 32 beaux bits gachés alors qu'avec un code plus compact, on aurait pu utiliser AL *et* AH, BL *et* BH, etc...
Tu m'expliqueras comment utiliser les 16 bits de poids fort de EAX indépendament de AL/AH/AX, autrement qu'au prix de contortions genre rotations sur 16 bits qui te font perdre en octets de code dix fois ce que tu gagnes en espace de stockage, et un rapport 100 au niveau des cycles processeur.
Heu... y'a pas une mnémonique genre SWAP sur x86 ?...
'fin bon, ca prend toujours un peu de temps et c'est plus du C...
-- Tek
Alexandre Bacquart
Antoine Leca wrote:
En , Emmanuel Delahaye va escriure:
In 'fr.comp.lang.c', Alexandre Bacquart wrote:
En mémoire, oui, mais au prix d'une réduction de la performance pour les adresses impaires.
Equivalent à la lecture de 16 bits (int sur 68k). On économise la place,
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Non. Il y a deux "modèles" de processeur avec le 680x0: 16 bits ou 32 bits (taille des int).
En effet, mais nous parlions du 68000, par des 680x0.
Le jeu d'instructions sait manipuler de la même manière des quantités sur 16 ou 32 bits (sauf peut-être les instructions les plus alambiquées genre CAS2). Mais ce n'était pas vrai pour les modes d'adressage (indexation etc.): dans les versions initiales (<68020), il n'étaient pas tous les disponible en version 32 bits, donc il était intéressant d'avoir des int sur 16 bits pour par exemple indexer les tableaux. De plus, bien sûr, cela économisait de la place en mémoire centrale, important en 1980.
Ouaip.
Au niveau des pointeurs, le plus souvent ils étaient sur 32 bits, mais je crois bien qu'il y eut des compilos pour 680x0 avec des pointeurs sur 16 bits, dans un espace mémoire limité à 64 K (et les parties hautes de A0-A7 étaient forcées à 0).
Évidement, tout ceci est historique: aujourd'hui tous les compilos pour 68k sont des compilos 32 bits.
Ce qui fait que dans le cas <68020, un int implémenté en 32 bits n'est plus le type le plus approprié en termes de vitesse et de place (et sur un 68008, cela devient réellement critique).
-- Tek
Antoine Leca wrote:
En Xns9526CBAB59175hsnoservernet@212.27.42.71, Emmanuel Delahaye va
escriure:
In 'fr.comp.lang.c', Alexandre Bacquart <tek512@hotmail.com> wrote:
En mémoire, oui, mais au prix d'une réduction de la performance
pour les adresses impaires.
Equivalent à la lecture de 16 bits (int sur 68k). On économise la
place,
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Non. Il y a deux "modèles" de processeur avec le 680x0: 16 bits ou 32 bits
(taille des int).
En effet, mais nous parlions du 68000, par des 680x0.
Le jeu d'instructions sait manipuler de la même manière
des quantités sur 16 ou 32 bits (sauf peut-être les instructions les plus
alambiquées genre CAS2). Mais ce n'était pas vrai pour les modes d'adressage
(indexation etc.): dans les versions initiales (<68020), il n'étaient pas
tous les disponible en version 32 bits, donc il était intéressant d'avoir
des int sur 16 bits pour par exemple indexer les tableaux. De plus, bien
sûr, cela économisait de la place en mémoire centrale, important en 1980.
Ouaip.
Au niveau des pointeurs, le plus souvent ils étaient sur 32 bits, mais je
crois bien qu'il y eut des compilos pour 680x0 avec des pointeurs sur 16
bits, dans un espace mémoire limité à 64 K (et les parties hautes de A0-A7
étaient forcées à 0).
Évidement, tout ceci est historique: aujourd'hui tous les compilos pour 68k
sont des compilos 32 bits.
Ce qui fait que dans le cas <68020, un int implémenté en 32 bits n'est
plus le type le plus approprié en termes de vitesse et de place (et sur
un 68008, cela devient réellement critique).
Le jeu d'instructions sait manipuler de la même manière des quantités sur 16 ou 32 bits (sauf peut-être les instructions les plus alambiquées genre CAS2). Mais ce n'était pas vrai pour les modes d'adressage (indexation etc.): dans les versions initiales (<68020), il n'étaient pas tous les disponible en version 32 bits, donc il était intéressant d'avoir des int sur 16 bits pour par exemple indexer les tableaux. De plus, bien sûr, cela économisait de la place en mémoire centrale, important en 1980.
Ouaip.
Au niveau des pointeurs, le plus souvent ils étaient sur 32 bits, mais je crois bien qu'il y eut des compilos pour 680x0 avec des pointeurs sur 16 bits, dans un espace mémoire limité à 64 K (et les parties hautes de A0-A7 étaient forcées à 0).
Évidement, tout ceci est historique: aujourd'hui tous les compilos pour 68k sont des compilos 32 bits.
Ce qui fait que dans le cas <68020, un int implémenté en 32 bits n'est plus le type le plus approprié en termes de vitesse et de place (et sur un 68008, cela devient réellement critique).
-- Tek
kUfa
Le jeu d'instructions sait manipuler de la même manière des quantités sur 16 ou 32 bits (sauf peut-être les instructions les plus alambiquées genre CAS2)
Enfin je penserai plus au fait que l'on ne peut pas indexer sur 32 bits sut PC, qu'il n'y a pas de multiplications 32 bits, et surtout lorsqu on ne peut pas faire un addressage rescale.
Mais ce n'était pas vrai pour les modes d'adressage (indexation etc.): dans les versions initiales (<68020), il n'étaient pas tous les disponible en version 32 bits, donc il était intéressant d'avoir des int sur 16 bits pour par exemple indexer les tableaux.
Non tu peux indexer en 32 bits sur autre chose que a7.
/kUfa.Scoopex^Scarab
Le jeu d'instructions sait manipuler de la même manière
des quantités sur 16 ou 32 bits (sauf peut-être les instructions les plus
alambiquées genre CAS2)
Enfin je penserai plus au fait que l'on ne peut pas indexer sur 32 bits sut PC,
qu'il n'y a pas de multiplications 32 bits, et surtout lorsqu on ne peut pas
faire un addressage rescale.
Mais ce n'était pas vrai pour les modes d'adressage
(indexation etc.): dans les versions initiales (<68020), il n'étaient pas
tous les disponible en version 32 bits, donc il était intéressant d'avoir
des int sur 16 bits pour par exemple indexer les tableaux.
Non tu peux indexer en 32 bits sur autre chose que a7.
Le jeu d'instructions sait manipuler de la même manière des quantités sur 16 ou 32 bits (sauf peut-être les instructions les plus alambiquées genre CAS2)
Enfin je penserai plus au fait que l'on ne peut pas indexer sur 32 bits sut PC, qu'il n'y a pas de multiplications 32 bits, et surtout lorsqu on ne peut pas faire un addressage rescale.
Mais ce n'était pas vrai pour les modes d'adressage (indexation etc.): dans les versions initiales (<68020), il n'étaient pas tous les disponible en version 32 bits, donc il était intéressant d'avoir des int sur 16 bits pour par exemple indexer les tableaux.
Non tu peux indexer en 32 bits sur autre chose que a7.
/kUfa.Scoopex^Scarab
Antoine Leca
En 40f6cad8$0$15283$, Alexandre Bacquart va escriure:
Antoine Leca wrote:
En , Emmanuel Delahaye va escriure:
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Non. Il y a deux "modèles" de processeur avec le 680x0: 16 bits ou 32 bits (taille des int).
En effet, mais nous parlions du 68000, par des 680x0.
Vous parliez de « 68k » (nonobstant ce qu'a écrit Emmanuel ci-dessus). Et les deux "modèles" de code généré ont coexisté, dès 1980, dans le code généré pour les 68000/68010/68008.
Ne mélangeons pas. Tu sembles mettre en exergue la taille externe du bus de données et la taille des registres; ce n'est pas le plus intéressant du point de vue du langage C (et il ne vient à l'idée de personne de dire que le Pentium est un processeur 64 bits). De plus, si on suit ton raisonnement, un compilo pour 68008 serait un compilo 8 bits ! ;-)
Ce qui fait que dans le cas <68020, un int implémenté en 32 bits n'est plus le type le plus approprié en termes de vitesse et de place (et sur un 68008, cela devient réellement critique).
D'un autre côté, quand tu as des tonnes de code qui fut écrit (pour PDP11 ou Vax) avec l'idée que un pointeur peut être stocké dans un int, c'est "utile" de pouvoir récupérer cet existant sans devoir tout refaire... D'où le choix proposé.
Antoine
En 40f6cad8$0$15283$636a15ce@news.free.fr, Alexandre Bacquart va escriure:
Antoine Leca wrote:
En Xns9526CBAB59175hsnoservernet@212.27.42.71, Emmanuel Delahaye va
escriure:
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Non. Il y a deux "modèles" de processeur avec le 680x0: 16 bits ou
32 bits (taille des int).
En effet, mais nous parlions du 68000, par des 680x0.
Vous parliez de « 68k » (nonobstant ce qu'a écrit Emmanuel ci-dessus). Et
les deux "modèles" de code généré ont coexisté, dès 1980, dans le code
généré pour les 68000/68010/68008.
Ne mélangeons pas. Tu sembles mettre en exergue la taille externe du bus de
données et la taille des registres; ce n'est pas le plus intéressant du
point de vue du langage C (et il ne vient à l'idée de personne de dire que
le Pentium est un processeur 64 bits). De plus, si on suit ton raisonnement,
un compilo pour 68008 serait un compilo 8 bits ! ;-)
Ce qui fait que dans le cas <68020, un int implémenté en 32 bits n'est
plus le type le plus approprié en termes de vitesse et de place (et
sur un 68008, cela devient réellement critique).
D'un autre côté, quand tu as des tonnes de code qui fut écrit (pour PDP11 ou
Vax) avec l'idée que un pointeur peut être stocké dans un int, c'est "utile"
de pouvoir récupérer cet existant sans devoir tout refaire... D'où le choix
proposé.
En 40f6cad8$0$15283$, Alexandre Bacquart va escriure:
Antoine Leca wrote:
En , Emmanuel Delahaye va escriure:
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Non. Il y a deux "modèles" de processeur avec le 680x0: 16 bits ou 32 bits (taille des int).
En effet, mais nous parlions du 68000, par des 680x0.
Vous parliez de « 68k » (nonobstant ce qu'a écrit Emmanuel ci-dessus). Et les deux "modèles" de code généré ont coexisté, dès 1980, dans le code généré pour les 68000/68010/68008.
Ne mélangeons pas. Tu sembles mettre en exergue la taille externe du bus de données et la taille des registres; ce n'est pas le plus intéressant du point de vue du langage C (et il ne vient à l'idée de personne de dire que le Pentium est un processeur 64 bits). De plus, si on suit ton raisonnement, un compilo pour 68008 serait un compilo 8 bits ! ;-)
Ce qui fait que dans le cas <68020, un int implémenté en 32 bits n'est plus le type le plus approprié en termes de vitesse et de place (et sur un 68008, cela devient réellement critique).
D'un autre côté, quand tu as des tonnes de code qui fut écrit (pour PDP11 ou Vax) avec l'idée que un pointeur peut être stocké dans un int, c'est "utile" de pouvoir récupérer cet existant sans devoir tout refaire... D'où le choix proposé.
Antoine
Alexandre Bacquart
Alexandre Bacquart wrote:
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Alexandre Bacquart wrote:
Oups, j'avais oublié ce détail... Ok, le bus de données externe est 16-bit, mais il y a un bus interne 32-bits entre l'ALU et les registres, non?
Oui heureusement :) On dit aussi que le 68000 est un 16/32 bits.
Petite rectification car c'est encore pire : le bus *interne* est aussi 16 bits, mais souvent sans surcoût pour les opérations 32 bits. Je n'ai pas trouvé plus de détails quand à son fonctionnement précis (multiplex ? ..), mais je me doute bien que tout le monde s'en fout. Juste pour me corriger.
-- Tek
Alexandre Bacquart wrote:
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Alexandre Bacquart <tek512@hotmail.com> wrote:
Oups, j'avais oublié ce détail... Ok, le bus de données externe est
16-bit, mais il y a un bus interne 32-bits entre l'ALU et les
registres, non?
Oui heureusement :) On dit aussi que le 68000 est un 16/32 bits.
Petite rectification car c'est encore pire : le bus *interne* est aussi
16 bits, mais souvent sans surcoût pour les opérations 32 bits. Je n'ai
pas trouvé plus de détails quand à son fonctionnement précis (multiplex
? ..), mais je me doute bien que tout le monde s'en fout. Juste pour me
corriger.
Oups, j'avais oublié ce détail... Ok, le bus de données externe est 16-bit, mais il y a un bus interne 32-bits entre l'ALU et les registres, non?
Oui heureusement :) On dit aussi que le 68000 est un 16/32 bits.
Petite rectification car c'est encore pire : le bus *interne* est aussi 16 bits, mais souvent sans surcoût pour les opérations 32 bits. Je n'ai pas trouvé plus de détails quand à son fonctionnement précis (multiplex ? ..), mais je me doute bien que tout le monde s'en fout. Juste pour me corriger.
-- Tek
Antoine Leca
En 410efae3$0$32524$, Alexandre Bacquart va escriure:
Oui heureusement :) On dit aussi que le 68000 est un 16/32 bits.
Petite rectification car c'est encore pire : le bus *interne* est aussi 16 bits, mais souvent sans surcoût pour les opérations 32 bits.
Ce ne serait pas l'UAL qui serait sur 32 bits, alors ?
Je n'ai pas trouvé plus de détails quand à son fonctionnement précis (multiplex ? ..), mais je me doute bien que tout le monde s'en fout.
Cela devait coûter plus cher de faire le démultiplexage au niveau interface extérieur que de le faire au niveau de l'interface avec la banque de registres ou l'UAL.
Antoine
En 410efae3$0$32524$626a14ce@news.free.fr, Alexandre Bacquart va escriure:
Oui heureusement :) On dit aussi que le 68000 est un 16/32 bits.
Petite rectification car c'est encore pire : le bus *interne* est
aussi 16 bits, mais souvent sans surcoût pour les opérations 32 bits.
Ce ne serait pas l'UAL qui serait sur 32 bits, alors ?
Je n'ai pas trouvé plus de détails quand à son fonctionnement précis
(multiplex ? ..), mais je me doute bien que tout le monde s'en fout.
Cela devait coûter plus cher de faire le démultiplexage au niveau interface
extérieur que de le faire au niveau de l'interface avec la banque de
registres ou l'UAL.
En 410efae3$0$32524$, Alexandre Bacquart va escriure:
Oui heureusement :) On dit aussi que le 68000 est un 16/32 bits.
Petite rectification car c'est encore pire : le bus *interne* est aussi 16 bits, mais souvent sans surcoût pour les opérations 32 bits.
Ce ne serait pas l'UAL qui serait sur 32 bits, alors ?
Je n'ai pas trouvé plus de détails quand à son fonctionnement précis (multiplex ? ..), mais je me doute bien que tout le monde s'en fout.
Cela devait coûter plus cher de faire le démultiplexage au niveau interface extérieur que de le faire au niveau de l'interface avec la banque de registres ou l'UAL.
Antoine
Alexandre Bacquart
Antoine Leca wrote:
En 410efae3$0$32524$, Alexandre Bacquart va escriure:
Oui heureusement :) On dit aussi que le 68000 est un 16/32 bits.
Petite rectification car c'est encore pire : le bus *interne* est aussi 16 bits, mais souvent sans surcoût pour les opérations 32 bits.
Ce ne serait pas l'UAL qui serait sur 32 bits, alors ?
Même pas... le débat est presque aussi vieux que le 68000 et il y a beaucoup de désinformation de la part des coders 68k eux-même; la majorité semble croire qu'en interne le 68000 est 32 bits et cela s'explique simplement par le fait que toute son architecture *logique* est 32 bits (donc implémentation possible d'un 68000 full 32 bits, peut-être qu'elles ont même existé en cablé, je ne saurais le dire). Du point de vue du programmeur, c'est 32 bits. La FAQ de comp.sys.m68k n'en parle pas, c'est dire si le sujet attise les foules...
D'après les tables de cycles du 68000 (et là du coup, je sors du grenier mon bon vieux "Mise en oeuvre du 68000" de Catherine Vieillefond) il y a clairement un surcoût (2 passes et vlan) pour les opérations arithmétiques 32 bits sur les données. Pas pour les adresses cependant, mais les cycles montrent que les calculs sur les adresses sont de toutes façons plus lents que sur les données 16 bits (néanmoins optimisés en 32 bits par un mécanisme de cascades):
ADD.W D0,D1 ;4 cycles ADDA.W A0,A1 ;8 cycles
En 32 bits :
ADD D0,D1 ;6 cycles ADDA A0,A1 ;6 cycles (exotique oui, mais j'm'a pas trompé)
Sachant que NOP = 4 cycles, il est clair que le 68000 est un processeur au fonctionnement interne de 16 bits. J'avais ces tables accrochées au mur derrière mon Atari ST et même si je devais être bien au courant de ce surcoût (je chassais le cycle machine à l'époque), ça ne m'a jamais mis la puce à l'oreille... jusqu'à aujourd'hui. En fait, il semble même qu'en interne chez Motorola, le 68000 ait été développé dans la section 16 bits.
Catherine ne semble pas aborder le bus interne du 68000 (et il faut reconnaître que pour "mettre en oeuvre le 68000", l'info n'est pas pertinente). Cependant lorsqu'en annexe elle parle du 68020 et qu'elle détaille ses "plus" par rapport à ses prédécesseurs, elle spécifie la taille du bus interne et de l'ALU en 32 bits, faisant de lui un véritable CPU 32 bits.
Vu que leur FAQ n'en parle pas, je n'ose pas troller sur comp.sys.m68k, et j'ai assez d'infos je crois.
Je n'ai pas trouvé plus de détails quand à son fonctionnement précis (multiplex ? ..), mais je me doute bien que tout le monde s'en fout.
Cela devait coûter plus cher de faire le démultiplexage au niveau interface extérieur que de le faire au niveau de l'interface avec la banque de registres ou l'UAL.
Certes.
-- Tek
Antoine Leca wrote:
En 410efae3$0$32524$626a14ce@news.free.fr, Alexandre Bacquart va escriure:
Oui heureusement :) On dit aussi que le 68000 est un 16/32 bits.
Petite rectification car c'est encore pire : le bus *interne* est
aussi 16 bits, mais souvent sans surcoût pour les opérations 32 bits.
Ce ne serait pas l'UAL qui serait sur 32 bits, alors ?
Même pas... le débat est presque aussi vieux que le 68000 et il y a
beaucoup de désinformation de la part des coders 68k eux-même; la
majorité semble croire qu'en interne le 68000 est 32 bits et cela
s'explique simplement par le fait que toute son architecture *logique*
est 32 bits (donc implémentation possible d'un 68000 full 32 bits,
peut-être qu'elles ont même existé en cablé, je ne saurais le dire). Du
point de vue du programmeur, c'est 32 bits. La FAQ de comp.sys.m68k n'en
parle pas, c'est dire si le sujet attise les foules...
D'après les tables de cycles du 68000 (et là du coup, je sors du grenier
mon bon vieux "Mise en oeuvre du 68000" de Catherine Vieillefond) il y a
clairement un surcoût (2 passes et vlan) pour les opérations
arithmétiques 32 bits sur les données. Pas pour les adresses cependant,
mais les cycles montrent que les calculs sur les adresses sont de toutes
façons plus lents que sur les données 16 bits (néanmoins optimisés en 32
bits par un mécanisme de cascades):
ADD.W D0,D1 ;4 cycles
ADDA.W A0,A1 ;8 cycles
En 32 bits :
ADD D0,D1 ;6 cycles
ADDA A0,A1 ;6 cycles (exotique oui, mais j'm'a pas trompé)
Sachant que NOP = 4 cycles, il est clair que le 68000 est un processeur
au fonctionnement interne de 16 bits. J'avais ces tables accrochées au
mur derrière mon Atari ST et même si je devais être bien au courant de
ce surcoût (je chassais le cycle machine à l'époque), ça ne m'a jamais
mis la puce à l'oreille... jusqu'à aujourd'hui. En fait, il semble même
qu'en interne chez Motorola, le 68000 ait été développé dans la section
16 bits.
Catherine ne semble pas aborder le bus interne du 68000 (et il faut
reconnaître que pour "mettre en oeuvre le 68000", l'info n'est pas
pertinente). Cependant lorsqu'en annexe elle parle du 68020 et qu'elle
détaille ses "plus" par rapport à ses prédécesseurs, elle spécifie la
taille du bus interne et de l'ALU en 32 bits, faisant de lui un
véritable CPU 32 bits.
Vu que leur FAQ n'en parle pas, je n'ose pas troller sur comp.sys.m68k,
et j'ai assez d'infos je crois.
Je n'ai pas trouvé plus de détails quand à son fonctionnement précis
(multiplex ? ..), mais je me doute bien que tout le monde s'en fout.
Cela devait coûter plus cher de faire le démultiplexage au niveau interface
extérieur que de le faire au niveau de l'interface avec la banque de
registres ou l'UAL.
En 410efae3$0$32524$, Alexandre Bacquart va escriure:
Oui heureusement :) On dit aussi que le 68000 est un 16/32 bits.
Petite rectification car c'est encore pire : le bus *interne* est aussi 16 bits, mais souvent sans surcoût pour les opérations 32 bits.
Ce ne serait pas l'UAL qui serait sur 32 bits, alors ?
Même pas... le débat est presque aussi vieux que le 68000 et il y a beaucoup de désinformation de la part des coders 68k eux-même; la majorité semble croire qu'en interne le 68000 est 32 bits et cela s'explique simplement par le fait que toute son architecture *logique* est 32 bits (donc implémentation possible d'un 68000 full 32 bits, peut-être qu'elles ont même existé en cablé, je ne saurais le dire). Du point de vue du programmeur, c'est 32 bits. La FAQ de comp.sys.m68k n'en parle pas, c'est dire si le sujet attise les foules...
D'après les tables de cycles du 68000 (et là du coup, je sors du grenier mon bon vieux "Mise en oeuvre du 68000" de Catherine Vieillefond) il y a clairement un surcoût (2 passes et vlan) pour les opérations arithmétiques 32 bits sur les données. Pas pour les adresses cependant, mais les cycles montrent que les calculs sur les adresses sont de toutes façons plus lents que sur les données 16 bits (néanmoins optimisés en 32 bits par un mécanisme de cascades):
ADD.W D0,D1 ;4 cycles ADDA.W A0,A1 ;8 cycles
En 32 bits :
ADD D0,D1 ;6 cycles ADDA A0,A1 ;6 cycles (exotique oui, mais j'm'a pas trompé)
Sachant que NOP = 4 cycles, il est clair que le 68000 est un processeur au fonctionnement interne de 16 bits. J'avais ces tables accrochées au mur derrière mon Atari ST et même si je devais être bien au courant de ce surcoût (je chassais le cycle machine à l'époque), ça ne m'a jamais mis la puce à l'oreille... jusqu'à aujourd'hui. En fait, il semble même qu'en interne chez Motorola, le 68000 ait été développé dans la section 16 bits.
Catherine ne semble pas aborder le bus interne du 68000 (et il faut reconnaître que pour "mettre en oeuvre le 68000", l'info n'est pas pertinente). Cependant lorsqu'en annexe elle parle du 68020 et qu'elle détaille ses "plus" par rapport à ses prédécesseurs, elle spécifie la taille du bus interne et de l'ALU en 32 bits, faisant de lui un véritable CPU 32 bits.
Vu que leur FAQ n'en parle pas, je n'ose pas troller sur comp.sys.m68k, et j'ai assez d'infos je crois.
Je n'ai pas trouvé plus de détails quand à son fonctionnement précis (multiplex ? ..), mais je me doute bien que tout le monde s'en fout.
Cela devait coûter plus cher de faire le démultiplexage au niveau interface extérieur que de le faire au niveau de l'interface avec la banque de registres ou l'UAL.
