On Fri, 29 Feb 2008 09:20:19 +0000 (UTC), Marc Boyer :

> Ca me rappelle les discutions sur
>int i= 2;
>int j = ++i * i++;
> Les valeurs de i et j sont formellement indéfinies. Dans la
>pratique, on imagine bien que i va avoir une valeur entre 3 et 4,
>et j entre 4, 6, 9 et 16.

Quid du code ci-dessous ?

int Pre (int& n)
{
++n;
return n;
}

int Post (int& n)
{
++n;
return n-1;
}

int Mult (int a, int b)
{
return a*b;
}

int i= 2;
int j= Mult (Pre(i), Post(i));


Il me semble que dans ce cas, il n'y a que deux possibilités :

1ère possibilité :
1. Pre() est exécutée en entier -> i vaut 3 ; le premier temporaire
vaut 3
2. Post() est exécutée en entier -> i vaut 4 ; le deuxième temporaire
vaut 3
3. Mult() est exécutée en entier -> les deux paramètres sont les deux
temporaires ci-dessus ; résultat : 9

j == 9 ; i == 4

2e possibilité :
Post() est exécutée en entier -> i vaut 3 ; le deuxième temporaire
vaut 2
Pre() est exécutée en entier -> i vaut 4 ; le premier temporaire vaut
4
Mult() est exécutée en entier -> les deux paramètres sont les deux
temporaires ci-dessus ; résultat : 8

j == 8 ; i == 4


La norme assure-t-elle qu'on obtient un de ces deux résultats (sans
préciser lequel), ou bien est-ce un "comportement indéfini" dans toute
sa splendeur, i.e. un crash est-il théoriquement possible ?

Fabien LE LEZ <gramster@gramster.com> writes:

> On Fri, 29 Feb 2008 09:20:19 +0000 (UTC), Marc Boyer :
>
> > Ca me rappelle les discutions sur
> >int i= 2;
> >int j = ++i * i++;
> > Les valeurs de i et j sont formellement indéfinies. Dans la
> >pratique, on imagine bien que i va avoir une valeur entre 3 et 4,
> >et j entre 4, 6, 9 et 16.
>
> Quid du code ci-dessous ?

Comportement non specifie (et pas indefini). J'ai pas verifie les details
de ton analyse, mais le principe est bon.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/...ite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

On 2008-02-29, Fabien LE LEZ <gramster@gramster.com> wrote:
> On Fri, 29 Feb 2008 09:20:19 +0000 (UTC), Marc Boyer :
> 1ère possibilité :
> 1. Pre() est exécutée en entier -> i vaut 3 ; le premier temporaire
> vaut 3
> 2. Post() est exécutée en entier -> i vaut 4 ; le deuxième temporaire
> vaut 3

Tu fais l'hypothèse que l'appel à la fonction est fait "en entier".
On sens bien que ce doit être vrai, mais difficile à trouver
explicitement. Le mieux que je trouve est 6.5.2.2/10 de la norme C
qui dit
"The order of evaluation of the function designator, the actual
arguments and subexpressions within the actual arguments is
unspecified", ce qui milite pour le fait qu'il y ait un ordre
et pas du parallélisme... Et comme l'appel de la fonction
et les ; qui sont dedans sont des points de séquence, en effet,
ton raisonnement doit être le bon.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

Le 28/02/2008 12:07, Sylvain a écrit :
>
> même dans ce cas je n'arrive pas à imaginer une valeur spéciale faisant
> traper l'injecteur.

As-tu lu le premier article de Jean-Marc Bourguet dans ce fil ?

<cit.>
il y a eu une machine n'ayant que des nombres en virgule flottante, mais
où certaines opérations trappaient si une donnée n'était pas entière
</cit.>

On Feb 29, 10:20 am, Marc Boyer <Marc.Bo...@enseeiht.yahoo.fr.invalid>
wrote:
> On 2008-02-27, Sylvain <noS...@mail.net> wrote:

> > Anthony Fleury wrote on 27/02/2008 19:29:

> >>> Est ce que ce code à un comportement indéfini ?

> >>> //iostream est inclue , ...
> >>> int a; //(1)
> >>> cout<< a; // (2)

> >> Entre autre, a peut très bien contenir une valeur "invalide" pour le
> >> système ("trap value") qui ferait remarquer au-dit système que la
> >> variable utilisée ne l'est pas d'une manière conforme.

