On 8 mar, 23:40, Sylvain wrote:James Kanze wrote on 07/03/2008 22:01:Le type influence bien comment on y accède.
c'est en substance tout à fait contradictoire avec tes
positions du fil précédent.
Explique, si te plais. Je ne vois pas comment le type ne
pourrait pas influencer comment on accède aux objets---quand
j'accède à travers un lvalue de type char, par exemple, je
n'accède qu'aux huit bits, tandis qu'avec int... Et je suis
certain de ne jamais avoir dit le contraire.
La norme guarantee qu'un accès à un unsigned char fonctionne.
Même si l'unsigned char n'a jamais été initialisé (mais
évidemment, la valeur que tu vois n'est pas déterminé dans ce
cas-là). La norme ne fait cette garantie pour aucune autre type.
On 8 mar, 23:40, Sylvain <noS...@mail.net> wrote:
James Kanze wrote on 07/03/2008 22:01:
Le type influence bien comment on y accède.
c'est en substance tout à fait contradictoire avec tes
positions du fil précédent.
Explique, si te plais. Je ne vois pas comment le type ne
pourrait pas influencer comment on accède aux objets---quand
j'accède à travers un lvalue de type char, par exemple, je
n'accède qu'aux huit bits, tandis qu'avec int... Et je suis
certain de ne jamais avoir dit le contraire.
La norme guarantee qu'un accès à un unsigned char fonctionne.
Même si l'unsigned char n'a jamais été initialisé (mais
évidemment, la valeur que tu vois n'est pas déterminé dans ce
cas-là). La norme ne fait cette garantie pour aucune autre type.
On 8 mar, 23:40, Sylvain wrote:James Kanze wrote on 07/03/2008 22:01:Le type influence bien comment on y accède.
c'est en substance tout à fait contradictoire avec tes
positions du fil précédent.
Explique, si te plais. Je ne vois pas comment le type ne
pourrait pas influencer comment on accède aux objets---quand
j'accède à travers un lvalue de type char, par exemple, je
n'accède qu'aux huit bits, tandis qu'avec int... Et je suis
certain de ne jamais avoir dit le contraire.
La norme guarantee qu'un accès à un unsigned char fonctionne.
Même si l'unsigned char n'a jamais été initialisé (mais
évidemment, la valeur que tu vois n'est pas déterminé dans ce
cas-là). La norme ne fait cette garantie pour aucune autre type.
James Kanze wrote on 09/03/2008 12:04:On 8 mar, 23:40, Sylvain wrote:James Kanze wrote on 07/03/2008 22:01:Le type influence bien comment on y accède.
c'est en substance tout à fait contradictoire avec tes
positions du fil précédent.
Explique, si te plais. Je ne vois pas comment le type ne
pourrait pas influencer comment on accède aux objets---quand
j'accède à travers un lvalue de type char, par exemple, je
n'accède qu'aux huit bits, tandis qu'avec int... Et je suis
certain de ne jamais avoir dit le contraire.
contradictoire avec:
"À la mise sous tension, la mémoire contient effectivement"
"n'importe quoi. (Aussi, la plupart des contrôleurs dont je me"
"suis servi dans le temps prévoyaient bien une commande pour"
"écrire des valeurs erronées. Pour des motifs de test, si rien"
"d'autre. Mais le problème réel, c'est que jusqu'à la première"
"écriture, le contenu n'est pas défini, et il y a des chances"
"qu'il soit invalid.)"
la "mise sous tension" ne préjuge pas du fait qu'uen cellule
sera vue comme une variable signée ou non-signée.
btw, que le char signed 'signed' ou 'unsigned' il me semble
bien qu'on accède à 8 bits en effet, enfin les signed char ne
font pas 9 bits (utiles) chez moi.
j'écrivais dans un post précédent qui n'ai pas apparu ici,
qu'il était évident que l'arithmétique associé à un entier
dépendait de son caractère signé ou non, pour autant son
*chargement* (mov al,[di] ou stosb ou lea al,offset) sont
uniques: i n'y a pas la "version qui plante avec un signé"
et celle qui "ne plante pas quelque soit le CRC puisque
c'est un unsigned là hein".
James Kanze wrote on 09/03/2008 12:04:
On 8 mar, 23:40, Sylvain <noS...@mail.net> wrote:
James Kanze wrote on 07/03/2008 22:01:
Le type influence bien comment on y accède.
c'est en substance tout à fait contradictoire avec tes
positions du fil précédent.
Explique, si te plais. Je ne vois pas comment le type ne
pourrait pas influencer comment on accède aux objets---quand
j'accède à travers un lvalue de type char, par exemple, je
n'accède qu'aux huit bits, tandis qu'avec int... Et je suis
certain de ne jamais avoir dit le contraire.
contradictoire avec:
<c044ccdb-93d3-4563-af63-f4d415b7c...@s12g2000prg.googlegroups.com>
"À la mise sous tension, la mémoire contient effectivement"
"n'importe quoi. (Aussi, la plupart des contrôleurs dont je me"
"suis servi dans le temps prévoyaient bien une commande pour"
"écrire des valeurs erronées. Pour des motifs de test, si rien"
"d'autre. Mais le problème réel, c'est que jusqu'à la première"
"écriture, le contenu n'est pas défini, et il y a des chances"
"qu'il soit invalid.)"
la "mise sous tension" ne préjuge pas du fait qu'uen cellule
sera vue comme une variable signée ou non-signée.
btw, que le char signed 'signed' ou 'unsigned' il me semble
bien qu'on accède à 8 bits en effet, enfin les signed char ne
font pas 9 bits (utiles) chez moi.
j'écrivais dans un post précédent qui n'ai pas apparu ici,
qu'il était évident que l'arithmétique associé à un entier
dépendait de son caractère signé ou non, pour autant son
*chargement* (mov al,[di] ou stosb ou lea al,offset) sont
uniques: i n'y a pas la "version qui plante avec un signé"
et celle qui "ne plante pas quelque soit le CRC puisque
c'est un unsigned là hein".
James Kanze wrote on 09/03/2008 12:04:On 8 mar, 23:40, Sylvain wrote:James Kanze wrote on 07/03/2008 22:01:Le type influence bien comment on y accède.
c'est en substance tout à fait contradictoire avec tes
positions du fil précédent.
Explique, si te plais. Je ne vois pas comment le type ne
pourrait pas influencer comment on accède aux objets---quand
j'accède à travers un lvalue de type char, par exemple, je
n'accède qu'aux huit bits, tandis qu'avec int... Et je suis
certain de ne jamais avoir dit le contraire.
contradictoire avec:
"À la mise sous tension, la mémoire contient effectivement"
"n'importe quoi. (Aussi, la plupart des contrôleurs dont je me"
"suis servi dans le temps prévoyaient bien une commande pour"
"écrire des valeurs erronées. Pour des motifs de test, si rien"
"d'autre. Mais le problème réel, c'est que jusqu'à la première"
"écriture, le contenu n'est pas défini, et il y a des chances"
"qu'il soit invalid.)"
la "mise sous tension" ne préjuge pas du fait qu'uen cellule
sera vue comme une variable signée ou non-signée.
btw, que le char signed 'signed' ou 'unsigned' il me semble
bien qu'on accède à 8 bits en effet, enfin les signed char ne
font pas 9 bits (utiles) chez moi.
j'écrivais dans un post précédent qui n'ai pas apparu ici,
qu'il était évident que l'arithmétique associé à un entier
dépendait de son caractère signé ou non, pour autant son
*chargement* (mov al,[di] ou stosb ou lea al,offset) sont
uniques: i n'y a pas la "version qui plante avec un signé"
et celle qui "ne plante pas quelque soit le CRC puisque
c'est un unsigned là hein".
Quand je parlais de différences en ce qui concerne la façon
qu'on accède aux valeurs, je pensais surtout aux différences
entre les accès byte et les accès mot. Sur le MCP, d'après le
peu que j'ai pû comprendre (je n'ai pas trouvé de doc
architecture ou hardware, seulement une description assez
détaillée des formats dans la doc ALGOL), l'accès char, unsigned
char et signed char doit se faire avec une instruction machine
qui ne prend pas en compte le tag (qui se trouve au niveau du
mot) ; les instructions d'accès mot, en revanche, doivent le
prendre bien en compte, mais je ne connais pas les détails.
Quand je parlais de différences en ce qui concerne la façon
qu'on accède aux valeurs, je pensais surtout aux différences
entre les accès byte et les accès mot. Sur le MCP, d'après le
peu que j'ai pû comprendre (je n'ai pas trouvé de doc
architecture ou hardware, seulement une description assez
détaillée des formats dans la doc ALGOL), l'accès char, unsigned
char et signed char doit se faire avec une instruction machine
qui ne prend pas en compte le tag (qui se trouve au niveau du
mot) ; les instructions d'accès mot, en revanche, doivent le
prendre bien en compte, mais je ne connais pas les détails.
Quand je parlais de différences en ce qui concerne la façon
qu'on accède aux valeurs, je pensais surtout aux différences
entre les accès byte et les accès mot. Sur le MCP, d'après le
peu que j'ai pû comprendre (je n'ai pas trouvé de doc
architecture ou hardware, seulement une description assez
détaillée des formats dans la doc ALGOL), l'accès char, unsigned
char et signed char doit se faire avec une instruction machine
qui ne prend pas en compte le tag (qui se trouve au niveau du
mot) ; les instructions d'accès mot, en revanche, doivent le
prendre bien en compte, mais je ne connais pas les détails.
James Kanze wrote on 10/03/2008 09:47:Quand je parlais de différences en ce qui concerne la façon
qu'on accède aux valeurs, je pensais surtout aux différences
entre les accès byte et les accès mot. Sur le MCP, d'après le
peu que j'ai pû comprendre (je n'ai pas trouvé de doc
architecture ou hardware, seulement une description assez
détaillée des formats dans la doc ALGOL), l'accès char, unsigned
char et signed char doit se faire avec une instruction machine
qui ne prend pas en compte le tag (qui se trouve au niveau du
mot) ; les instructions d'accès mot, en revanche, doivent le
prendre bien en compte, mais je ne connais pas les détails.
moi non plus je ne connais pas ces détails et j'ai bcp de mal à
imaginer le tag magique lu dans certaines conditions uniquement.
un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
- mais que les tests de parité ou
contrôle d'erreur dépendent de la taille mémoire accédée est
étonnant, d'autant plus que le proc lira souvent un mot complet
(demandera un mot complet au controleur mémoire) quand il traite
une opération d'un octet ... laissons cela aux électroniciens.
James Kanze wrote on 10/03/2008 09:47:
Quand je parlais de différences en ce qui concerne la façon
qu'on accède aux valeurs, je pensais surtout aux différences
entre les accès byte et les accès mot. Sur le MCP, d'après le
peu que j'ai pû comprendre (je n'ai pas trouvé de doc
architecture ou hardware, seulement une description assez
détaillée des formats dans la doc ALGOL), l'accès char, unsigned
char et signed char doit se faire avec une instruction machine
qui ne prend pas en compte le tag (qui se trouve au niveau du
mot) ; les instructions d'accès mot, en revanche, doivent le
prendre bien en compte, mais je ne connais pas les détails.
moi non plus je ne connais pas ces détails et j'ai bcp de mal à
imaginer le tag magique lu dans certaines conditions uniquement.
un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
- mais que les tests de parité ou
contrôle d'erreur dépendent de la taille mémoire accédée est
étonnant, d'autant plus que le proc lira souvent un mot complet
(demandera un mot complet au controleur mémoire) quand il traite
une opération d'un octet ... laissons cela aux électroniciens.
James Kanze wrote on 10/03/2008 09:47:Quand je parlais de différences en ce qui concerne la façon
qu'on accède aux valeurs, je pensais surtout aux différences
entre les accès byte et les accès mot. Sur le MCP, d'après le
peu que j'ai pû comprendre (je n'ai pas trouvé de doc
architecture ou hardware, seulement une description assez
détaillée des formats dans la doc ALGOL), l'accès char, unsigned
char et signed char doit se faire avec une instruction machine
qui ne prend pas en compte le tag (qui se trouve au niveau du
mot) ; les instructions d'accès mot, en revanche, doivent le
prendre bien en compte, mais je ne connais pas les détails.
moi non plus je ne connais pas ces détails et j'ai bcp de mal à
imaginer le tag magique lu dans certaines conditions uniquement.
un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
- mais que les tests de parité ou
contrôle d'erreur dépendent de la taille mémoire accédée est
étonnant, d'autant plus que le proc lira souvent un mot complet
(demandera un mot complet au controleur mémoire) quand il traite
une opération d'un octet ... laissons cela aux électroniciens.
On Mar 11, 12:25 am, Sylvain wrote:James Kanze wrote on 10/03/2008 09:47:Quand je parlais de différences en ce qui concerne la façon
qu'on accède aux valeurs, je pensais surtout aux différences
entre les accès byte et les accès mot. Sur le MCP, d'après le
peu que j'ai pû comprendre (je n'ai pas trouvé de doc
architecture ou hardware, seulement une description assez
détaillée des formats dans la doc ALGOL), l'accès char, unsigned
char et signed char doit se faire avec une instruction machine
qui ne prend pas en compte le tag (qui se trouve au niveau du
mot) ; les instructions d'accès mot, en revanche, doivent le
prendre bien en compte, mais je ne connais pas les détails.
moi non plus je ne connais pas ces détails et j'ai bcp de mal à
imaginer le tag magique lu dans certaines conditions uniquement.
L'idée d'une architecture tagguée a eu une vogue, l'idée étant de gerer
un peu les types dans le hardware.
Je crois que c'était très courant dans les machines Lisp, par exemple (où
le tag indiquerait si le mot mémoire était un atome ou une cellule de
cons). Dans les années 1970, j'ai aussi entendu parler d'une architecture
avec un tag sur les indirections. Quand on lisait à une adresse mémoire,
si le tag était positionné, le processeur utilisait la valeur comme une
adresse d'indirection (avec les désavantages évidents qu'avant d'écrire,
il fallait lire, qu'il fallait une instruction spéciale pour écrire des
pointeurs -- c-à-d un store data et un store address instruction -- et
qu'il fallait une logique supplémentaire pour détecter des cycles --
sinon, tu avais une instruction machine qui n'en finissait jamais).
un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
On Mar 11, 12:25 am, Sylvain <noS...@mail.net> wrote:
James Kanze wrote on 10/03/2008 09:47:
Quand je parlais de différences en ce qui concerne la façon
qu'on accède aux valeurs, je pensais surtout aux différences
entre les accès byte et les accès mot. Sur le MCP, d'après le
peu que j'ai pû comprendre (je n'ai pas trouvé de doc
architecture ou hardware, seulement une description assez
détaillée des formats dans la doc ALGOL), l'accès char, unsigned
char et signed char doit se faire avec une instruction machine
qui ne prend pas en compte le tag (qui se trouve au niveau du
mot) ; les instructions d'accès mot, en revanche, doivent le
prendre bien en compte, mais je ne connais pas les détails.
moi non plus je ne connais pas ces détails et j'ai bcp de mal à
imaginer le tag magique lu dans certaines conditions uniquement.
L'idée d'une architecture tagguée a eu une vogue, l'idée étant de gerer
un peu les types dans le hardware.
Je crois que c'était très courant dans les machines Lisp, par exemple (où
le tag indiquerait si le mot mémoire était un atome ou une cellule de
cons). Dans les années 1970, j'ai aussi entendu parler d'une architecture
avec un tag sur les indirections. Quand on lisait à une adresse mémoire,
si le tag était positionné, le processeur utilisait la valeur comme une
adresse d'indirection (avec les désavantages évidents qu'avant d'écrire,
il fallait lire, qu'il fallait une instruction spéciale pour écrire des
pointeurs -- c-à-d un store data et un store address instruction -- et
qu'il fallait une logique supplémentaire pour détecter des cycles --
sinon, tu avais une instruction machine qui n'en finissait jamais).
un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
On Mar 11, 12:25 am, Sylvain wrote:James Kanze wrote on 10/03/2008 09:47:Quand je parlais de différences en ce qui concerne la façon
qu'on accède aux valeurs, je pensais surtout aux différences
entre les accès byte et les accès mot. Sur le MCP, d'après le
peu que j'ai pû comprendre (je n'ai pas trouvé de doc
architecture ou hardware, seulement une description assez
détaillée des formats dans la doc ALGOL), l'accès char, unsigned
char et signed char doit se faire avec une instruction machine
qui ne prend pas en compte le tag (qui se trouve au niveau du
mot) ; les instructions d'accès mot, en revanche, doivent le
prendre bien en compte, mais je ne connais pas les détails.
moi non plus je ne connais pas ces détails et j'ai bcp de mal à
imaginer le tag magique lu dans certaines conditions uniquement.
L'idée d'une architecture tagguée a eu une vogue, l'idée étant de gerer
un peu les types dans le hardware.
Je crois que c'était très courant dans les machines Lisp, par exemple (où
le tag indiquerait si le mot mémoire était un atome ou une cellule de
cons). Dans les années 1970, j'ai aussi entendu parler d'une architecture
avec un tag sur les indirections. Quand on lisait à une adresse mémoire,
si le tag était positionné, le processeur utilisait la valeur comme une
adresse d'indirection (avec les désavantages évidents qu'avant d'écrire,
il fallait lire, qu'il fallait une instruction spéciale pour écrire des
pointeurs -- c-à-d un store data et un store address instruction -- et
qu'il fallait une logique supplémentaire pour détecter des cycles --
sinon, tu avais une instruction machine qui n'en finissait jamais).
un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
On Mar 11, 12:25 am, Sylvain wrote:un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
On Mar 11, 12:25 am, Sylvain <noS...@mail.net> wrote:
un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
On Mar 11, 12:25 am, Sylvain wrote:un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
James Kanze writes:
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
Il me semblait que les machines IBM (que ce soit les
descendant des 360 ou les divers POWER) permettent l'adressage
non aligne a (relativement) faible cout. La raison que
j'avais vu donnee etait que le COBOL en generait pas mal.
Mais je n'ai pas regarde precisement les manuels.
James Kanze <james.ka...@gmail.com> writes:
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
Il me semblait que les machines IBM (que ce soit les
descendant des 360 ou les divers POWER) permettent l'adressage
non aligne a (relativement) faible cout. La raison que
j'avais vu donnee etait que le COBOL en generait pas mal.
Mais je n'ai pas regarde precisement les manuels.
James Kanze writes:
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
Il me semblait que les machines IBM (que ce soit les
descendant des 360 ou les divers POWER) permettent l'adressage
non aligne a (relativement) faible cout. La raison que
j'avais vu donnee etait que le COBOL en generait pas mal.
Mais je n'ai pas regarde precisement les manuels.
un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
James Kanze wrote on 11/03/2008 10:51:un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
je pensais en effet à des procs Intel - imposant l'alignement -
comme les PXAnnn.
pardon d'avoir oublié les "0.001% of us" qui utilisent un Cray.
James Kanze wrote on 11/03/2008 10:51:
un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
je pensais en effet à des procs Intel - imposant l'alignement -
comme les PXAnnn.
pardon d'avoir oublié les "0.001% of us" qui utilisent un Cray.
James Kanze wrote on 11/03/2008 10:51:un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
je pensais en effet à des procs Intel - imposant l'alignement -
comme les PXAnnn.
pardon d'avoir oublié les "0.001% of us" qui utilisent un Cray.
James Kanze wrote on 11/03/2008 10:51:un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
je pensais en effet à des procs Intel - imposant l'alignement -
comme les PXAnnn.
pardon d'avoir oublié les "0.001% of us" qui utilisent un Cray.
James Kanze wrote on 11/03/2008 10:51:
un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
je pensais en effet à des procs Intel - imposant l'alignement -
comme les PXAnnn.
pardon d'avoir oublié les "0.001% of us" qui utilisent un Cray.
James Kanze wrote on 11/03/2008 10:51:un alignement peut être requis pour lire un mot - c'est assez
courant sur les petits procs
Des petits procs, comme les IBM système z, les anciens Crays,
tous les Sparcs... En fait, les seules architectures que moi,
j'ai vues, où on n'avait pas besoin de respecter l'alignement,
c'est l'architecture Intel (probablement parce qu'au départ, il
n'avait que 8 bits).
je pensais en effet à des procs Intel - imposant l'alignement -
comme les PXAnnn.
pardon d'avoir oublié les "0.001% of us" qui utilisent un Cray.