Que j'y pense, le VAX avait (et je suppose, a toujours)
des instructions pour lire n bits à partir d'une adresse
et un offset de bits. Dans la première version de compress
que j'ai vu, on s'en servait, moyennant un petit coup de
asm, pour insérer et extraire les bits dans le flux --
c'était nettement plus rapide que tout ce qu'on aurait pu
écrire en C.
Que j'y pense, le VAX avait (et je suppose, a toujours)
des instructions pour lire n bits à partir d'une adresse
et un offset de bits. Dans la première version de compress
que j'ai vu, on s'en servait, moyennant un petit coup de
asm, pour insérer et extraire les bits dans le flux --
c'était nettement plus rapide que tout ce qu'on aurait pu
écrire en C.
Que j'y pense, le VAX avait (et je suppose, a toujours)
des instructions pour lire n bits à partir d'une adresse
et un offset de bits. Dans la première version de compress
que j'ai vu, on s'en servait, moyennant un petit coup de
asm, pour insérer et extraire les bits dans le flux --
c'était nettement plus rapide que tout ce qu'on aurait pu
écrire en C.
Jean-Marc Bourguet writes:
|> Il y a quelques processeurs (en fait seul le 8051 me vient a
|> l'esprit pour le moment) qui permette d'acceder aux bits
|> individuellement. Dans ces cas l'ordre peut avoir de l'importance.
Et le PDP-10 ?
Jean-Marc Bourguet <jm@bourguet.org> writes:
|> Il y a quelques processeurs (en fait seul le 8051 me vient a
|> l'esprit pour le moment) qui permette d'acceder aux bits
|> individuellement. Dans ces cas l'ordre peut avoir de l'importance.
Et le PDP-10 ?
Jean-Marc Bourguet writes:
|> Il y a quelques processeurs (en fait seul le 8051 me vient a
|> l'esprit pour le moment) qui permette d'acceder aux bits
|> individuellement. Dans ces cas l'ordre peut avoir de l'importance.
Et le PDP-10 ?
(En passant, j'espère que tu ne prends pas mal mes critiques.
Que nenni. Pas vu de critique.
(En passant, j'espère que tu ne prends pas mal mes critiques.
Que nenni. Pas vu de critique.
(En passant, j'espère que tu ne prends pas mal mes critiques.
Que nenni. Pas vu de critique.
Jean-Marc Bourguet writes:
|> Pierre Maurette writes:
|> > Question aux spécialistes du C: est-il possible de
|> > concevoir une machine dont l'atome mémoire (donc la
|> > base de l'endianité) serait de 16 bits et la taille
|> > du char de 8 bits ?
|> Oui. On utilise alors des pointeurs vers char qui
|> contiennent plus d'info. C'est a cause de ce genre de
|> machines qu'on peut avoir sizeof (int*) <
|> sizeof(char*). Les C pour PDP-10 que j'ai vu (j'ai pas
|> utilise le C sur ces machines mais des compilateurs C
|> pour elles existent) ont CHAR_BIT==9 et
|> sizeof(int)==4; mais ces machines etaient utilise avec
|> de l'ASCII, 7 bits, 5 char par mot + 1 bit de padding
|> ou du 6 bits , 6 char par mots et il me semble me
|> souvenir qu'il etait possible de mettre les compilo C
|> dans un mode plus compatible avec le systeme meme si
|> moins conforme a l'ISO.
Sur le C pour le PDP-10 que j'ai vu, la taille des
pointeurs était toujours 24 bits. En revanche, il n'y
avait que les bits de poids faibles (j'en oublies combien)
qui servait pour l'adressage des mots ; certains bits de
poids fort servaient à selectionner les bytes dans le mot,
le cas échéant (les char*). Ce qui donnait la situation
que si p était un char*, "(int)p > (int)( p+1 )" pour
certains valeurs de p.
(Sur le PDP-10, grosso modo, le poids fort d'un mot était
ignoré dans la plupart des adressages. Dans le cas des
instructions load byte et store byte, en revanche, une
partie du poid fort spécifier l'offset du premier bit, et
une autre partie le nombre de bits concerné. En C,
évidemment, le nombre de bits concerné était toujours 9,
mais dans la plupart des autres langages, on utilisait 6.)
|> Alternativement on peut naturellement les faire
|> fonctionner avec des chars equivalent au mot.
C'était quand même assez rare sur les machines à vocation générale.
Jean-Marc Bourguet <jm@bourguet.org> writes:
|> Pierre Maurette <maurettepierre@wanadoo.fr> writes:
|> > Question aux spécialistes du C: est-il possible de
|> > concevoir une machine dont l'atome mémoire (donc la
|> > base de l'endianité) serait de 16 bits et la taille
|> > du char de 8 bits ?
|> Oui. On utilise alors des pointeurs vers char qui
|> contiennent plus d'info. C'est a cause de ce genre de
|> machines qu'on peut avoir sizeof (int*) <
|> sizeof(char*). Les C pour PDP-10 que j'ai vu (j'ai pas
|> utilise le C sur ces machines mais des compilateurs C
|> pour elles existent) ont CHAR_BIT==9 et
|> sizeof(int)==4; mais ces machines etaient utilise avec
|> de l'ASCII, 7 bits, 5 char par mot + 1 bit de padding
|> ou du 6 bits , 6 char par mots et il me semble me
|> souvenir qu'il etait possible de mettre les compilo C
|> dans un mode plus compatible avec le systeme meme si
|> moins conforme a l'ISO.
Sur le C pour le PDP-10 que j'ai vu, la taille des
pointeurs était toujours 24 bits. En revanche, il n'y
avait que les bits de poids faibles (j'en oublies combien)
qui servait pour l'adressage des mots ; certains bits de
poids fort servaient à selectionner les bytes dans le mot,
le cas échéant (les char*). Ce qui donnait la situation
que si p était un char*, "(int)p > (int)( p+1 )" pour
certains valeurs de p.
(Sur le PDP-10, grosso modo, le poids fort d'un mot était
ignoré dans la plupart des adressages. Dans le cas des
instructions load byte et store byte, en revanche, une
partie du poid fort spécifier l'offset du premier bit, et
une autre partie le nombre de bits concerné. En C,
évidemment, le nombre de bits concerné était toujours 9,
mais dans la plupart des autres langages, on utilisait 6.)
|> Alternativement on peut naturellement les faire
|> fonctionner avec des chars equivalent au mot.
C'était quand même assez rare sur les machines à vocation générale.
Jean-Marc Bourguet writes:
|> Pierre Maurette writes:
|> > Question aux spécialistes du C: est-il possible de
|> > concevoir une machine dont l'atome mémoire (donc la
|> > base de l'endianité) serait de 16 bits et la taille
|> > du char de 8 bits ?
|> Oui. On utilise alors des pointeurs vers char qui
|> contiennent plus d'info. C'est a cause de ce genre de
|> machines qu'on peut avoir sizeof (int*) <
|> sizeof(char*). Les C pour PDP-10 que j'ai vu (j'ai pas
|> utilise le C sur ces machines mais des compilateurs C
|> pour elles existent) ont CHAR_BIT==9 et
|> sizeof(int)==4; mais ces machines etaient utilise avec
|> de l'ASCII, 7 bits, 5 char par mot + 1 bit de padding
|> ou du 6 bits , 6 char par mots et il me semble me
|> souvenir qu'il etait possible de mettre les compilo C
|> dans un mode plus compatible avec le systeme meme si
|> moins conforme a l'ISO.
Sur le C pour le PDP-10 que j'ai vu, la taille des
pointeurs était toujours 24 bits. En revanche, il n'y
avait que les bits de poids faibles (j'en oublies combien)
qui servait pour l'adressage des mots ; certains bits de
poids fort servaient à selectionner les bytes dans le mot,
le cas échéant (les char*). Ce qui donnait la situation
que si p était un char*, "(int)p > (int)( p+1 )" pour
certains valeurs de p.
(Sur le PDP-10, grosso modo, le poids fort d'un mot était
ignoré dans la plupart des adressages. Dans le cas des
instructions load byte et store byte, en revanche, une
partie du poid fort spécifier l'offset du premier bit, et
une autre partie le nombre de bits concerné. En C,
évidemment, le nombre de bits concerné était toujours 9,
mais dans la plupart des autres langages, on utilisait 6.)
|> Alternativement on peut naturellement les faire
|> fonctionner avec des chars equivalent au mot.
C'était quand même assez rare sur les machines à vocation générale.
"Jean-Marc" writes:"Richard Delorme" a écrit dans le message de
news:4179589d$0$15756$Anthony Fleury wrote on 22/10/04 :
Personnellement je choisis la seconde option, car je préfère un
programme non portable qui marche sur ma machine qu'un programme
portable qui ne marche que sur des machines dont je ne dispose pas.
C'est une opinion défendable, tant que tu ne programmes
que pour toi. Evidemment, c'est inacceptable si ton
programme a ne serait ce qu'une chance sur un million de
sortir de ta machine.
Mais non. C'est une opinion défendable dans beaucoup de
contextes.
"Jean-Marc" <nospamjean_marc_n2@yahoo.fr> writes:
"Richard Delorme" <abulmo@nospam.fr> a écrit dans le message de
news:4179589d$0$15756$7a628cd7@news.club-internet.fr...
Anthony Fleury wrote on 22/10/04 :
Personnellement je choisis la seconde option, car je préfère un
programme non portable qui marche sur ma machine qu'un programme
portable qui ne marche que sur des machines dont je ne dispose pas.
C'est une opinion défendable, tant que tu ne programmes
que pour toi. Evidemment, c'est inacceptable si ton
programme a ne serait ce qu'une chance sur un million de
sortir de ta machine.
Mais non. C'est une opinion défendable dans beaucoup de
contextes.
"Jean-Marc" writes:"Richard Delorme" a écrit dans le message de
news:4179589d$0$15756$Anthony Fleury wrote on 22/10/04 :
Personnellement je choisis la seconde option, car je préfère un
programme non portable qui marche sur ma machine qu'un programme
portable qui ne marche que sur des machines dont je ne dispose pas.
C'est une opinion défendable, tant que tu ne programmes
que pour toi. Evidemment, c'est inacceptable si ton
programme a ne serait ce qu'une chance sur un million de
sortir de ta machine.
Mais non. C'est une opinion défendable dans beaucoup de
contextes.
Personnellement je choisis la seconde option, car je préfère un
programme non portable qui marche sur ma machine qu'un programme
portable qui ne marche que sur des machines dont je ne dispose pas.
C'est une opinion défendable, tant que tu ne programmes que pour toi.
Evidemment, c'est inacceptable si ton programme a ne serait ce qu'une
chance sur un million de sortir de ta machine.
Personnellement je choisis la seconde option, car je préfère un
programme non portable qui marche sur ma machine qu'un programme
portable qui ne marche que sur des machines dont je ne dispose pas.
C'est une opinion défendable, tant que tu ne programmes que pour toi.
Evidemment, c'est inacceptable si ton programme a ne serait ce qu'une
chance sur un million de sortir de ta machine.
Personnellement je choisis la seconde option, car je préfère un
programme non portable qui marche sur ma machine qu'un programme
portable qui ne marche que sur des machines dont je ne dispose pas.
C'est une opinion défendable, tant que tu ne programmes que pour toi.
Evidemment, c'est inacceptable si ton programme a ne serait ce qu'une
chance sur un million de sortir de ta machine.
Tu n'as pas compris le sens de mon exemple. En pratique, sur l'exemple que
j'avais pris, mon code "non portable" marchera sur les machines capables de
faire fonctionner le code portable, tandis que le code portable ne
fonctionnera pas, par manque de ressources, sur les machines 16 bits pour
lesquels il a été rendu portable. Il est donc vain de vouloir rendre un code
portable à tout prix, car, en pratique, on réduit certainement le nombre de
machine où le programme peut réellement fonctionner.
Tu n'as pas compris le sens de mon exemple. En pratique, sur l'exemple que
j'avais pris, mon code "non portable" marchera sur les machines capables de
faire fonctionner le code portable, tandis que le code portable ne
fonctionnera pas, par manque de ressources, sur les machines 16 bits pour
lesquels il a été rendu portable. Il est donc vain de vouloir rendre un code
portable à tout prix, car, en pratique, on réduit certainement le nombre de
machine où le programme peut réellement fonctionner.
Tu n'as pas compris le sens de mon exemple. En pratique, sur l'exemple que
j'avais pris, mon code "non portable" marchera sur les machines capables de
faire fonctionner le code portable, tandis que le code portable ne
fonctionnera pas, par manque de ressources, sur les machines 16 bits pour
lesquels il a été rendu portable. Il est donc vain de vouloir rendre un code
portable à tout prix, car, en pratique, on réduit certainement le nombre de
machine où le programme peut réellement fonctionner.
Richard Delorme wrote on 22/10/04 :Tu n'as pas compris le sens de mon exemple. En pratique, sur l'exemple
que j'avais pris, mon code "non portable" marchera sur les machines
capables de faire fonctionner le code portable, tandis que le code
portable ne fonctionnera pas, par manque de ressources, sur les
machines 16 bits pour lesquels il a été rendu portable. Il est donc
vain de vouloir rendre un code portable à tout prix, car, en pratique,
on réduit certainement le nombre de machine où le programme peut
réellement fonctionner.
C'est la conséquence évidente de la portabilité. On réduit les
performances à plus petit dénominateur commun. Il y a des cas où ce
n'est pas une option.
Richard Delorme wrote on 22/10/04 :
Tu n'as pas compris le sens de mon exemple. En pratique, sur l'exemple
que j'avais pris, mon code "non portable" marchera sur les machines
capables de faire fonctionner le code portable, tandis que le code
portable ne fonctionnera pas, par manque de ressources, sur les
machines 16 bits pour lesquels il a été rendu portable. Il est donc
vain de vouloir rendre un code portable à tout prix, car, en pratique,
on réduit certainement le nombre de machine où le programme peut
réellement fonctionner.
C'est la conséquence évidente de la portabilité. On réduit les
performances à plus petit dénominateur commun. Il y a des cas où ce
n'est pas une option.
Richard Delorme wrote on 22/10/04 :Tu n'as pas compris le sens de mon exemple. En pratique, sur l'exemple
que j'avais pris, mon code "non portable" marchera sur les machines
capables de faire fonctionner le code portable, tandis que le code
portable ne fonctionnera pas, par manque de ressources, sur les
machines 16 bits pour lesquels il a été rendu portable. Il est donc
vain de vouloir rendre un code portable à tout prix, car, en pratique,
on réduit certainement le nombre de machine où le programme peut
réellement fonctionner.
C'est la conséquence évidente de la portabilité. On réduit les
performances à plus petit dénominateur commun. Il y a des cas où ce
n'est pas une option.
Personnellement je choisis la seconde option, car je préfère un
programme non portable qui marche sur ma machine qu'un programme
portable qui ne marche que sur des machines dont je ne dispose pas.
Personnellement je choisis la seconde option, car je préfère un
programme non portable qui marche sur ma machine qu'un programme
portable qui ne marche que sur des machines dont je ne dispose pas.
Personnellement je choisis la seconde option, car je préfère un
programme non portable qui marche sur ma machine qu'un programme
portable qui ne marche que sur des machines dont je ne dispose pas.