> > j'ai du mal à saisir la finesse de l'indéfinition. je ne
> > vois ici qu'une imprévision (non connaissance d'une valeur
> > aléatoire, ou comment se paraphraser).

> > surtout je ne vois pas ce que serait un *int* "invalide" !!
> > vous avez des machines sur lesquelles un int, disons 32
> > bits, peut contenir toutes les valuers entières entre
> > 0x00000000 et 0xFFFFFFFF *plus* d'autres valeurs invalides
> > ???

> Il y a là un problème de vocabulaire qui peut durer longtemps...
> La norme parle de "comportement indéfini" pour tout ce à quoi
> elle ne veut pas associer de sémantique.
> Après, sur l'ensemble des compilateurs existants à ce jour et
> l'ensemble de OS et l'ensemble des processeurs et des mémoires,
> ce sera surement un comportement "défini", avec une définition
> plus ou moins précise quand même...

Oui et non. Lorsqu'il y a des comportements inféfinis, il peut
bien y avoir des aléas dans la pratique. Prenons un cas
concret : CP/M ou MS-DOS (quand tu compiles en modèle large).
Écrire à travers un pointeur non initialisé peut bien écrire
n'importe où, de façon plus ou moins aléatoire. (En fait, il
dépend de ce que tu as fait avant -- ce que la commande
précédante a laissé à l'adresse du pointeur. Mais de point de
vue pratique, je crois qu'on peut dire aléatoire.) C-à-d que si
tu n'as vraiment pas de chance, tu modifies le système---la
prochaine lecture disque devient une écriture, par exemple, ou
prèsque n'importe quoi d'autre. C'est vraiment un comportement
indéfini. (Si tu n'as vraiment pas de bol, il va falloir
réformatter la disquette.)

> Après, l'exemple d'une exécution sous purify est intéressante.
> En quoi le triplet gcc/linux/purify ne serait pas une "plateforme
> d'exécution" et VC++/Vista le serait il ? Parce qu'aucun code
> en production ne l'utilise ? En est-on sûr ?

> Ca me rappelle les discutions sur
> int i= 2;
> int j = ++i * i++;
> Les valeurs de i et j sont formellement indéfinies. Dans la
> pratique, on imagine bien que i va avoir une valeur entre 3 et 4,
> et j entre 4, 6, 9 et 16.

À l'époque, il a bien été expliqué qu'il existait des machines
où ce code pourrait provoquer un plantage. Je ne me rappelle
plus les détails, et j'avoue ne jamais avoir vu une telle
machine, mais l'explication tournait sur le fait que le
compilateur, sachant que les deux écritures ne pouvaient pas
référencier le même mot, pouvait générer des écritures en
parallel, et que selon ce qu'on disait, ça pourrait provoquer un
plantage sur certains systèmes. (J'ai bien travaillé dans des
contextes où il fallait tenir compte des temps d'accès dans les
instructions, sinon, plantage, mais d'une part, il s'agissait du
microcode -- il y aurait jamais du C++ là -- et de l'autre,
entre le lancement d'une lecture et la récupération de sa
valeur, on n'avait pas de droit de faire quoique ce soit avec la
mémoire. Même adresse ou pas.)

> Sauf qu'en plus, la norme C (et donc par extension celle de C++)
> évoque bien la notion de "trap representation", qu'on peut évoquer
> là à cause de la non-initialisation.

Comme j'ai déjà dit ailleurs, j'ai réelement vu le cas où lire
de la mémoire qu'on n'avait jamais écrite pourrait provoquer un
plantage. Mais dans ce cas-là, il suffisait d'y avoir écrit une
fois, depuis la mise sous tension du système. En revanche, il y
avait bien les anciens processeurs de Burroughs/Unisys, qui
avait une architecture tagguée. En particulier, un entier
n'était qu'un virgule flottant avec le champs exposant à 0
(c-à-d 48 bits, avec 8 bits obligatoirement à 0, et magnitude
signée, en plus). Il n'y avait qu'une seule instruction add, par
exemple, qui fonctionnait à la fois pour les flottants et les
entiers, selon les valeurs qu'on lui donnait. Je ne sais pas ce
qui passait si tu mettais des bits d'un flottant dans une
variable de type entier en C, mais ça m'étonnerait que ce soit
quelque chose de bien prévisible.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Feb 29, 12:08 pm, Marc Boyer <Marc.Bo...@enseeiht.yahoo.fr.invalid>
wrote:
> On 2008-02-29, Fabien LE LEZ <grams...@gramster.com> wrote:

