David ROMAN writes:Est-il possible avoir un code en C capable de detecter le type de
processeur,
Toute valeur peut etre relue comme un tableau d'unsigned char.
Donc
void hexdump(void* p, size_t n, FILE* fp) {
int i;
unsigned char* cp = p;
for (i = 0; i < n; ++i, ++cp) {
fprintf(fp, "%2x", *cp);
}
}
est valide.
David ROMAN <roman@cesr.fr> writes:
Est-il possible avoir un code en C capable de detecter le type de
processeur,
Toute valeur peut etre relue comme un tableau d'unsigned char.
Donc
void hexdump(void* p, size_t n, FILE* fp) {
int i;
unsigned char* cp = p;
for (i = 0; i < n; ++i, ++cp) {
fprintf(fp, "%2x", *cp);
}
}
est valide.
David ROMAN writes:Est-il possible avoir un code en C capable de detecter le type de
processeur,
Toute valeur peut etre relue comme un tableau d'unsigned char.
Donc
void hexdump(void* p, size_t n, FILE* fp) {
int i;
unsigned char* cp = p;
for (i = 0; i < n; ++i, ++cp) {
fprintf(fp, "%2x", *cp);
}
}
est valide.
Bonjour,
Jean-Marc Bourguet wrote:David ROMAN writes:Est-il possible avoir un code en C capable de detecter le type de
processeur,
Toute valeur peut etre relue comme un tableau d'unsigned char.
Donc
void hexdump(void* p, size_t n, FILE* fp) {
int i;
unsigned char* cp = p;
for (i = 0; i < n; ++i, ++cp) {
fprintf(fp, "%2x", *cp);
}
}
est valide.
Une petite question qui va sembler sûrement idiote, que devient ce
type de code pour des architectures ayant des byte de plus de 8
bits? est-ce la bonne manière de faire dans tous les cas ?
En fait je dois avouer que ce type d'architecture «défie» un peu mon
imagination, pour la simple et bonne raison que je n'ai jamais
travaillé dessus, je devrais peut être me remettre à l'architecture
et me documenter un peu :-)
Bonjour,
Jean-Marc Bourguet wrote:
David ROMAN <roman@cesr.fr> writes:
Est-il possible avoir un code en C capable de detecter le type de
processeur,
Toute valeur peut etre relue comme un tableau d'unsigned char.
Donc
void hexdump(void* p, size_t n, FILE* fp) {
int i;
unsigned char* cp = p;
for (i = 0; i < n; ++i, ++cp) {
fprintf(fp, "%2x", *cp);
}
}
est valide.
Une petite question qui va sembler sûrement idiote, que devient ce
type de code pour des architectures ayant des byte de plus de 8
bits? est-ce la bonne manière de faire dans tous les cas ?
En fait je dois avouer que ce type d'architecture «défie» un peu mon
imagination, pour la simple et bonne raison que je n'ai jamais
travaillé dessus, je devrais peut être me remettre à l'architecture
et me documenter un peu :-)
Bonjour,
Jean-Marc Bourguet wrote:David ROMAN writes:Est-il possible avoir un code en C capable de detecter le type de
processeur,
Toute valeur peut etre relue comme un tableau d'unsigned char.
Donc
void hexdump(void* p, size_t n, FILE* fp) {
int i;
unsigned char* cp = p;
for (i = 0; i < n; ++i, ++cp) {
fprintf(fp, "%2x", *cp);
}
}
est valide.
Une petite question qui va sembler sûrement idiote, que devient ce
type de code pour des architectures ayant des byte de plus de 8
bits? est-ce la bonne manière de faire dans tous les cas ?
En fait je dois avouer que ce type d'architecture «défie» un peu mon
imagination, pour la simple et bonne raison que je n'ai jamais
travaillé dessus, je devrais peut être me remettre à l'architecture
et me documenter un peu :-)
Emmanuel Delahaye a écrit:Yves ROMAN wrote on 22/10/04 :Désolé, mais je n'arrive jamais à me souvenir du sens de big/little endian.
Alors je parle en opposition Intel/Motorola...
Bienvenu au club! Si quelqu'un a un moyen mnémotechnique, qu'il le
dise!
Intel / Little, il me semble que les lettres en commun sont
suffisantes.
Ensuite, ce n'est pas un "truc", mais on peut soit mémoriser "little
end first, c.à.d. que les poids faibles sont écrits en premier. Mais
bien sûr, pourquoi first et pas last? En fait, j'ai lu que le
mnémonitechnique US est "Little[Big] End In", mais la subtilité de ce
"In" m'échappe.
Si la donnée à ranger en mémoire est comme une carte perforée a mettre dans la
fente, tu mets le bon coté dedans, et tu pousses !
C'est tiré par les cheveux (et un peu osé !) mais pourquoi pas...
Hum hum. Je vais en rester à mes "repères". Ces histoires de bits que
Emmanuel Delahaye <emdel@YOURBRAnoos.fr> a écrit:
Yves ROMAN wrote on 22/10/04 :
Désolé, mais je n'arrive jamais à me souvenir du sens de big/little endian.
Alors je parle en opposition Intel/Motorola...
Bienvenu au club! Si quelqu'un a un moyen mnémotechnique, qu'il le
dise!
Intel / Little, il me semble que les lettres en commun sont
suffisantes.
Ensuite, ce n'est pas un "truc", mais on peut soit mémoriser "little
end first, c.à.d. que les poids faibles sont écrits en premier. Mais
bien sûr, pourquoi first et pas last? En fait, j'ai lu que le
mnémonitechnique US est "Little[Big] End In", mais la subtilité de ce
"In" m'échappe.
Si la donnée à ranger en mémoire est comme une carte perforée a mettre dans la
fente, tu mets le bon coté dedans, et tu pousses !
C'est tiré par les cheveux (et un peu osé !) mais pourquoi pas...
Hum hum. Je vais en rester à mes "repères". Ces histoires de bits que
Emmanuel Delahaye a écrit:Yves ROMAN wrote on 22/10/04 :Désolé, mais je n'arrive jamais à me souvenir du sens de big/little endian.
Alors je parle en opposition Intel/Motorola...
Bienvenu au club! Si quelqu'un a un moyen mnémotechnique, qu'il le
dise!
Intel / Little, il me semble que les lettres en commun sont
suffisantes.
Ensuite, ce n'est pas un "truc", mais on peut soit mémoriser "little
end first, c.à.d. que les poids faibles sont écrits en premier. Mais
bien sûr, pourquoi first et pas last? En fait, j'ai lu que le
mnémonitechnique US est "Little[Big] End In", mais la subtilité de ce
"In" m'échappe.
Si la donnée à ranger en mémoire est comme une carte perforée a mettre dans la
fente, tu mets le bon coté dedans, et tu pousses !
C'est tiré par les cheveux (et un peu osé !) mais pourquoi pas...
Hum hum. Je vais en rester à mes "repères". Ces histoires de bits que
Une petite question qui va sembler sûrement idiote, que devient ce type de
code pour des architectures ayant des byte de plus de 8 bits ? est-ce la
bonne manière de faire dans tous les cas ?
En fait je dois avouer que ce type d'architecture «défie» un peu mon
imagination, pour la simple et bonne raison que je n'ai jamais travaillé
dessus, je devrais peut être me remettre à l'architecture et me documenter
un peu :-)
Une petite question qui va sembler sûrement idiote, que devient ce type de
code pour des architectures ayant des byte de plus de 8 bits ? est-ce la
bonne manière de faire dans tous les cas ?
En fait je dois avouer que ce type d'architecture «défie» un peu mon
imagination, pour la simple et bonne raison que je n'ai jamais travaillé
dessus, je devrais peut être me remettre à l'architecture et me documenter
un peu :-)
Une petite question qui va sembler sûrement idiote, que devient ce type de
code pour des architectures ayant des byte de plus de 8 bits ? est-ce la
bonne manière de faire dans tous les cas ?
En fait je dois avouer que ce type d'architecture «défie» un peu mon
imagination, pour la simple et bonne raison que je n'ai jamais travaillé
dessus, je devrais peut être me remettre à l'architecture et me documenter
un peu :-)
Une petite question qui va sembler sûrement idiote, que devient ce
type de code pour des architectures ayant des byte de plus de 8
bits? est-ce la bonne manière de faire dans tous les cas ?
Les architectures de ce type recentes ont tendance (en fait je ne
connais pas d'exception mais mon savoir n'est pas universel) a
utiliser en C un char qui a la taille de l'unite d'addressage.
Les architectures de ce type plus anciennes ont generalement un char
plus petit que l'unite d'adressage.
Et dans celles que je connais on
aurait plutot tendance a utiliser un char de 7 ou 6 bits qu'un de 8
bits ou plus quoi qu'en dise la norme. (C'est bien beau de demander
des char de 8 bits ou plus, si tout le reste utilise de char de 7 bits
l'interroperabilite n'est pas a son mieux).
Une petite question qui va sembler sûrement idiote, que devient ce
type de code pour des architectures ayant des byte de plus de 8
bits? est-ce la bonne manière de faire dans tous les cas ?
Les architectures de ce type recentes ont tendance (en fait je ne
connais pas d'exception mais mon savoir n'est pas universel) a
utiliser en C un char qui a la taille de l'unite d'addressage.
Les architectures de ce type plus anciennes ont generalement un char
plus petit que l'unite d'adressage.
Et dans celles que je connais on
aurait plutot tendance a utiliser un char de 7 ou 6 bits qu'un de 8
bits ou plus quoi qu'en dise la norme. (C'est bien beau de demander
des char de 8 bits ou plus, si tout le reste utilise de char de 7 bits
l'interroperabilite n'est pas a son mieux).
Une petite question qui va sembler sûrement idiote, que devient ce
type de code pour des architectures ayant des byte de plus de 8
bits? est-ce la bonne manière de faire dans tous les cas ?
Les architectures de ce type recentes ont tendance (en fait je ne
connais pas d'exception mais mon savoir n'est pas universel) a
utiliser en C un char qui a la taille de l'unite d'addressage.
Les architectures de ce type plus anciennes ont generalement un char
plus petit que l'unite d'adressage.
Et dans celles que je connais on
aurait plutot tendance a utiliser un char de 7 ou 6 bits qu'un de 8
bits ou plus quoi qu'en dise la norme. (C'est bien beau de demander
des char de 8 bits ou plus, si tout le reste utilise de char de 7 bits
l'interroperabilite n'est pas a son mieux).
Jean-Marc Bourguet wrote on 22/10/04 :Une petite question qui va sembler sûrement idiote, que devient ce
type de code pour des architectures ayant des byte de plus de 8
bits? est-ce la bonne manière de faire dans tous les cas ?
Les architectures de ce type recentes ont tendance (en fait je ne
connais pas d'exception mais mon savoir n'est pas universel) a
utiliser en C un char qui a la taille de l'unite d'addressage.
C'est la norme.
Les architectures de ce type plus anciennes ont generalement un
char plus petit que l'unite d'adressage.
Alors on ne parle pas de C standard. En C, un char et un byte ont la
même taille, et valent 1 (byte). Toujours. Leur taille en bit est au
minimum de 8 bits.
Et dans celles que je connais on aurait plutot tendance a utiliser
un char de 7 ou 6 bits qu'un de 8 bits ou plus quoi qu'en dise la
norme. (C'est bien beau de demander des char de 8 bits ou plus,
si tout le reste utilise de char de 7 bits l'interroperabilite
n'est pas a son mieux).
Pas de char de 7 bits en C standard.
Jean-Marc Bourguet wrote on 22/10/04 :
Une petite question qui va sembler sûrement idiote, que devient ce
type de code pour des architectures ayant des byte de plus de 8
bits? est-ce la bonne manière de faire dans tous les cas ?
Les architectures de ce type recentes ont tendance (en fait je ne
connais pas d'exception mais mon savoir n'est pas universel) a
utiliser en C un char qui a la taille de l'unite d'addressage.
C'est la norme.
Les architectures de ce type plus anciennes ont generalement un
char plus petit que l'unite d'adressage.
Alors on ne parle pas de C standard. En C, un char et un byte ont la
même taille, et valent 1 (byte). Toujours. Leur taille en bit est au
minimum de 8 bits.
Et dans celles que je connais on aurait plutot tendance a utiliser
un char de 7 ou 6 bits qu'un de 8 bits ou plus quoi qu'en dise la
norme. (C'est bien beau de demander des char de 8 bits ou plus,
si tout le reste utilise de char de 7 bits l'interroperabilite
n'est pas a son mieux).
Pas de char de 7 bits en C standard.
Jean-Marc Bourguet wrote on 22/10/04 :Une petite question qui va sembler sûrement idiote, que devient ce
type de code pour des architectures ayant des byte de plus de 8
bits? est-ce la bonne manière de faire dans tous les cas ?
Les architectures de ce type recentes ont tendance (en fait je ne
connais pas d'exception mais mon savoir n'est pas universel) a
utiliser en C un char qui a la taille de l'unite d'addressage.
C'est la norme.
Les architectures de ce type plus anciennes ont generalement un
char plus petit que l'unite d'adressage.
Alors on ne parle pas de C standard. En C, un char et un byte ont la
même taille, et valent 1 (byte). Toujours. Leur taille en bit est au
minimum de 8 bits.
Et dans celles que je connais on aurait plutot tendance a utiliser
un char de 7 ou 6 bits qu'un de 8 bits ou plus quoi qu'en dise la
norme. (C'est bien beau de demander des char de 8 bits ou plus,
si tout le reste utilise de char de 7 bits l'interroperabilite
n'est pas a son mieux).
Pas de char de 7 bits en C standard.
Pour ce qui concerne les architectures anciennes, il y a pas mal de
documentation disponible sur le PDP-10 (commence par 36bit.org et suis
le lien pour DEC). Pour les architectures recentes, regarde les DSP de
chez TI. Il doit y avoir de la doc.
Merci pour la réponse et pour les liens. Moi qui ne savait pas comment
Pour ce qui concerne les architectures anciennes, il y a pas mal de
documentation disponible sur le PDP-10 (commence par 36bit.org et suis
le lien pour DEC). Pour les architectures recentes, regarde les DSP de
chez TI. Il doit y avoir de la doc.
Merci pour la réponse et pour les liens. Moi qui ne savait pas comment
Pour ce qui concerne les architectures anciennes, il y a pas mal de
documentation disponible sur le PDP-10 (commence par 36bit.org et suis
le lien pour DEC). Pour les architectures recentes, regarde les DSP de
chez TI. Il doit y avoir de la doc.
Merci pour la réponse et pour les liens. Moi qui ne savait pas comment