Je viens d'installer Flash Player à partir de
http://fpdownload.macromedia.com/get/flashplayer/pdc/13.0.0.182/install_f
lash_player_osx.dmg
c'est le lien de l'install fournit par la fenêtre "uodate Flash Player"
Sous Safari 5.1 et Firefox 27 et 28, les Flash ne marchent plus :
"plug-in error"
seul Chrome 34.0 l'utilise sans problème
L'OS est 10/6.8
In article <1lk39xc.18cr0ex1tbikisN%, (SbM) wrote:
Pierre-Alain Dorange wrote:
> J.P wrote: > > > > « We have determined that this problem is due to a compiler update in > > > our build infrastructure that exposed a long-standing bug in a Mac > > > system library. Flash Player now attempts to use CPU instructions that > > > are not available on a subset of supported Mac hardware from 2006 to > > > 2007. » > > > > > > C'est donc lié à l'absence de certaines instructions dans le jeu > > > d'instructions de certains Mac. > > > > Ça veut aussi dire que Flash tape directement dans le matériel ce que je > > pensais être une méthode de programmation totalement obsolète ! > > Ça me rappelle de bien vieilles applis sous Win 3.1 et suivants :-) > > Faut pas forcément être trop critique non plus... Sans information > détaillée ça ne veux pas dire que Flash tape directement dans le > hardware... Il est évoqué le lien entre une mise à jour du compilateur > et un bug dans les librairies Mac.
Voilà. A priori il n'est dit nulle part que c'est Flash lui-même qui « tape dans le matériel » : « « We have determined that this problem is due to a compiler update in our build infrastructure that exposed a long-standing bug in a Mac system library. »
Mais J.P. aime bien troller :)
"Flash Player now attempts to use CPU instructions" Cela n'indique pas que Flash tape dans le matériel plutôt que rester un peu au-dessus, dans des bibiothèques ou API Apple ?
-- Jean-Pierre
In article <1lk39xc.18cr0ex1tbikisN%sebastienmarty@yahoo.fr>,
sebastienmarty@yahoo.fr (SbM) wrote:
> J.P <jpp@gmail.com> wrote:
>
> > > « We have determined that this problem is due to a compiler update in
> > > our build infrastructure that exposed a long-standing bug in a Mac
> > > system library. Flash Player now attempts to use CPU instructions that
> > > are not available on a subset of supported Mac hardware from 2006 to
> > > 2007. »
> > >
> > > C'est donc lié à l'absence de certaines instructions dans le jeu
> > > d'instructions de certains Mac.
> >
> > Ça veut aussi dire que Flash tape directement dans le matériel ce que je
> > pensais être une méthode de programmation totalement obsolète !
> > Ça me rappelle de bien vieilles applis sous Win 3.1 et suivants :-)
>
> Faut pas forcément être trop critique non plus... Sans information
> détaillée ça ne veux pas dire que Flash tape directement dans le
> hardware... Il est évoqué le lien entre une mise à jour du compilateur
> et un bug dans les librairies Mac.
Voilà. A priori il n'est dit nulle part que c'est Flash lui-même qui
« tape dans le matériel » : « « We have determined that this problem is
due to a compiler update in our build infrastructure that exposed a
long-standing bug in a Mac system library. »
Mais J.P. aime bien troller :)
"Flash Player now attempts to use CPU instructions"
Cela n'indique pas que Flash tape dans le matériel plutôt que rester un
peu au-dessus, dans des bibiothèques ou API Apple ?
In article <1lk39xc.18cr0ex1tbikisN%, (SbM) wrote:
Pierre-Alain Dorange wrote:
> J.P wrote: > > > > « We have determined that this problem is due to a compiler update in > > > our build infrastructure that exposed a long-standing bug in a Mac > > > system library. Flash Player now attempts to use CPU instructions that > > > are not available on a subset of supported Mac hardware from 2006 to > > > 2007. » > > > > > > C'est donc lié à l'absence de certaines instructions dans le jeu > > > d'instructions de certains Mac. > > > > Ça veut aussi dire que Flash tape directement dans le matériel ce que je > > pensais être une méthode de programmation totalement obsolète ! > > Ça me rappelle de bien vieilles applis sous Win 3.1 et suivants :-) > > Faut pas forcément être trop critique non plus... Sans information > détaillée ça ne veux pas dire que Flash tape directement dans le > hardware... Il est évoqué le lien entre une mise à jour du compilateur > et un bug dans les librairies Mac.
Voilà. A priori il n'est dit nulle part que c'est Flash lui-même qui « tape dans le matériel » : « « We have determined that this problem is due to a compiler update in our build infrastructure that exposed a long-standing bug in a Mac system library. »
Mais J.P. aime bien troller :)
"Flash Player now attempts to use CPU instructions" Cela n'indique pas que Flash tape dans le matériel plutôt que rester un peu au-dessus, dans des bibiothèques ou API Apple ?
-- Jean-Pierre
sebastienmarty
J.P wrote:
In article <1lk39xc.18cr0ex1tbikisN%, (SbM) wrote:
> Pierre-Alain Dorange wrote: > > > J.P wrote: > > > > > > « We have determined that this problem is due to a compiler update > > > > in our build infrastructure that exposed a long-standing bug in a > > > > Mac system library. Flash Player now attempts to use CPU > > > > instructions that are not available on a subset of supported Mac > > > > hardware from 2006 to 2007. » > > > > > > > > C'est donc lié à l'absence de certaines instructions dans le jeu > > > > d'instructions de certains Mac. > > > > > > Ça veut aussi dire que Flash tape directement dans le matériel ce > > > que je pensais être une méthode de programmation totalement obsolète > > > ! Ça me rappelle de bien vieilles applis sous Win 3.1 et suivants > > > :-) > > > > Faut pas forcément être trop critique non plus... Sans information > > détaillée ça ne veux pas dire que Flash tape directement dans le > > hardware... Il est évoqué le lien entre une mise à jour du compilateur > > et un bug dans les librairies Mac. > > Voilà. A priori il n'est dit nulle part que c'est Flash lui-même qui > « tape dans le matériel » : « « We have determined that this problem is > due to a compiler update in our build infrastructure that exposed a > long-standing bug in a Mac system library. » > > Mais J.P. aime bien troller :)
"Flash Player now attempts to use CPU instructions" Cela n'indique pas que Flash tape dans le matériel plutôt que rester un peu au-dessus, dans des bibiothèques ou API Apple ?
Tu ne cites qu'une partie. La formulation n'est certes pas très claire, mais pour moi c'est le compilo qui utilise des instructions non disponibles. Faudrait étudier le source :)
-- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
J.P <jpp@gmail.com> wrote:
In article <1lk39xc.18cr0ex1tbikisN%sebastienmarty@yahoo.fr>,
sebastienmarty@yahoo.fr (SbM) wrote:
> Pierre-Alain Dorange <pdorange@pas-de-pub-merci.mac.com> wrote:
>
> > J.P <jpp@gmail.com> wrote:
> >
> > > > « We have determined that this problem is due to a compiler update
> > > > in our build infrastructure that exposed a long-standing bug in a
> > > > Mac system library. Flash Player now attempts to use CPU
> > > > instructions that are not available on a subset of supported Mac
> > > > hardware from 2006 to 2007. »
> > > >
> > > > C'est donc lié à l'absence de certaines instructions dans le jeu
> > > > d'instructions de certains Mac.
> > >
> > > Ça veut aussi dire que Flash tape directement dans le matériel ce
> > > que je pensais être une méthode de programmation totalement obsolète
> > > ! Ça me rappelle de bien vieilles applis sous Win 3.1 et suivants
> > > :-)
> >
> > Faut pas forcément être trop critique non plus... Sans information
> > détaillée ça ne veux pas dire que Flash tape directement dans le
> > hardware... Il est évoqué le lien entre une mise à jour du compilateur
> > et un bug dans les librairies Mac.
>
> Voilà. A priori il n'est dit nulle part que c'est Flash lui-même qui
> « tape dans le matériel » : « « We have determined that this problem is
> due to a compiler update in our build infrastructure that exposed a
> long-standing bug in a Mac system library. »
>
> Mais J.P. aime bien troller :)
"Flash Player now attempts to use CPU instructions"
Cela n'indique pas que Flash tape dans le matériel plutôt que rester un
peu au-dessus, dans des bibiothèques ou API Apple ?
Tu ne cites qu'une partie. La formulation n'est certes pas très claire,
mais pour moi c'est le compilo qui utilise des instructions non
disponibles. Faudrait étudier le source :)
--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)
In article <1lk39xc.18cr0ex1tbikisN%, (SbM) wrote:
> Pierre-Alain Dorange wrote: > > > J.P wrote: > > > > > > « We have determined that this problem is due to a compiler update > > > > in our build infrastructure that exposed a long-standing bug in a > > > > Mac system library. Flash Player now attempts to use CPU > > > > instructions that are not available on a subset of supported Mac > > > > hardware from 2006 to 2007. » > > > > > > > > C'est donc lié à l'absence de certaines instructions dans le jeu > > > > d'instructions de certains Mac. > > > > > > Ça veut aussi dire que Flash tape directement dans le matériel ce > > > que je pensais être une méthode de programmation totalement obsolète > > > ! Ça me rappelle de bien vieilles applis sous Win 3.1 et suivants > > > :-) > > > > Faut pas forcément être trop critique non plus... Sans information > > détaillée ça ne veux pas dire que Flash tape directement dans le > > hardware... Il est évoqué le lien entre une mise à jour du compilateur > > et un bug dans les librairies Mac. > > Voilà. A priori il n'est dit nulle part que c'est Flash lui-même qui > « tape dans le matériel » : « « We have determined that this problem is > due to a compiler update in our build infrastructure that exposed a > long-standing bug in a Mac system library. » > > Mais J.P. aime bien troller :)
"Flash Player now attempts to use CPU instructions" Cela n'indique pas que Flash tape dans le matériel plutôt que rester un peu au-dessus, dans des bibiothèques ou API Apple ?
Tu ne cites qu'une partie. La formulation n'est certes pas très claire, mais pour moi c'est le compilo qui utilise des instructions non disponibles. Faudrait étudier le source :)
-- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
J.P
In article <1lk3zdg.fcm29p1pzrzftN%, (SbM) wrote:
« We have determined that this problem is > > due to a compiler update in our build infrastructure that exposed a > > long-standing bug in a Mac system library. »
Le problème serait plutôt dans une interprétation d'une "Mac library" par une nouvelle version de compilateur. La version précédente ne créait pas d'erreur malgré ce bug, la nouvelle : oui. et donc, mea-culpa, Flash ne taperait pas dans le CPU, au moins dans ce cas là, mais bien dans des bibliothèques système Apple.
-- Jean-Pierre
In article <1lk3zdg.fcm29p1pzrzftN%sebastienmarty@yahoo.fr>,
sebastienmarty@yahoo.fr (SbM) wrote:
« We have determined that this problem is
> > due to a compiler update in our build infrastructure that exposed a
> > long-standing bug in a Mac system library. »
Le problème serait plutôt dans une interprétation d'une "Mac library"
par une nouvelle version de compilateur.
La version précédente ne créait pas d'erreur malgré ce bug, la nouvelle
: oui.
et donc, mea-culpa, Flash ne taperait pas dans le CPU, au moins dans ce
cas là, mais bien dans des bibliothèques système Apple.
« We have determined that this problem is > > due to a compiler update in our build infrastructure that exposed a > > long-standing bug in a Mac system library. »
Le problème serait plutôt dans une interprétation d'une "Mac library" par une nouvelle version de compilateur. La version précédente ne créait pas d'erreur malgré ce bug, la nouvelle : oui. et donc, mea-culpa, Flash ne taperait pas dans le CPU, au moins dans ce cas là, mais bien dans des bibliothèques système Apple.
-- Jean-Pierre
pdorange
J.P wrote:
> Mais J.P. aime bien troller :)
"Flash Player now attempts to use CPU instructions" Cela n'indique pas que Flash tape dans le matériel plutôt que rester un peu au-dessus, dans des bibiothèques ou API Apple ?
Disons que un programme qui n'utilise pas les "CPU instructions", et bien comment le dire... C'est pas un logiciel c'est des données...
Bien sur que *tout* les logiciels (tous) utilisent les instructions du CPU. Je répète : TOUS, de MacSoup à Safari en passant par les AppleScripts, les scripts shell etc... C'est la base d'un logiciel.
Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
J.P <jpp@gmail.com> wrote:
> Mais J.P. aime bien troller :)
"Flash Player now attempts to use CPU instructions"
Cela n'indique pas que Flash tape dans le matériel plutôt que rester un
peu au-dessus, dans des bibiothèques ou API Apple ?
Disons que un programme qui n'utilise pas les "CPU instructions", et
bien comment le dire... C'est pas un logiciel c'est des données...
Bien sur que *tout* les logiciels (tous) utilisent les instructions du
CPU. Je répète : TOUS, de MacSoup à Safari en passant par les
AppleScripts, les scripts shell etc... C'est la base d'un logiciel.
Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
"Flash Player now attempts to use CPU instructions" Cela n'indique pas que Flash tape dans le matériel plutôt que rester un peu au-dessus, dans des bibiothèques ou API Apple ?
Disons que un programme qui n'utilise pas les "CPU instructions", et bien comment le dire... C'est pas un logiciel c'est des données...
Bien sur que *tout* les logiciels (tous) utilisent les instructions du CPU. Je répète : TOUS, de MacSoup à Safari en passant par les AppleScripts, les scripts shell etc... C'est la base d'un logiciel.
Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
J.P
In article <1lk51f5.fkl5cnhsqc32N%, (Pierre-Alain Dorange) wrote:
J.P wrote:
> > Mais J.P. aime bien troller :) > > "Flash Player now attempts to use CPU instructions" > Cela n'indique pas que Flash tape dans le matériel plutôt que rester un > peu au-dessus, dans des bibiothèques ou API Apple ?
Disons que un programme qui n'utilise pas les "CPU instructions", et bien comment le dire... C'est pas un logiciel c'est des données...
Bien sur que *tout* les logiciels (tous) utilisent les instructions du CPU. Je répète : TOUS, de MacSoup à Safari en passant par les AppleScripts, les scripts shell etc... C'est la base d'un logiciel.
Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
Les seuls programmes que j'ai pu écrire et qui contenaient des instructions CPU étaient en assembleur. Les autres étaient écrits dans un langage de plus ou moins haut niveau (de Basic à Ada) qui, un fois compilés et liés à des bibliotèques, produisaient un éxécutable contenant les instructions adéquates pour le CPU et les périphériques concernés pour aboutir, en principe, aux résultats escomptés.
Mais les temps ont peut-être changé.
-- Jean-Pierre
In article <1lk51f5.fkl5cnhsqc32N%pdorange@pas-de-pub-merci.mac.com>,
pdorange@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) wrote:
J.P <jpp@gmail.com> wrote:
> > Mais J.P. aime bien troller :)
>
> "Flash Player now attempts to use CPU instructions"
> Cela n'indique pas que Flash tape dans le matériel plutôt que rester un
> peu au-dessus, dans des bibiothèques ou API Apple ?
Disons que un programme qui n'utilise pas les "CPU instructions", et
bien comment le dire... C'est pas un logiciel c'est des données...
Bien sur que *tout* les logiciels (tous) utilisent les instructions du
CPU. Je répète : TOUS, de MacSoup à Safari en passant par les
AppleScripts, les scripts shell etc... C'est la base d'un logiciel.
Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
Les seuls programmes que j'ai pu écrire et qui contenaient des
instructions CPU étaient en assembleur.
Les autres étaient écrits dans un langage de plus ou moins haut niveau
(de Basic à Ada) qui, un fois compilés et liés à des bibliotèques,
produisaient un éxécutable contenant les instructions adéquates pour le
CPU et les périphériques concernés pour aboutir, en principe, aux
résultats escomptés.
In article <1lk51f5.fkl5cnhsqc32N%, (Pierre-Alain Dorange) wrote:
J.P wrote:
> > Mais J.P. aime bien troller :) > > "Flash Player now attempts to use CPU instructions" > Cela n'indique pas que Flash tape dans le matériel plutôt que rester un > peu au-dessus, dans des bibiothèques ou API Apple ?
Disons que un programme qui n'utilise pas les "CPU instructions", et bien comment le dire... C'est pas un logiciel c'est des données...
Bien sur que *tout* les logiciels (tous) utilisent les instructions du CPU. Je répète : TOUS, de MacSoup à Safari en passant par les AppleScripts, les scripts shell etc... C'est la base d'un logiciel.
Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
Les seuls programmes que j'ai pu écrire et qui contenaient des instructions CPU étaient en assembleur. Les autres étaient écrits dans un langage de plus ou moins haut niveau (de Basic à Ada) qui, un fois compilés et liés à des bibliotèques, produisaient un éxécutable contenant les instructions adéquates pour le CPU et les périphériques concernés pour aboutir, en principe, aux résultats escomptés.
Mais les temps ont peut-être changé.
-- Jean-Pierre
sebastienmarty
J.P wrote:
In article <1lk51f5.fkl5cnhsqc32N%, (Pierre-Alain Dorange) wrote:
> J.P wrote: > > > > Mais J.P. aime bien troller :) > > > > "Flash Player now attempts to use CPU instructions" > > Cela n'indique pas que Flash tape dans le matériel plutôt que rester un > > peu au-dessus, dans des bibiothèques ou API Apple ? > > Disons que un programme qui n'utilise pas les "CPU instructions", et > bien comment le dire... C'est pas un logiciel c'est des données... > > Bien sur que *tout* les logiciels (tous) utilisent les instructions du > CPU. Je répète : TOUS, de MacSoup à Safari en passant par les > AppleScripts, les scripts shell etc... C'est la base d'un logiciel. > > Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
Les seuls programmes que j'ai pu écrire et qui contenaient des instructions CPU étaient en assembleur.
Ils ne contenaient donc pas d'instructions CPU mais des *mnémoniques*, qui étaient traduites ensuite en code machine par ton assembleur. C'est plus « direct » qu'un langage haut niveau, certes, mais en gros c'est le même principe.
-- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
J.P <jpp@gmail.com> wrote:
In article <1lk51f5.fkl5cnhsqc32N%pdorange@pas-de-pub-merci.mac.com>,
pdorange@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) wrote:
> J.P <jpp@gmail.com> wrote:
>
> > > Mais J.P. aime bien troller :)
> >
> > "Flash Player now attempts to use CPU instructions"
> > Cela n'indique pas que Flash tape dans le matériel plutôt que rester un
> > peu au-dessus, dans des bibiothèques ou API Apple ?
>
> Disons que un programme qui n'utilise pas les "CPU instructions", et
> bien comment le dire... C'est pas un logiciel c'est des données...
>
> Bien sur que *tout* les logiciels (tous) utilisent les instructions du
> CPU. Je répète : TOUS, de MacSoup à Safari en passant par les
> AppleScripts, les scripts shell etc... C'est la base d'un logiciel.
>
> Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
Les seuls programmes que j'ai pu écrire et qui contenaient des
instructions CPU étaient en assembleur.
Ils ne contenaient donc pas d'instructions CPU mais des *mnémoniques*,
qui étaient traduites ensuite en code machine par ton assembleur. C'est
plus « direct » qu'un langage haut niveau, certes, mais en gros c'est le
même principe.
--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)
In article <1lk51f5.fkl5cnhsqc32N%, (Pierre-Alain Dorange) wrote:
> J.P wrote: > > > > Mais J.P. aime bien troller :) > > > > "Flash Player now attempts to use CPU instructions" > > Cela n'indique pas que Flash tape dans le matériel plutôt que rester un > > peu au-dessus, dans des bibiothèques ou API Apple ? > > Disons que un programme qui n'utilise pas les "CPU instructions", et > bien comment le dire... C'est pas un logiciel c'est des données... > > Bien sur que *tout* les logiciels (tous) utilisent les instructions du > CPU. Je répète : TOUS, de MacSoup à Safari en passant par les > AppleScripts, les scripts shell etc... C'est la base d'un logiciel. > > Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
Les seuls programmes que j'ai pu écrire et qui contenaient des instructions CPU étaient en assembleur.
Ils ne contenaient donc pas d'instructions CPU mais des *mnémoniques*, qui étaient traduites ensuite en code machine par ton assembleur. C'est plus « direct » qu'un langage haut niveau, certes, mais en gros c'est le même principe.
-- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
J.P
In article <1lk53z9.188meu11mrp4y1N%, (SbM) wrote:
J.P wrote:
> In article <1lk51f5.fkl5cnhsqc32N%, > (Pierre-Alain Dorange) wrote: > > > J.P wrote: > > > > > > Mais J.P. aime bien troller :) > > > > > > "Flash Player now attempts to use CPU instructions" > > > Cela n'indique pas que Flash tape dans le matériel plutôt que rester un > > > peu au-dessus, dans des bibiothèques ou API Apple ? > > > > Disons que un programme qui n'utilise pas les "CPU instructions", et > > bien comment le dire... C'est pas un logiciel c'est des données... > > > > Bien sur que *tout* les logiciels (tous) utilisent les instructions du > > CPU. Je répète : TOUS, de MacSoup à Safari en passant par les > > AppleScripts, les scripts shell etc... C'est la base d'un logiciel. > > > > Rappellons que le CPU c'est ce qui exécute les instructions... du CPU. > > Les seuls programmes que j'ai pu écrire et qui contenaient des > instructions CPU étaient en assembleur.
Ils ne contenaient donc pas d'instructions CPU mais des *mnémoniques*, qui étaient traduites ensuite en code machine par ton assembleur. C'est plus « direct » qu'un langage haut niveau, certes, mais en gros c'est le même principe.
Codant en assembleur, on connait exactement les instructions qui vont au CPU, avec un langage on ne sait absolument pas le code qu'il va produire à moins d'aller fouiller dans l'éxécutable. Et le compilo, au lieu d'une traduction/translation bête et méchante des MOV, ADD et autres, il optimise, et donc ce qu'il produit est assez imprévisible en ce qui concerne les instructions bas niveau utilisées. Je suppose que l'utilisation des threads, du parallélisme ou la compilation pour multicore, compliquent encore un peu la chose.
-- Jean-Pierre
In article <1lk53z9.188meu11mrp4y1N%sebastienmarty@yahoo.fr>,
sebastienmarty@yahoo.fr (SbM) wrote:
J.P <jpp@gmail.com> wrote:
> In article <1lk51f5.fkl5cnhsqc32N%pdorange@pas-de-pub-merci.mac.com>,
> pdorange@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) wrote:
>
> > J.P <jpp@gmail.com> wrote:
> >
> > > > Mais J.P. aime bien troller :)
> > >
> > > "Flash Player now attempts to use CPU instructions"
> > > Cela n'indique pas que Flash tape dans le matériel plutôt que rester un
> > > peu au-dessus, dans des bibiothèques ou API Apple ?
> >
> > Disons que un programme qui n'utilise pas les "CPU instructions", et
> > bien comment le dire... C'est pas un logiciel c'est des données...
> >
> > Bien sur que *tout* les logiciels (tous) utilisent les instructions du
> > CPU. Je répète : TOUS, de MacSoup à Safari en passant par les
> > AppleScripts, les scripts shell etc... C'est la base d'un logiciel.
> >
> > Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
>
> Les seuls programmes que j'ai pu écrire et qui contenaient des
> instructions CPU étaient en assembleur.
Ils ne contenaient donc pas d'instructions CPU mais des *mnémoniques*,
qui étaient traduites ensuite en code machine par ton assembleur. C'est
plus « direct » qu'un langage haut niveau, certes, mais en gros c'est le
même principe.
Codant en assembleur, on connait exactement les instructions qui vont au
CPU, avec un langage on ne sait absolument pas le code qu'il va produire
à moins d'aller fouiller dans l'éxécutable.
Et le compilo, au lieu d'une traduction/translation bête et méchante des
MOV, ADD et autres, il optimise, et donc ce qu'il produit est assez
imprévisible en ce qui concerne les instructions bas niveau utilisées.
Je suppose que l'utilisation des threads, du parallélisme ou la
compilation pour multicore, compliquent encore un peu la chose.
In article <1lk53z9.188meu11mrp4y1N%, (SbM) wrote:
J.P wrote:
> In article <1lk51f5.fkl5cnhsqc32N%, > (Pierre-Alain Dorange) wrote: > > > J.P wrote: > > > > > > Mais J.P. aime bien troller :) > > > > > > "Flash Player now attempts to use CPU instructions" > > > Cela n'indique pas que Flash tape dans le matériel plutôt que rester un > > > peu au-dessus, dans des bibiothèques ou API Apple ? > > > > Disons que un programme qui n'utilise pas les "CPU instructions", et > > bien comment le dire... C'est pas un logiciel c'est des données... > > > > Bien sur que *tout* les logiciels (tous) utilisent les instructions du > > CPU. Je répète : TOUS, de MacSoup à Safari en passant par les > > AppleScripts, les scripts shell etc... C'est la base d'un logiciel. > > > > Rappellons que le CPU c'est ce qui exécute les instructions... du CPU. > > Les seuls programmes que j'ai pu écrire et qui contenaient des > instructions CPU étaient en assembleur.
Ils ne contenaient donc pas d'instructions CPU mais des *mnémoniques*, qui étaient traduites ensuite en code machine par ton assembleur. C'est plus « direct » qu'un langage haut niveau, certes, mais en gros c'est le même principe.
Codant en assembleur, on connait exactement les instructions qui vont au CPU, avec un langage on ne sait absolument pas le code qu'il va produire à moins d'aller fouiller dans l'éxécutable. Et le compilo, au lieu d'une traduction/translation bête et méchante des MOV, ADD et autres, il optimise, et donc ce qu'il produit est assez imprévisible en ce qui concerne les instructions bas niveau utilisées. Je suppose que l'utilisation des threads, du parallélisme ou la compilation pour multicore, compliquent encore un peu la chose.
-- Jean-Pierre
pdorange
J.P wrote:
> Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
Les seuls programmes que j'ai pu écrire et qui contenaient des instructions CPU étaient en assembleur.
Non, tout les programmes utilisent les instructions CPU, c'est pas possible autrement.
Que ce soit un langage compilé ou interprété, le source (que tu as écris ou n'importe qui d'autre) est traduit en langage machine (c'est possible de faire autrement) donc en instruction CPU : c'est la base.
Donc, tout logiciel est traduit en intruction machine (ou CPU si tu préfèes) (par un compilateur ou un interpréteur).
Donc on ne peux absolument rien déduire d'un communiqué qui indique que le plug-in utilise des instruction CPU... c'est un peu comme de dire que je respire de l'air...
[...] Mais les temps ont peut-être changé.
Un CPU reste un CPU, c'est lce qui exécute les instructions (et qui n'est capable que de comprend ces propres instructions). On notera qu'un GPU est aussi un CPU mais spécialisé.
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
J.P <jpp@gmail.com> wrote:
> Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
Les seuls programmes que j'ai pu écrire et qui contenaient des
instructions CPU étaient en assembleur.
Non, tout les programmes utilisent les instructions CPU, c'est pas
possible autrement.
Que ce soit un langage compilé ou interprété, le source (que tu as écris
ou n'importe qui d'autre) est traduit en langage machine (c'est possible
de faire autrement) donc en instruction CPU : c'est la base.
Donc, tout logiciel est traduit en intruction machine (ou CPU si tu
préfèes) (par un compilateur ou un interpréteur).
Donc on ne peux absolument rien déduire d'un communiqué qui indique que
le plug-in utilise des instruction CPU... c'est un peu comme de dire que
je respire de l'air...
[...]
Mais les temps ont peut-être changé.
Un CPU reste un CPU, c'est lce qui exécute les instructions (et qui
n'est capable que de comprend ces propres instructions).
On notera qu'un GPU est aussi un CPU mais spécialisé.
> Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
Les seuls programmes que j'ai pu écrire et qui contenaient des instructions CPU étaient en assembleur.
Non, tout les programmes utilisent les instructions CPU, c'est pas possible autrement.
Que ce soit un langage compilé ou interprété, le source (que tu as écris ou n'importe qui d'autre) est traduit en langage machine (c'est possible de faire autrement) donc en instruction CPU : c'est la base.
Donc, tout logiciel est traduit en intruction machine (ou CPU si tu préfèes) (par un compilateur ou un interpréteur).
Donc on ne peux absolument rien déduire d'un communiqué qui indique que le plug-in utilise des instruction CPU... c'est un peu comme de dire que je respire de l'air...
[...] Mais les temps ont peut-être changé.
Un CPU reste un CPU, c'est lce qui exécute les instructions (et qui n'est capable que de comprend ces propres instructions). On notera qu'un GPU est aussi un CPU mais spécialisé.
Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
sebastienmarty
Pierre-Alain Dorange wrote:
J.P wrote:
> > Rappellons que le CPU c'est ce qui exécute les instructions... du CPU. > > Les seuls programmes que j'ai pu écrire et qui contenaient des > instructions CPU étaient en assembleur.
Non, tout les programmes utilisent les instructions CPU, c'est pas possible autrement.
La distinction que fait J.P., c'est entre l'assembleur, où l'auteur utilise directement les instructions du processeur sous forme de mnémoniques (c'est ce qu'il appelle « taper dans le matériel »), et les langages de haut niveau où le source est traduit en langage machine par le compilateur sans que l'auteur du programme sache quelles sont les instructions CPU utilisées.
-- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
> > Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
>
> Les seuls programmes que j'ai pu écrire et qui contenaient des
> instructions CPU étaient en assembleur.
Non, tout les programmes utilisent les instructions CPU, c'est pas
possible autrement.
La distinction que fait J.P., c'est entre l'assembleur, où l'auteur
utilise directement les instructions du processeur sous forme de
mnémoniques (c'est ce qu'il appelle « taper dans le matériel »), et les
langages de haut niveau où le source est traduit en langage machine par
le compilateur sans que l'auteur du programme sache quelles sont les
instructions CPU utilisées.
--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)
> > Rappellons que le CPU c'est ce qui exécute les instructions... du CPU. > > Les seuls programmes que j'ai pu écrire et qui contenaient des > instructions CPU étaient en assembleur.
Non, tout les programmes utilisent les instructions CPU, c'est pas possible autrement.
La distinction que fait J.P., c'est entre l'assembleur, où l'auteur utilise directement les instructions du processeur sous forme de mnémoniques (c'est ce qu'il appelle « taper dans le matériel »), et les langages de haut niveau où le source est traduit en langage machine par le compilateur sans que l'auteur du programme sache quelles sont les instructions CPU utilisées.
-- [SbM] "If the French were really intelligent, they'd speak English" (W. Sheed)
J.P
In article <1lk5h4j.1kb0kr9dkmenzN%, (SbM) wrote:
Pierre-Alain Dorange wrote:
> J.P wrote: > > > > Rappellons que le CPU c'est ce qui exécute les instructions... du CPU. > > > > Les seuls programmes que j'ai pu écrire et qui contenaient des > > instructions CPU étaient en assembleur. > > Non, tout les programmes utilisent les instructions CPU, c'est pas > possible autrement.
La distinction que fait J.P., c'est entre l'assembleur, où l'auteur utilise directement les instructions du processeur sous forme de mnémoniques (c'est ce qu'il appelle « taper dans le matériel »), et les langages de haut niveau où le source est traduit en langage machine par le compilateur sans que l'auteur du programme sache quelles sont les instructions CPU utilisées.
et encore moins quand le programme, le code que j'écris, une fois compilé est lié à des bibliothèques dont on ne connait que les méthodes d'entrées et sortie, rien de ce qui se passe dedans. Et là on parle simple, car si on ajoute l'optimisation des compilateurs pour le threading, le pipeling, le parallélisme etc. ce qui arrive au CPU est totalement inconnu du programeur à moins de fouiller l'éxécutable. Et c'est probablement en faisant cela que les développeurs de Flash 13 ont découvert ces instructions incompatibles avec les iMac de ces séries dont mon iMac7,1.
-- Jean-Pierre
In article <1lk5h4j.1kb0kr9dkmenzN%sebastienmarty@yahoo.fr>,
sebastienmarty@yahoo.fr (SbM) wrote:
> J.P <jpp@gmail.com> wrote:
>
> > > Rappellons que le CPU c'est ce qui exécute les instructions... du CPU.
> >
> > Les seuls programmes que j'ai pu écrire et qui contenaient des
> > instructions CPU étaient en assembleur.
>
> Non, tout les programmes utilisent les instructions CPU, c'est pas
> possible autrement.
La distinction que fait J.P., c'est entre l'assembleur, où l'auteur
utilise directement les instructions du processeur sous forme de
mnémoniques (c'est ce qu'il appelle « taper dans le matériel »), et les
langages de haut niveau où le source est traduit en langage machine par
le compilateur sans que l'auteur du programme sache quelles sont les
instructions CPU utilisées.
et encore moins quand le programme, le code que j'écris, une fois
compilé est lié à des bibliothèques dont on ne connait que les méthodes
d'entrées et sortie, rien de ce qui se passe dedans.
Et là on parle simple, car si on ajoute l'optimisation des compilateurs
pour le threading, le pipeling, le parallélisme etc. ce qui arrive au
CPU est totalement inconnu du programeur à moins de fouiller
l'éxécutable.
Et c'est probablement en faisant cela que les développeurs de Flash 13
ont découvert ces instructions incompatibles avec les iMac de ces séries
dont mon iMac7,1.
> J.P wrote: > > > > Rappellons que le CPU c'est ce qui exécute les instructions... du CPU. > > > > Les seuls programmes que j'ai pu écrire et qui contenaient des > > instructions CPU étaient en assembleur. > > Non, tout les programmes utilisent les instructions CPU, c'est pas > possible autrement.
La distinction que fait J.P., c'est entre l'assembleur, où l'auteur utilise directement les instructions du processeur sous forme de mnémoniques (c'est ce qu'il appelle « taper dans le matériel »), et les langages de haut niveau où le source est traduit en langage machine par le compilateur sans que l'auteur du programme sache quelles sont les instructions CPU utilisées.
et encore moins quand le programme, le code que j'écris, une fois compilé est lié à des bibliothèques dont on ne connait que les méthodes d'entrées et sortie, rien de ce qui se passe dedans. Et là on parle simple, car si on ajoute l'optimisation des compilateurs pour le threading, le pipeling, le parallélisme etc. ce qui arrive au CPU est totalement inconnu du programeur à moins de fouiller l'éxécutable. Et c'est probablement en faisant cela que les développeurs de Flash 13 ont découvert ces instructions incompatibles avec les iMac de ces séries dont mon iMac7,1.