> > On Fri, 29 Feb 2008 09:20:19 +0000 (UTC), Marc Boyer :
> > 1ère possibilité :
> > 1. Pre() est exécutée en entier -> i vaut 3 ; le premier temporaire
> > vaut 3
> > 2. Post() est exécutée en entier -> i vaut 4 ; le deuxième temporaire
> > vaut 3

> Tu fais l'hypothèse que l'appel à la fonction est fait "en entier".
> On sens bien que ce doit être vrai, mais difficile à trouver
> explicitement. Le mieux que je trouve est 6.5.2.2/10 de la norme C
> qui dit
> "The order of evaluation of the function designator, the actual
> arguments and subexpressions within the actual arguments is
> unspecified", ce qui milite pour le fait qu'il y ait un ordre
> et pas du parallélisme... Et comme l'appel de la fonction
> et les ; qui sont dedans sont des points de séquence, en effet,
> ton raisonnement doit être le bon.

Il me semble qu'il y a eu un DR ou une démande de clarification
à cet égard adressé au comité C, et qu'ils ont bien dit que oui,
une fois qu'on est entré dans une fonction, on ne peut rien
faire d'autre avant d'avoir fini la fonction. C'est difficile à
comprendre ce que pourrait signifier le fait que l'appel et le
rétour d'une fonction soit des points de séquencement autrement.

En fait, la norme C (comme la norme C++ jusqu'aujourd'hui)
suppose un modèle séquentiel. Je dirais que ce n'est pas
tellement qu'on interdit l'exécution parallel des fonctions,
mais que la machine abstraite est séquentielle, et que le
résultat réel doit correspondre à une exécution possible de la
machine abstraite tant que le code est « correct » (pas de
comportement indéfini). Dans l'exemple de Fabien, la machine
abstraite peut appeler Pre avant Post, ou Post avant Pre, mais
il ne peut aller au délà que se elle peut prouver que le
résultat serait le même qu'un de ces deux cas, parce qu'il y a
bien des points de séquencement entre toutes les écritures.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze <james.kanze@gmail.com> writes:

> Comme j'ai déjà dit ailleurs, j'ai réelement vu le cas où lire
> de la mémoire qu'on n'avait jamais écrite pourrait provoquer un
> plantage. Mais dans ce cas-là, il suffisait d'y avoir écrit une
> fois, depuis la mise sous tension du système. En revanche, il y
> avait bien les anciens processeurs de Burroughs/Unisys, qui
> avait une architecture tagguée. En particulier, un entier
> n'était qu'un virgule flottant avec le champs exposant à 0
> (c-à-d 48 bits, avec 8 bits obligatoirement à 0, et magnitude
> signée, en plus). Il n'y avait qu'une seule instruction add, par
> exemple, qui fonctionnait à la fois pour les flottants et les
> entiers, selon les valeurs qu'on lui donnait. Je ne sais pas ce
> qui passait si tu mettais des bits d'un flottant dans une
> variable de type entier en C, mais ça m'étonnerait que ce soit
> quelque chose de bien prévisible.

De mémoire, il y a des interruptions quand c'est utilisé pour de
l'indexage. C'est à cette architecture que je faisais allusion aussi.
Mais j'avais oublié que c'était une machine à tag (en plus des 48 bits de
données, il y a quelques bits de tag) et un tag est prévu pour les données
non initialisées, avec interruption si utilisation.

C'est la plus vieille architecture encore en service. Les suivantes sont
celle de Sperry (aussi chez Unisys) et IBM 360.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/...ite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

