GNT sans publicité, site mobile, fonctionnalitées exclusives...

Rosetta et endianess?

Le
Saïd
Bonjour,

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)
Lire les 8 réponses

Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Saïd
Le #465519
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)


Patrick Stadelmann
Le #465517
In article Stephane Madrau
- 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
Le #465515
In article Stephane Madrau
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
Le #465514
Patrick Stadelmann
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
Le #465513
In article (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
Publicité
Suivre les réponses
Poster une réponse
Anonyme