Si j'ecris (mal) un programme en C. Ce programme accede a un entier 32 bits
en triturant ses octets (et donc en utilisant le fait que l'architecture de
la machine est (big ou little, je ne sais jamais)-endian. Je compile le
programme sur un mac PPC. Puis je lance le programme sur un mac a base
Intel.
1) Rosetta se lance-t-il pour interpreter le code? (Rosetta peut-il servir
pour les simples programmes en C qui ne sont pas dans un bundle .app,
j'imagine que oui)
2) Est-ce que le comportement du programme sera le meme que sur PPC? (en
gros, est-ce que les entiers sont stockee en memoire avec l'endianess PPC ou
Intel?)
--
Saïd.
"Bless this, O Lord, that with it thou mayst blow thine enemies to tiny
bits, in thy mercy."
In the Book of Armaments, Chapter 4. (The Holy Hand Grenade)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Saïd
Stephane Madrau :
2) Est-ce que le comportement du programme sera le meme que sur PPC? (en gros, est-ce que les entiers sont stockee en memoire avec l'endianess PPC ou Intel?)
Là, je suis certain que oui.
Ca signifie qu'a chaque acces a une donnees qui se trouve en memoire pour lui appliquer une operation, il doit y avoir une conversion big/little endian? Ca ne ralentit pas la machine (de beaucoup)?
exemple:
unsigned int a; char *c;
a=0xffffffff; c=(char *) &a; c[0]=0; /*selon l'endian du stockage de a en memoire, a vaut 0xffffff ou 0xffffff00 (256 fois plus!) */ a=a+a; /* si on veut que le comportement soit le meme, on doit fliper a avant de le transmettre au processeur et defliper le resultat avant de le sotcker a nouveau en memoire. */
-- Saïd. "Bless this, O Lord, that with it thou mayst blow thine enemies to tiny bits, in thy mercy." In the Book of Armaments, Chapter 4. (The Holy Hand Grenade)
Stephane Madrau :
2) Est-ce que le comportement du programme sera le meme que sur PPC? (en
gros, est-ce que les entiers sont stockee en memoire avec l'endianess PPC ou
Intel?)
Là, je suis certain que oui.
Ca signifie qu'a chaque acces a une donnees qui se trouve en memoire pour
lui appliquer une operation, il doit y avoir une conversion big/little
endian? Ca ne ralentit pas la machine (de beaucoup)?
exemple:
unsigned int a;
char *c;
a=0xffffffff;
c=(char *) &a;
c[0]=0; /*selon l'endian du stockage de a en memoire, a vaut 0xffffff
ou 0xffffff00 (256 fois plus!) */
a=a+a; /* si on veut que le comportement soit le meme, on doit fliper a
avant de le transmettre au processeur et defliper le resultat
avant de le sotcker a nouveau en memoire. */
--
Saïd.
"Bless this, O Lord, that with it thou mayst blow thine enemies to tiny
bits, in thy mercy."
In the Book of Armaments, Chapter 4. (The Holy Hand Grenade)
2) Est-ce que le comportement du programme sera le meme que sur PPC? (en gros, est-ce que les entiers sont stockee en memoire avec l'endianess PPC ou Intel?)
Là, je suis certain que oui.
Ca signifie qu'a chaque acces a une donnees qui se trouve en memoire pour lui appliquer une operation, il doit y avoir une conversion big/little endian? Ca ne ralentit pas la machine (de beaucoup)?
exemple:
unsigned int a; char *c;
a=0xffffffff; c=(char *) &a; c[0]=0; /*selon l'endian du stockage de a en memoire, a vaut 0xffffff ou 0xffffff00 (256 fois plus!) */ a=a+a; /* si on veut que le comportement soit le meme, on doit fliper a avant de le transmettre au processeur et defliper le resultat avant de le sotcker a nouveau en memoire. */
-- Saïd. "Bless this, O Lord, that with it thou mayst blow thine enemies to tiny bits, in thy mercy." In the Book of Armaments, Chapter 4. (The Holy Hand Grenade)
Patrick Stadelmann
In article <43c7a70f$0$31884$, Stephane Madrau wrote:
- est ce que en mémoire c'est stocké en big ou little ? A la limite on s'en fout, puisque cette partie de la mémoire ne sera accédée que par le process sous Rosetta; donc cela n'a même pas de sens de se demander la manière de stocker en mémoire.
C'est forcément en big-endian. Si une application écrit des longs sur 4 octets et relis des octets, le comportement est différent selon la manière dont les longs sont stockés en mémoire.
- est-ce qu'une partie de mémoire partagée est en little ou big ? Je suppose little car elle doit pouvoir être accédée nativement par les process natifs.
Quelle mémoire partagée ? Il est pratiquement impossible de partager de la mémoire entre les deux modes. C'est pour cela à mon avis qu'on ne peut pas par exemple appeler des plug-ins PowerPC depuis une application Intel (alors que c'était possible de le faire entre 680x0 et PowerPC).
Patrick -- Patrick Stadelmann
In article <43c7a70f$0$31884$636a15ce@news.free.fr>,
Stephane Madrau <stephane@madrau.com> wrote:
- est ce que en mémoire c'est stocké en big ou little ? A la limite on
s'en fout, puisque cette partie de la mémoire ne sera accédée que par le
process sous Rosetta; donc cela n'a même pas de sens de se demander la
manière de stocker en mémoire.
C'est forcément en big-endian. Si une application écrit des longs sur 4
octets et relis des octets, le comportement est différent selon la
manière dont les longs sont stockés en mémoire.
- est-ce qu'une partie de mémoire partagée est en little ou big ? Je
suppose little car elle doit pouvoir être accédée nativement par les
process natifs.
Quelle mémoire partagée ? Il est pratiquement impossible de partager de
la mémoire entre les deux modes. C'est pour cela à mon avis qu'on ne
peut pas par exemple appeler des plug-ins PowerPC depuis une application
Intel (alors que c'était possible de le faire entre 680x0 et PowerPC).
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <43c7a70f$0$31884$, Stephane Madrau wrote:
- est ce que en mémoire c'est stocké en big ou little ? A la limite on s'en fout, puisque cette partie de la mémoire ne sera accédée que par le process sous Rosetta; donc cela n'a même pas de sens de se demander la manière de stocker en mémoire.
C'est forcément en big-endian. Si une application écrit des longs sur 4 octets et relis des octets, le comportement est différent selon la manière dont les longs sont stockés en mémoire.
- est-ce qu'une partie de mémoire partagée est en little ou big ? Je suppose little car elle doit pouvoir être accédée nativement par les process natifs.
Quelle mémoire partagée ? Il est pratiquement impossible de partager de la mémoire entre les deux modes. C'est pour cela à mon avis qu'on ne peut pas par exemple appeler des plug-ins PowerPC depuis une application Intel (alors que c'était possible de le faire entre 680x0 et PowerPC).
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article <43c7c0b9$0$14989$, Stephane Madrau wrote:
Patrick Stadelmann wrote:
Quelle mémoire partagée ? Il est pratiquement impossible de partager de la mémoire entre les deux modes.
Il n'y a rien qui t'empêche de faire un programme qui utilise la mémoire partagée ou mappée (shm* ou mmap). Rien ne t'empêche ensuite de faire deux versions (PPC et i386) qui viendront accéder au même segment.
Là c'est un peu comme si tu écrivais dans un fichier sur un PC et le relisais sur un Mac : les applications doivent convenir d'un format d'échange. Moi je pensais à un passage de donnée entre 2 fonctions. Rosetta ne peut pas savoir si les octets passés sont des octets, des shorts, des longs... il lui est donc impossible de gérer le passage de manière transparente.
Que verra l'un et que verra l'autre des deux programmes ? Est ce que ça sera transparent pour l'application PPC dans Rosetta ?
Si du code dans Rosetta écrit des longs de 4 octet en mémoire, ils doivent absolument être stocké en big-endian, il n'y a pas le choix. Sinon une application qui par exemple ne lit que l'octet de poids fort pour savoir si le nombre est positif ou négatif ne fonctionnera pas car l'octet de poids fort ne sera pas au bon endroit.
Patrick -- Patrick Stadelmann
In article <43c7c0b9$0$14989$626a14ce@news.free.fr>,
Stephane Madrau <stephane@madrau.com> wrote:
Patrick Stadelmann wrote:
Quelle mémoire partagée ? Il est pratiquement impossible de partager de
la mémoire entre les deux modes.
Il n'y a rien qui t'empêche de faire un programme qui utilise la mémoire
partagée ou mappée (shm* ou mmap). Rien ne t'empêche ensuite de faire
deux versions (PPC et i386) qui viendront accéder au même segment.
Là c'est un peu comme si tu écrivais dans un fichier sur un PC et le
relisais sur un Mac : les applications doivent convenir d'un format
d'échange. Moi je pensais à un passage de donnée entre 2 fonctions.
Rosetta ne peut pas savoir si les octets passés sont des octets, des
shorts, des longs... il lui est donc impossible de gérer le passage de
manière transparente.
Que verra l'un et que verra l'autre des deux programmes ? Est ce que ça
sera transparent pour l'application PPC dans Rosetta ?
Si du code dans Rosetta écrit des longs de 4 octet en mémoire, ils
doivent absolument être stocké en big-endian, il n'y a pas le choix.
Sinon une application qui par exemple ne lit que l'octet de poids fort
pour savoir si le nombre est positif ou négatif ne fonctionnera pas car
l'octet de poids fort ne sera pas au bon endroit.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <43c7c0b9$0$14989$, Stephane Madrau wrote:
Patrick Stadelmann wrote:
Quelle mémoire partagée ? Il est pratiquement impossible de partager de la mémoire entre les deux modes.
Il n'y a rien qui t'empêche de faire un programme qui utilise la mémoire partagée ou mappée (shm* ou mmap). Rien ne t'empêche ensuite de faire deux versions (PPC et i386) qui viendront accéder au même segment.
Là c'est un peu comme si tu écrivais dans un fichier sur un PC et le relisais sur un Mac : les applications doivent convenir d'un format d'échange. Moi je pensais à un passage de donnée entre 2 fonctions. Rosetta ne peut pas savoir si les octets passés sont des octets, des shorts, des longs... il lui est donc impossible de gérer le passage de manière transparente.
Que verra l'un et que verra l'autre des deux programmes ? Est ce que ça sera transparent pour l'application PPC dans Rosetta ?
Si du code dans Rosetta écrit des longs de 4 octet en mémoire, ils doivent absolument être stocké en big-endian, il n'y a pas le choix. Sinon une application qui par exemple ne lit que l'octet de poids fort pour savoir si le nombre est positif ou négatif ne fonctionnera pas car l'octet de poids fort ne sera pas au bon endroit.
Patrick -- Patrick Stadelmann
stephane
Patrick Stadelmann wrote:
Il n'y a rien qui t'empêche de faire un programme qui utilise la mémoire partagée ou mappée (shm* ou mmap). Rien ne t'empêche ensuite de faire deux versions (PPC et i386) qui viendront accéder au même segment. Là c'est un peu comme si tu écrivais dans un fichier sur un PC et le
relisais sur un Mac : les applications doivent convenir d'un format d'échange.
ce qui veut dire qu'une mémoire partagée de ce tpe, écrite par un processus natif, et relue par un processus sous Rosetta devrait êrre swappée probablement. Et vice versa. Logique, sans aucun doute.
Ne ma^trisant pas beaucoup ce concept de mémoire partagée, il faudra que je teste les exemples de http://www.cs.cf.ac.uk/Dave/C/node27.html
Moi je pensais à un passage de donnée entre 2 fonctions. Rosetta ne peut pas savoir si les octets passés sont des octets, des shorts, des longs... il lui est donc impossible de gérer le passage de manière transparente.
ça on est bien d'accord.
Si du code dans Rosetta écrit des longs de 4 octet en mémoire, ils doivent absolument être stocké en big-endian, il n'y a pas le choix. Sinon une application qui par exemple ne lit que l'octet de poids fort pour savoir si le nombre est positif ou négatif ne fonctionnera pas car l'octet de poids fort ne sera pas au bon endroit.
ça me parait logique, oui.
-- Stéphane
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Il n'y a rien qui t'empêche de faire un programme qui utilise la mémoire
partagée ou mappée (shm* ou mmap). Rien ne t'empêche ensuite de faire
deux versions (PPC et i386) qui viendront accéder au même segment.
Là c'est un peu comme si tu écrivais dans un fichier sur un PC et le
relisais sur un Mac : les applications doivent convenir d'un format
d'échange.
ce qui veut dire qu'une mémoire partagée de ce tpe, écrite par un
processus natif, et relue par un processus sous Rosetta devrait êrre
swappée probablement. Et vice versa. Logique, sans aucun doute.
Ne ma^trisant pas beaucoup ce concept de mémoire partagée, il faudra que
je teste les exemples de http://www.cs.cf.ac.uk/Dave/C/node27.html
Moi je pensais à un passage de donnée entre 2 fonctions.
Rosetta ne peut pas savoir si les octets passés sont des octets, des
shorts, des longs... il lui est donc impossible de gérer le passage de
manière transparente.
ça on est bien d'accord.
Si du code dans Rosetta écrit des longs de 4 octet en mémoire, ils
doivent absolument être stocké en big-endian, il n'y a pas le choix.
Sinon une application qui par exemple ne lit que l'octet de poids fort
pour savoir si le nombre est positif ou négatif ne fonctionnera pas car
l'octet de poids fort ne sera pas au bon endroit.
Il n'y a rien qui t'empêche de faire un programme qui utilise la mémoire partagée ou mappée (shm* ou mmap). Rien ne t'empêche ensuite de faire deux versions (PPC et i386) qui viendront accéder au même segment. Là c'est un peu comme si tu écrivais dans un fichier sur un PC et le
relisais sur un Mac : les applications doivent convenir d'un format d'échange.
ce qui veut dire qu'une mémoire partagée de ce tpe, écrite par un processus natif, et relue par un processus sous Rosetta devrait êrre swappée probablement. Et vice versa. Logique, sans aucun doute.
Ne ma^trisant pas beaucoup ce concept de mémoire partagée, il faudra que je teste les exemples de http://www.cs.cf.ac.uk/Dave/C/node27.html
Moi je pensais à un passage de donnée entre 2 fonctions. Rosetta ne peut pas savoir si les octets passés sont des octets, des shorts, des longs... il lui est donc impossible de gérer le passage de manière transparente.
ça on est bien d'accord.
Si du code dans Rosetta écrit des longs de 4 octet en mémoire, ils doivent absolument être stocké en big-endian, il n'y a pas le choix. Sinon une application qui par exemple ne lit que l'octet de poids fort pour savoir si le nombre est positif ou négatif ne fonctionnera pas car l'octet de poids fort ne sera pas au bon endroit.
ça me parait logique, oui.
-- Stéphane
Patrick Stadelmann
In article <1h945kt.1jdj29310p56ryN%, (Stephane Madrau) wrote:
ce qui veut dire qu'une mémoire partagée de ce tpe, écrite par un processus natif, et relue par un processus sous Rosetta devrait êrre swappée probablement. Et vice versa. Logique, sans aucun doute.
Swappée si nécessaire par l'un des processus, le natif en toute logique, celui dans Rosetta n'étant même pas sensé savoir que Rosetta existe et qu'il communique avec un processus big-endian.
Patrick -- Patrick Stadelmann
In article <1h945kt.1jdj29310p56ryN%stephane@madrau.com>,
stephane@madrau.com (Stephane Madrau) wrote:
ce qui veut dire qu'une mémoire partagée de ce tpe, écrite par un
processus natif, et relue par un processus sous Rosetta devrait êrre
swappée probablement. Et vice versa. Logique, sans aucun doute.
Swappée si nécessaire par l'un des processus, le natif en toute logique,
celui dans Rosetta n'étant même pas sensé savoir que Rosetta existe et
qu'il communique avec un processus big-endian.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1h945kt.1jdj29310p56ryN%, (Stephane Madrau) wrote:
ce qui veut dire qu'une mémoire partagée de ce tpe, écrite par un processus natif, et relue par un processus sous Rosetta devrait êrre swappée probablement. Et vice versa. Logique, sans aucun doute.
Swappée si nécessaire par l'un des processus, le natif en toute logique, celui dans Rosetta n'étant même pas sensé savoir que Rosetta existe et qu'il communique avec un processus big-endian.
Patrick -- Patrick Stadelmann
stephane
Patrick Stadelmann wrote:
Swappée si nécessaire par l'un des processus, le natif en toute logique, celui dans Rosetta n'étant même pas sensé savoir que Rosetta existe et qu'il communique avec un processus big-endian.
En tous cas, après test, un processus natif qui écrit 0xDEADBEEF, un process sous Rosetta lit 0xefbeadde (pas certain de la valeur, mais en tous cas c'était swappé). C'est effectivement comme un fichier.
Qui l'a swappé, l'écriture ou la lecture ? comment est-il en mémoire ? Si c'est comme un fichier, alors on aura bien 0xef; 0xbe; 0xad; 0xde
Désolé si c'est trivial, pour moi ça va mieux en l'écrivant et en y réfléchissant
-- Stéphane
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Swappée si nécessaire par l'un des processus, le natif en toute logique,
celui dans Rosetta n'étant même pas sensé savoir que Rosetta existe et
qu'il communique avec un processus big-endian.
En tous cas, après test, un processus natif qui écrit 0xDEADBEEF, un
process sous Rosetta lit 0xefbeadde (pas certain de la valeur, mais en
tous cas c'était swappé). C'est effectivement comme un fichier.
Qui l'a swappé, l'écriture ou la lecture ? comment est-il en mémoire ?
Si c'est comme un fichier, alors on aura bien 0xef; 0xbe; 0xad; 0xde
Désolé si c'est trivial, pour moi ça va mieux en l'écrivant et en y
réfléchissant
Swappée si nécessaire par l'un des processus, le natif en toute logique, celui dans Rosetta n'étant même pas sensé savoir que Rosetta existe et qu'il communique avec un processus big-endian.
En tous cas, après test, un processus natif qui écrit 0xDEADBEEF, un process sous Rosetta lit 0xefbeadde (pas certain de la valeur, mais en tous cas c'était swappé). C'est effectivement comme un fichier.
Qui l'a swappé, l'écriture ou la lecture ? comment est-il en mémoire ? Si c'est comme un fichier, alors on aura bien 0xef; 0xbe; 0xad; 0xde
Désolé si c'est trivial, pour moi ça va mieux en l'écrivant et en y réfléchissant
-- Stéphane
Saïd
Stephane Madrau :
Patrick Stadelmann wrote:
Swappée si nécessaire par l'un des processus, le natif en toute logique, celui dans Rosetta n'étant même pas sensé savoir que Rosetta existe et qu'il communique avec un processus big-endian.
En tous cas, après test, un processus natif qui écrit 0xDEADBEEF, un process sous Rosetta lit 0xefbeadde (pas certain de la valeur, mais en tous cas c'était swappé). C'est effectivement comme un fichier.
Qui l'a swappé, l'écriture ou la lecture ? comment est-il en mémoire ? Si c'est comme un fichier, alors on aura bien 0xef; 0xbe; 0xad; 0xde
Personne ne l'a swappe, justement. Et personne d'autre que le programme PPC ne sait quelles portions de doivent etre swappees ou pas. Il n'y a que Rosetta qui peut decider, quand une operation est demande, de lire l'arguement en prenant en compte le fait qu'il est au format PPC.
-- Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser. Wer bleibt er? -- Heidegger
Stephane Madrau :
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
Swappée si nécessaire par l'un des processus, le natif en toute logique,
celui dans Rosetta n'étant même pas sensé savoir que Rosetta existe et
qu'il communique avec un processus big-endian.
En tous cas, après test, un processus natif qui écrit 0xDEADBEEF, un
process sous Rosetta lit 0xefbeadde (pas certain de la valeur, mais en
tous cas c'était swappé). C'est effectivement comme un fichier.
Qui l'a swappé, l'écriture ou la lecture ? comment est-il en mémoire ?
Si c'est comme un fichier, alors on aura bien 0xef; 0xbe; 0xad; 0xde
Personne ne l'a swappe, justement. Et personne d'autre que le programme
PPC ne sait quelles portions de doivent etre swappees ou pas. Il n'y a que
Rosetta qui peut decider, quand une operation est demande, de lire
l'arguement en prenant en compte le fait qu'il est au format PPC.
--
Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser.
Wer bleibt er? -- Heidegger
Swappée si nécessaire par l'un des processus, le natif en toute logique, celui dans Rosetta n'étant même pas sensé savoir que Rosetta existe et qu'il communique avec un processus big-endian.
En tous cas, après test, un processus natif qui écrit 0xDEADBEEF, un process sous Rosetta lit 0xefbeadde (pas certain de la valeur, mais en tous cas c'était swappé). C'est effectivement comme un fichier.
Qui l'a swappé, l'écriture ou la lecture ? comment est-il en mémoire ? Si c'est comme un fichier, alors on aura bien 0xef; 0xbe; 0xad; 0xde
Personne ne l'a swappe, justement. Et personne d'autre que le programme PPC ne sait quelles portions de doivent etre swappees ou pas. Il n'y a que Rosetta qui peut decider, quand une operation est demande, de lire l'arguement en prenant en compte le fait qu'il est au format PPC.
-- Sind zu sein und es seiend in einem Schiff. Fällt zu sein hat das Wasser. Wer bleibt er? -- Heidegger
stephane
Saïd wrote:
Personne ne l'a swappe, justement. Et personne d'autre que le programme PPC ne sait quelles portions de doivent etre swappees ou pas. Il n'y a que Rosetta qui peut decider, quand une operation est demande, de lire l'arguement en prenant en compte le fait qu'il est au format PPC.
Logique oui Le proc natif l'a stocké comme lui sait le faire, et le proc PPC l'a relu comme lui sait le faire, d'où le résultat. Effectivement, tout est limpide. Merci pour le brainstorming
-- Stephane
Saïd <said@brian.lan> wrote:
Personne ne l'a swappe, justement. Et personne d'autre que le programme
PPC ne sait quelles portions de doivent etre swappees ou pas. Il n'y a que
Rosetta qui peut decider, quand une operation est demande, de lire
l'arguement en prenant en compte le fait qu'il est au format PPC.
Logique oui Le proc natif l'a stocké comme lui sait le faire, et le proc
PPC l'a relu comme lui sait le faire, d'où le résultat.
Effectivement, tout est limpide. Merci pour le brainstorming
Personne ne l'a swappe, justement. Et personne d'autre que le programme PPC ne sait quelles portions de doivent etre swappees ou pas. Il n'y a que Rosetta qui peut decider, quand une operation est demande, de lire l'arguement en prenant en compte le fait qu'il est au format PPC.
Logique oui Le proc natif l'a stocké comme lui sait le faire, et le proc PPC l'a relu comme lui sait le faire, d'où le résultat. Effectivement, tout est limpide. Merci pour le brainstorming