On Feb 29, 7:25 pm, Jean-Marc Bourguet <j...@bourguet.org> wrote:
> James Kanze <james.ka...@gmail.com> writes:
> > Comme j'ai déjà dit ailleurs, j'ai réelement vu le cas où lire
> > de la mémoire qu'on n'avait jamais écrite pourrait provoquer un
> > plantage. Mais dans ce cas-là, il suffisait d'y avoir écrit une
> > fois, depuis la mise sous tension du système. En revanche, il y
> > avait bien les anciens processeurs de Burroughs/Unisys, qui
> > avait une architecture tagguée. En particulier, un entier
> > n'était qu'un virgule flottant avec le champs exposant à 0
> > (c-à-d 48 bits, avec 8 bits obligatoirement à 0, et magnitude
> > signée, en plus). Il n'y avait qu'une seule instruction add, par
> > exemple, qui fonctionnait à la fois pour les flottants et les
> > entiers, selon les valeurs qu'on lui donnait. Je ne sais pas ce
> > qui passait si tu mettais des bits d'un flottant dans une
> > variable de type entier en C, mais ça m'étonnerait que ce soit
> > quelque chose de bien prévisible.

> De mémoire,

Tu l'as réelement programmé. J'avoue ne le connaître moi-même
que de ouï-dire. (Enfin, prèsque. En 1967, j'ai pris un cours de
programmation à Georgia Tech, et il avait un Burroughs. Mais la
programmation était en Fortran, et on n'a rien vu de
l'architecture.)

> il y a des interruptions quand c'est utilisé pour
> de l'indexage. C'est à cette architecture que je faisais
> allusion aussi. Mais j'avais oublié que c'était une machine à
> tag (en plus des 48 bits de données, il y a quelques bits de
> tag) et un tag est prévu pour les données non initialisées,
> avec interruption si utilisation.

> C'est la plus vieille architecture encore en service. Les
> suivantes sont celle de Sperry (aussi chez Unisys) et IBM 360.

Je crois que celle de Sperry est encore plus ancienne. Au moins,
Sperry fabriquait les ordinateurs bien avant Burroughs. Et quant
à « en service », je ne sais pas. Ça fait quelque années
maintenant qu'elle a disparu du catalogue d'Unisys.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Olivier Miakinen wrote on 29/02/2008 13:13:
> Le 28/02/2008 12:07, Sylvain a écrit :
>> même dans ce cas je n'arrive pas à imaginer une valeur spéciale faisant
>> traper l'injecteur.
>
> As-tu lu le premier article de Jean-Marc Bourguet dans ce fil ?

oui.

> <cit.>
> il y a eu une machine n'ayant que des nombres en virgule flottante, mais
> où certaines opérations trappaient si une donnée n'était pas entière
> </cit.>

?!??
il y a eu une époque où les hommes vivaient dans des cavernes ...
écrire du code sur un PC devrait être interdit car incompatble
avec les moyens de cette époque ?

Sylvain.

James Kanze wrote on 29/02/2008 09:50:
>>
>> lorsqu'elle est lue, or pour que le code: "int x; cout << x;"
>> soit lu en mémoire et fourni au CPU, il faut qu'il ait été
>> écrit dans cette mémoire,
>
> Où ça ?

boulette!, la (mémoire de la) pile est juste allouée, pas écrite en effet.

> Tu prétends que c'est impossible ? Est-ce que tu peux te
> mettre dans la tête que je parle ici d'expérience. [...]

oui merci je comprends très bien que tu parles de *ton* expérience.

Sylvain.

James Kanze <james.kanze@gmail.com> writes:

> On Feb 29, 7:25 pm, Jean-Marc Bourguet <j...@bourguet.org> wrote:
> > James Kanze <james.ka...@gmail.com> writes:
> > > Comme j'ai déjà dit ailleurs, j'ai réelement vu le cas où lire
> > > de la mémoire qu'on n'avait jamais écrite pourrait provoquer un
> > > plantage. Mais dans ce cas-là, il suffisait d'y avoir écrit une
> > > fois, depuis la mise sous tension du système. En revanche, il y
> > > avait bien les anciens processeurs de Burroughs/Unisys, qui
> > > avait une architecture tagguée. En particulier, un entier
> > > n'était qu'un virgule flottant avec le champs exposant à 0
> > > (c-à-d 48 bits, avec 8 bits obligatoirement à 0, et magnitude
> > > signée, en plus). Il n'y avait qu'une seule instruction add, par
> > > exemple, qui fonctionnait à la fois pour les flottants et les
> > > entiers, selon les valeurs qu'on lui donnait. Je ne sais pas ce
> > > qui passait si tu mettais des bits d'un flottant dans une
> > > variable de type entier en C, mais ça m'étonnerait que ce soit
> > > quelque chose de bien prévisible.
>
> > De mémoire,
>
> Tu l'as réelement programmé.

Non, c'est pas du tout mon monde mais je m'intéresse à l'architecture des
ordinateur. J'ai lu beaucoup mais utilisé beaucoup moins. L'architecture
la plus exotique que j'ai utilisé, c'est les PDP-10.

> > C'est la plus vieille architecture encore en service. Les
> > suivantes sont celle de Sperry (aussi chez Unisys) et IBM 360.
>
> Je crois que celle de Sperry est encore plus ancienne.

Mise en service du B5000 en 1961, de la série 1100 d'Univac en 1962.

> Au moins, Sperry fabriquait les ordinateurs bien avant Burroughs.

Exact.

> Et quant à « en service », je ne sais pas. Ça fait quelque années
> maintenant qu'elle a disparu du catalogue d'Unisys.

Sur leur page web, tu prends mainframe et tu as accès aux MCP Mainframes
(qui doivent être les descendants du B5000) et aux OS2200 Mainframes (qui
doivent être les descendants de l'univac 1100). J'ai pas eu le temps de
fouiller pour confirmer, leur site est mal fait si on cherche des détails
techniques.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/...ite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

On 1 mar, 14:52, Jean-Marc Bourguet <j...@bourguet.org> wrote:
> James Kanze <james.ka...@gmail.com> writes:
> > > C'est la plus vieille architecture encore en service. Les
> > > suivantes sont celle de Sperry (aussi chez Unisys) et IBM 360.

> > Je crois que celle de Sperry est encore plus ancienne.

> Mise en service du B5000 en 1961, de la série 1100 d'Univac en 1962.

La question, évidemment, c'est : est-ce que la série 1100
d'Univac n'est qu'une prologation d'une architecture antérieur ?
Mais à vrai dire, il n'y a pas de raisons de le supposer, étant
donner la façon que les ordinateurs étaient développés alors.

> > Au moins, Sperry fabriquait les ordinateurs bien avant Burroughs.

> Exact.

> > Et quant à « en service », je ne sais pas. Ça fait quelque
> > années maintenant qu'elle a disparu du catalogue d'Unisys.

> Sur leur page web, tu prends mainframe et tu as accès aux MCP
> Mainframes (qui doivent être les descendants du B5000) et aux
> OS2200 Mainframes (qui doivent être les descendants de
> l'univac 1100). J'ai pas eu le temps de fouiller pour
> confirmer, leur site est mal fait si on cherche des détails
> techniques.

En effet. Je ne faisais que répéter ce que j'ai entendu
(j'oublie même où). Mais en cherchant, j'en ai trouvé une « C
Programming Reference Manual », avec un tableau (2-1) « Summary
of Basic Data Types and Data Type Specifiers », avec char en 8
bits (1 byte), float et double en 48 bits (1 word), long double
en 96 bits (2 words) et tous les autres types integraux en 48
bits (1 word). Et plus tard, un tableau 2-4 « Size and Range of
Plain and Signed Integer Types », avec l'intervale pour tous
(sauf les types caractère) de « 1-2**39 to 2**39-1 » (c-à-d
-549755813887 à 549755813887 -- ce n'est pas du complément à 2,
et ce ne se sert pas de tous les 48 bits), et tableau 2-5 pour
les unsigned, avec l'intervale 0 à 2**39-1 -- on rémarque bien
que UINT_MAX == INT_MAX.

L'intervale des flottans est assez curieux aussi : 8.75811540204E-47
to
4.31359146674E68. (En représentation binaire, ça ferait un
intervale de 380 pour les exposants. Une valeur plutôt bizarre,
à mon avis, et qui aurait besoin de plus que les huit bits
réservés dans les 48 par les entiers.)

Enfin, pour ceux qui s'y intéressent, j'ai trouvé cette
documentation, et un tas d'autres documentations, à
http://public.support.unisys.com/com...libraries.aspx.
(Et en passant, il y a encore des manuals d'Algol. Je rappelle
que le language de programmation préféré dans cet environement,
c'était bien l'Algol.)

Si j'ai bien compris la site, dans les produits haut de gamme,
c'est réelement implémenté dans le hardward ; dans les produits
bas de gamme, c'est plutôt émulé par une machine virtuelle.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On 2 mar, 12:03, James Kanze <james.ka...@gmail.com> wrote:
> On 1 mar, 14:52, Jean-Marc Bourguet <j...@bourguet.org> wrote:
> En effet. Je ne faisais que répéter ce que j'ai entendu
> (j'oublie même où). Mais en cherchant, j'en ai trouvé une « C
> Programming Reference Manual »,

Une autre chose intéressante ; dans une annexe au document
cité : « The default character set is EBCDIC. ». Le titre de
l'annexe est bien « Getting Source Onto A Series Systems », ce
qui démontrait bien qu'il s'agit de l'architecture Séries A.
(Toute la documentation commercielle a été mis à jour, avec MCP,
mais les techniciens continuent à l'appeler par son nom
original.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze <james.kanze@gmail.com> writes:

> On 1 mar, 14:52, Jean-Marc Bourguet <j...@bourguet.org> wrote:
> > James Kanze <james.ka...@gmail.com> writes:
> > > > C'est la plus vieille architecture encore en service. Les
> > > > suivantes sont celle de Sperry (aussi chez Unisys) et IBM 360.
>
> > > Je crois que celle de Sperry est encore plus ancienne.
>
> > Mise en service du B5000 en 1961, de la série 1100 d'Univac en 1962.
>
> La question, évidemment, c'est : est-ce que la série 1100
> d'Univac n'est qu'une prologation d'une architecture antérieur ?
> Mais à vrai dire, il n'y a pas de raisons de le supposer, étant
> donner la façon que les ordinateurs étaient développés alors.

J'ai voulu revoir mes sources et elles semblent incohérentes. J'ai pas le
temps de recouper et de voir ce qu'il en est exactement (sur d'autres
sources encore comme bitsaver qui a des scan de pas mal de manuels). La
série 1100 d'Univac a l'air de dater des années 50, mais certains modèles
ont l'air de ne pas être de la même architecture que les autres (machines
24 bits et 36 bits par exemple). Les architectures Univac plus vieilles
(Univac I et II) m'ont l'air d'être totalement différentes (purement basées
sur les caractères, avec un mot de 12 caractères).

> Enfin, pour ceux qui s'y intéressent, j'ai trouvé cette documentation, et
> un tas d'autres documentations, à
> http://public.support.unisys.com/com...libraries.aspx.
> (Et en passant, il y a encore des manuals d'Algol. Je rappelle que le
> language de programmation préféré dans cet environement, c'était bien
> l'Algol.)

> Si j'ai bien compris la site, dans les produits haut de gamme,
> c'est réelement implémenté dans le hardward ; dans les produits
> bas de gamme, c'est plutôt émulé par une machine virtuelle.

C'est l'impression que j'avais aussi. De toute manière, il n'y a guère de
différence de fond entre une machine virtuelle et une implémentation par
micro-programmation, en particulier quand le micro-programme est
modifiable.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/...ite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Le 29/02/2008 21:51, Sylvain a écrit :
>
>> <cit.>
>> il y a eu une machine n'ayant que des nombres en virgule flottante, mais
>> où certaines opérations trappaient si une donnée n'était pas entière
>> </cit.>
>
> ?!??
> il y a eu une époque où les hommes vivaient dans des cavernes ...
> écrire du code sur un PC devrait être interdit car incompatble
> avec les moyens de cette époque ?

En quoi cette architecture serait-elle incompatible avec les moyens de
notre époque ? JavaScript, par exemple, ne stocke que des nombres en
virgule flottante au format IEEE754, ce qui ne l'empêche pas d'avoir
des opérations qui limitent les valeurs aux entiers entre 0 et 2^32-1,
ou entre -2^31 et 2^31-1, ou encore entre 0 et 2^16-1.

Mais bon, comme d'habitude tu n'es là que pour troller et j'ai encore
marché dedans...

Olivier Miakinen wrote on 03/03/2008 13:24:
>
> Mais bon, comme d'habitude tu n'es là que pour troller et j'ai encore
> marché dedans...

à crier au troll dans la plupart de tes posts, tu n'es plus audible.

je ne me rapelles pas la moindre réponse de ta part à un de mes rares
posts ici, encore moins à une enfilade - remarque je ne l'affirmes pas
puisque tu n'archives pas et pour cette contrib. c'est clairement mieux.

Sylvain.