Grrrr wrote:On Fri, 10 Jun 2005 12:09:19 +0200, Patrick Stadelmann wrote:Même avec du bête code algorithmique, le passage de PC à Mac n'est pas
toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il
fonctionne correctement, ça n'est pas immédiat.
Il n'est pas si difficile de faire du code portable et utilisable pour
toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex).
Les problèmes se situent généralement dans le noyau et la libc.
Pour le reste, si on code pas trop crade, il suffit généralement de
recompiler.
Tu oublies deux choses :
- les programmes évolués faisant beaucoup de traitement de signal (son
ou image) utilisent les instructions Altivec / SSE spécifiquent aux
processeurs PPC / x86. Aucun langage à ma connaissance ne propose de
système générique pour utiliser ces instructions, il est donc nécessaire
d'utiliser des extensions pour se servir des ces instructions. Et bien
sûr ses extensions sont différentes pour altivec et sse et sont non
facilement convertibles de l'un dans l'autre.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
Grrrr <Grrr@Grrr.org.invalid> wrote:
On Fri, 10 Jun 2005 12:09:19 +0200, Patrick Stadelmann wrote:
Même avec du bête code algorithmique, le passage de PC à Mac n'est pas
toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il
fonctionne correctement, ça n'est pas immédiat.
Il n'est pas si difficile de faire du code portable et utilisable pour
toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex).
Les problèmes se situent généralement dans le noyau et la libc.
Pour le reste, si on code pas trop crade, il suffit généralement de
recompiler.
Tu oublies deux choses :
- les programmes évolués faisant beaucoup de traitement de signal (son
ou image) utilisent les instructions Altivec / SSE spécifiquent aux
processeurs PPC / x86. Aucun langage à ma connaissance ne propose de
système générique pour utiliser ces instructions, il est donc nécessaire
d'utiliser des extensions pour se servir des ces instructions. Et bien
sûr ses extensions sont différentes pour altivec et sse et sont non
facilement convertibles de l'un dans l'autre.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
Grrrr wrote:On Fri, 10 Jun 2005 12:09:19 +0200, Patrick Stadelmann wrote:Même avec du bête code algorithmique, le passage de PC à Mac n'est pas
toujours évident. Compiler le soft c'est une chose, encore faut-il qu'il
fonctionne correctement, ça n'est pas immédiat.
Il n'est pas si difficile de faire du code portable et utilisable pour
toutes les architectures communes (x86, PPC, ARM, MIPS, sh, par ex).
Les problèmes se situent généralement dans le noyau et la libc.
Pour le reste, si on code pas trop crade, il suffit généralement de
recompiler.
Tu oublies deux choses :
- les programmes évolués faisant beaucoup de traitement de signal (son
ou image) utilisent les instructions Altivec / SSE spécifiquent aux
processeurs PPC / x86. Aucun langage à ma connaissance ne propose de
système générique pour utiliser ces instructions, il est donc nécessaire
d'utiliser des extensions pour se servir des ces instructions. Et bien
sûr ses extensions sont différentes pour altivec et sse et sont non
facilement convertibles de l'un dans l'autre.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
On Mon, 13 Jun 2005 00:52:06 +0200, Schmurtz wrote:- les programmes évolués faisant beaucoup de traitement de signal (son
ou image) utilisent les instructions Altivec / SSE spécifiquent aux
processeurs PPC / x86. Aucun langage à ma connaissance ne propose de
système générique pour utiliser ces instructions, il est donc nécessaire
d'utiliser des extensions pour se servir des ces instructions. Et bien
sûr ses extensions sont différentes pour altivec et sse et sont non
facilement convertibles de l'un dans l'autre.
Les principes de base du SSE et de l'altivec sont les mêmes. Il est
trivial de faire une librairie fournissant toutes les fonctions de bases
en C. Au final, ça donne un fichier pour SSE, un pour Altivec, de
quelques centaines de lignes chacun: grosso modo, 4 lignes par
instruction de base + 1 commentaire. Avec 2 à 300 instructions de bases,
ça donne un fichier d'environ 1000 lignes, aisément portable en quelques
heures, y compris sur un CPU qui n'a pas d'instruction SIMD:
l'implémentation en C sera plus grosse et plus lente, mais pas plus dur
à écrire.
Tout le reste du code doit être en C et n'a pas besoin d'être porté,
juste recompilé.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
Sur du code écrit correctement, le plus dur c'est de mettre les bons
#define dans le code pour compiler dans la bonne endianness.
Bien sur, si tu as des centaines de milliers de lignes de code écrit
comme un cochon et complètement dépendant de l'endianness, tu as plus
vite fait de tout jeter et tout ré-écrire. Mais depuis le temps que ces
problèmes se posent (déjà au début des années 80 !), il faut espérer
qu'aucun programme sérieux n'est dans ce cas.
On Mon, 13 Jun 2005 00:52:06 +0200, Schmurtz wrote:
- les programmes évolués faisant beaucoup de traitement de signal (son
ou image) utilisent les instructions Altivec / SSE spécifiquent aux
processeurs PPC / x86. Aucun langage à ma connaissance ne propose de
système générique pour utiliser ces instructions, il est donc nécessaire
d'utiliser des extensions pour se servir des ces instructions. Et bien
sûr ses extensions sont différentes pour altivec et sse et sont non
facilement convertibles de l'un dans l'autre.
Les principes de base du SSE et de l'altivec sont les mêmes. Il est
trivial de faire une librairie fournissant toutes les fonctions de bases
en C. Au final, ça donne un fichier pour SSE, un pour Altivec, de
quelques centaines de lignes chacun: grosso modo, 4 lignes par
instruction de base + 1 commentaire. Avec 2 à 300 instructions de bases,
ça donne un fichier d'environ 1000 lignes, aisément portable en quelques
heures, y compris sur un CPU qui n'a pas d'instruction SIMD:
l'implémentation en C sera plus grosse et plus lente, mais pas plus dur
à écrire.
Tout le reste du code doit être en C et n'a pas besoin d'être porté,
juste recompilé.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
Sur du code écrit correctement, le plus dur c'est de mettre les bons
#define dans le code pour compiler dans la bonne endianness.
Bien sur, si tu as des centaines de milliers de lignes de code écrit
comme un cochon et complètement dépendant de l'endianness, tu as plus
vite fait de tout jeter et tout ré-écrire. Mais depuis le temps que ces
problèmes se posent (déjà au début des années 80 !), il faut espérer
qu'aucun programme sérieux n'est dans ce cas.
On Mon, 13 Jun 2005 00:52:06 +0200, Schmurtz wrote:- les programmes évolués faisant beaucoup de traitement de signal (son
ou image) utilisent les instructions Altivec / SSE spécifiquent aux
processeurs PPC / x86. Aucun langage à ma connaissance ne propose de
système générique pour utiliser ces instructions, il est donc nécessaire
d'utiliser des extensions pour se servir des ces instructions. Et bien
sûr ses extensions sont différentes pour altivec et sse et sont non
facilement convertibles de l'un dans l'autre.
Les principes de base du SSE et de l'altivec sont les mêmes. Il est
trivial de faire une librairie fournissant toutes les fonctions de bases
en C. Au final, ça donne un fichier pour SSE, un pour Altivec, de
quelques centaines de lignes chacun: grosso modo, 4 lignes par
instruction de base + 1 commentaire. Avec 2 à 300 instructions de bases,
ça donne un fichier d'environ 1000 lignes, aisément portable en quelques
heures, y compris sur un CPU qui n'a pas d'instruction SIMD:
l'implémentation en C sera plus grosse et plus lente, mais pas plus dur
à écrire.
Tout le reste du code doit être en C et n'a pas besoin d'être porté,
juste recompilé.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
Sur du code écrit correctement, le plus dur c'est de mettre les bons
#define dans le code pour compiler dans la bonne endianness.
Bien sur, si tu as des centaines de milliers de lignes de code écrit
comme un cochon et complètement dépendant de l'endianness, tu as plus
vite fait de tout jeter et tout ré-écrire. Mais depuis le temps que ces
problèmes se posent (déjà au début des années 80 !), il faut espérer
qu'aucun programme sérieux n'est dans ce cas.
Saïd wrote:C'est que le programme est mal ecrit. Ca rentre dans la categorie du code
crade. En C++ il suffit de faire v >> file; pour ecrire proprement et
portablement. En tout cas c'est un zélote de C++ qui m'a explique ca.
Perso, je reste au C (dans l'espoir d'etre immortel->signature ;-) ).
T'an connais beaucoup des gens qui utilisent les libs standards c++ à
chaque fois qu'ils ont besoin de sérialiser des données ?
Saïd <said@brian.lan> wrote:
C'est que le programme est mal ecrit. Ca rentre dans la categorie du code
crade. En C++ il suffit de faire v >> file; pour ecrire proprement et
portablement. En tout cas c'est un zélote de C++ qui m'a explique ca.
Perso, je reste au C (dans l'espoir d'etre immortel->signature ;-) ).
T'an connais beaucoup des gens qui utilisent les libs standards c++ à
chaque fois qu'ils ont besoin de sérialiser des données ?
Saïd wrote:C'est que le programme est mal ecrit. Ca rentre dans la categorie du code
crade. En C++ il suffit de faire v >> file; pour ecrire proprement et
portablement. En tout cas c'est un zélote de C++ qui m'a explique ca.
Perso, je reste au C (dans l'espoir d'etre immortel->signature ;-) ).
T'an connais beaucoup des gens qui utilisent les libs standards c++ à
chaque fois qu'ils ont besoin de sérialiser des données ?
- les programmes évolués faisant beaucoup de traitement de signal (son
ou image) utilisent les instructions Altivec / SSE spécifiquent aux
processeurs PPC / x86. Aucun langage à ma connaissance ne propose de
système générique pour utiliser ces instructions,
il est donc nécessaire
d'utiliser des extensions pour se servir des ces instructions. Et bien
sûr ses extensions sont différentes pour altivec et sse et sont non
facilement convertibles de l'un dans l'autre.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
- les programmes évolués faisant beaucoup de traitement de signal (son
ou image) utilisent les instructions Altivec / SSE spécifiquent aux
processeurs PPC / x86. Aucun langage à ma connaissance ne propose de
système générique pour utiliser ces instructions,
il est donc nécessaire
d'utiliser des extensions pour se servir des ces instructions. Et bien
sûr ses extensions sont différentes pour altivec et sse et sont non
facilement convertibles de l'un dans l'autre.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
- les programmes évolués faisant beaucoup de traitement de signal (son
ou image) utilisent les instructions Altivec / SSE spécifiquent aux
processeurs PPC / x86. Aucun langage à ma connaissance ne propose de
système générique pour utiliser ces instructions,
il est donc nécessaire
d'utiliser des extensions pour se servir des ces instructions. Et bien
sûr ses extensions sont différentes pour altivec et sse et sont non
facilement convertibles de l'un dans l'autre.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
Grrrr wrote:On Mon, 13 Jun 2005 00:52:06 +0200, Schmurtz wrote:- les programmes évolués faisant beaucoup de traitement de signal (son
ou image) utilisent les instructions Altivec / SSE spécifiquent aux
processeurs PPC / x86. Aucun langage à ma connaissance ne propose de
système générique pour utiliser ces instructions, il est donc nécessaire
d'utiliser des extensions pour se servir des ces instructions. Et bien
sûr ses extensions sont différentes pour altivec et sse et sont non
facilement convertibles de l'un dans l'autre.
Les principes de base du SSE et de l'altivec sont les mêmes. Il est
trivial de faire une librairie fournissant toutes les fonctions de bases
en C. Au final, ça donne un fichier pour SSE, un pour Altivec, de
quelques centaines de lignes chacun: grosso modo, 4 lignes par
instruction de base + 1 commentaire. Avec 2 à 300 instructions de bases,
ça donne un fichier d'environ 1000 lignes, aisément portable en quelques
heures, y compris sur un CPU qui n'a pas d'instruction SIMD:
l'implémentation en C sera plus grosse et plus lente, mais pas plus dur
à écrire.
Tout le reste du code doit être en C et n'a pas besoin d'être porté,
juste recompilé.
Ce que tu dis est vrai, mais je pense qu'il existe des programmes
utilisant altivec dont il faudra réécrire toutes ces fonctions pour
utiliser sse à la place. Ce que tu dis est vrai, mais suppose d'avoir
conçu la chose proprement au début, ce qui n'est malheureusement pas
toujours le cas.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
Sur du code écrit correctement, le plus dur c'est de mettre les bons
#define dans le code pour compiler dans la bonne endianness.
Sur un programme de 100000 lignes ça prend du temps...
Grrrr <Grrr@Grrr.org.invalid> wrote:
On Mon, 13 Jun 2005 00:52:06 +0200, Schmurtz wrote:
- les programmes évolués faisant beaucoup de traitement de signal (son
ou image) utilisent les instructions Altivec / SSE spécifiquent aux
processeurs PPC / x86. Aucun langage à ma connaissance ne propose de
système générique pour utiliser ces instructions, il est donc nécessaire
d'utiliser des extensions pour se servir des ces instructions. Et bien
sûr ses extensions sont différentes pour altivec et sse et sont non
facilement convertibles de l'un dans l'autre.
Les principes de base du SSE et de l'altivec sont les mêmes. Il est
trivial de faire une librairie fournissant toutes les fonctions de bases
en C. Au final, ça donne un fichier pour SSE, un pour Altivec, de
quelques centaines de lignes chacun: grosso modo, 4 lignes par
instruction de base + 1 commentaire. Avec 2 à 300 instructions de bases,
ça donne un fichier d'environ 1000 lignes, aisément portable en quelques
heures, y compris sur un CPU qui n'a pas d'instruction SIMD:
l'implémentation en C sera plus grosse et plus lente, mais pas plus dur
à écrire.
Tout le reste du code doit être en C et n'a pas besoin d'être porté,
juste recompilé.
Ce que tu dis est vrai, mais je pense qu'il existe des programmes
utilisant altivec dont il faudra réécrire toutes ces fonctions pour
utiliser sse à la place. Ce que tu dis est vrai, mais suppose d'avoir
conçu la chose proprement au début, ce qui n'est malheureusement pas
toujours le cas.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
Sur du code écrit correctement, le plus dur c'est de mettre les bons
#define dans le code pour compiler dans la bonne endianness.
Sur un programme de 100000 lignes ça prend du temps...
Grrrr wrote:On Mon, 13 Jun 2005 00:52:06 +0200, Schmurtz wrote:- les programmes évolués faisant beaucoup de traitement de signal (son
ou image) utilisent les instructions Altivec / SSE spécifiquent aux
processeurs PPC / x86. Aucun langage à ma connaissance ne propose de
système générique pour utiliser ces instructions, il est donc nécessaire
d'utiliser des extensions pour se servir des ces instructions. Et bien
sûr ses extensions sont différentes pour altivec et sse et sont non
facilement convertibles de l'un dans l'autre.
Les principes de base du SSE et de l'altivec sont les mêmes. Il est
trivial de faire une librairie fournissant toutes les fonctions de bases
en C. Au final, ça donne un fichier pour SSE, un pour Altivec, de
quelques centaines de lignes chacun: grosso modo, 4 lignes par
instruction de base + 1 commentaire. Avec 2 à 300 instructions de bases,
ça donne un fichier d'environ 1000 lignes, aisément portable en quelques
heures, y compris sur un CPU qui n'a pas d'instruction SIMD:
l'implémentation en C sera plus grosse et plus lente, mais pas plus dur
à écrire.
Tout le reste du code doit être en C et n'a pas besoin d'être porté,
juste recompilé.
Ce que tu dis est vrai, mais je pense qu'il existe des programmes
utilisant altivec dont il faudra réécrire toutes ces fonctions pour
utiliser sse à la place. Ce que tu dis est vrai, mais suppose d'avoir
conçu la chose proprement au début, ce qui n'est malheureusement pas
toujours le cas.
- les PPC sont des processeurs big endian et les x86 sont little endian.
Ça veux dire en gros que si un programme compilé pour PPC écrit
0x12345678 dans un fichier, le même programme compilé pour x86 lisant le
fichier créer par sa version PPC lira 0x78563412. C'est trivial à
résoudre en théorie, mais dans la pratique c'est beaucoup plus compliqué
(il y a des milliers de lignes de code à modifier).
Sur du code écrit correctement, le plus dur c'est de mettre les bons
#define dans le code pour compiler dans la bonne endianness.
Sur un programme de 100000 lignes ça prend du temps...
