Salut,

Est-ce que vous savez s'il existe des wrappers vers les fonctions de
cryptographie (AES notamment pour le chiffrement symétrique et SHA-1
pour le hachage) d'OpenSSL, tous les wrappers que je connais (ICS,
Indy) ne wrappent que la partie "SSL" qui les intéresse et pas les
fonctions de crypto génériques.

Celui là : http://www.disi.unige.it/person/Ferr...delphiopenssl/

est trop ancien et n'intègre pas les fonctions AES/Rijndael

A vot' bon coeur m'sieur dames ;-)

Pierre

--
Pierre Y.

Pierre Y. a écrit :
> Salut,
>
> Est-ce que vous savez s'il existe des wrappers vers les fonctions de
> cryptographie (AES notamment pour le chiffrement symétrique et SHA-1 pour le
> hachage) d'OpenSSL, tous les wrappers que je connais (ICS, Indy) ne wrappent
> que la partie "SSL" qui les intéresse et pas les fonctions de crypto
> génériques.
>
> Celui là : http://www.disi.unige.it/person/Ferr...delphiopenssl/
>
> est trop ancien et n'intègre pas les fonctions AES/Rijndael
>
> A vot' bon coeur m'sieur dames ;-)
>
> Pierre

Ah, si je vous demande ça c'est que les implémentations de AES que
j'utilise (DCPCrypt v2 en l'occurence) n'est pas compatible avec la
version OpenSSL disponible sous Linux en Ruby (par exemple...)

--
Pierre Y.

> Est-ce que vous savez s'il existe des wrappers vers les fonctions de
> cryptographie (AES notamment pour le chiffrement symétrique et SHA-1 pour
> le hachage) d'OpenSSL, tous les wrappers que je connais (ICS, Indy) ne
> wrappent que la partie "SSL" qui les intéresse et pas les fonctions de
> crypto génériques.

ICS inclu une implémentation de SHA1.

--
francois.piette@overbyte.be
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be

Après mûre réflexion, Francois PIETTE [ICS-MidWare] a écrit :
>> Est-ce que vous savez s'il existe des wrappers vers les fonctions de
>> cryptographie (AES notamment pour le chiffrement symétrique et SHA-1 pour
>> le hachage) d'OpenSSL, tous les wrappers que je connais (ICS, Indy) ne
>> wrappent que la partie "SSL" qui les intéresse et pas les fonctions de
>> crypto génériques.
>
> ICS inclu une implémentation de SHA1.

Merci. Mais ce n'est pas SHA1 mon problème, c'est AES. Je n'arrive pas
à générer une clé AES compatible entre Ruby et Delphi.

--
Pierre Y.

> Merci. Mais ce n'est pas SHA1 mon problème, c'est AES. Je n'arrive pas à
> générer une clé AES compatible entre Ruby et Delphi.

Je ne connais pas spécifiquement AES, mais ton problème me semble bizarre.
Le standard c'est le standard et donc je ne vois pas trop le problème que tu
pourrais avoir si ce n'est la représentation - binaire, hexadécimale ou
autre - de la clé en question.

PS: Cherche toujours AES dans les sources de ICS-SSL car c'est bien possible
que quelqu'un l'ait implémenté !

--
francois.piette@overbyte.be
Auteur du freeware ICS - Internet Component Suite
Auteur du middleware multi-tiers MidWare
web: http://www.overbyte.be
blog: http://francois-piette.blogspot.com

Francois PIETTE [ICS-MidWare] a écrit :
>> Merci. Mais ce n'est pas SHA1 mon problème, c'est AES. Je n'arrive pas à
>> générer une clé AES compatible entre Ruby et Delphi.
>
> Je ne connais pas spécifiquement AES, mais ton problème me semble bizarre. Le
> standard c'est le standard et donc je ne vois pas trop le problème que tu
> pourrais avoir si ce n'est la représentation - binaire, hexadécimale ou autre
> - de la clé en question.

Il y a plusieurs manières d'obtenir une clé pour un algorithme
symétrique comme AES ou 3-DES.

Le plus sécurisé est HMAC + SHA1, HMAC crée un hash en remixant sur lui
même le résultat d'un hash sha1 d'un mot de passe éventuellement salé
(auquel on a ajouté devant ou derrière des données fixes qu'on oubliera
pas d'envoyer avec le contenu crypté de manière que la méthode de
génération du mot de passe côté client suive la même procédure : salage
du mot de passe et moulinette HMAC avec SHA-1)

Dans le cas d'AES, la clé attendue est de 128 bits, or SHA-1 génère des
hashes de 160 bits. Une des solutions consiste à ne prendre que les 16
premiers octets (128 bits) du hash SHA-1 généré.

Donc voilà... c'est pô si simple mon capitaine.

Ensuite il y a le problème du padding. Les algorithmes comme AES
travaillent sur blocs de taille constante. Si le dernier bloc à
chiffrer ne fait pas la bonne taille on ajoute un pattern d'octets
connus (que des $0 ou des $F$0 ou la taille du padding suivi de $80 ou
l'inverse...)

> PS: Cherche toujours AES dans les sources de ICS-SSL car c'est bien possible
> que quelqu'un l'ait implémenté !

J'ai cherché :-)

--
Pierre Y.

Salut,

Je pense que tu devrais trouver ton bonheur avec Synapse.
La partie cryptage est basée sur OpenSSL donc tu devrais pouvoir faire
tout ce que tu veux je pense.
Ce n'est pas VCL, dans le sens visuel, mais c'est pas important car
c'est vraiment la meilleure librairie de communication TCP/IP à mon goût.
En prime, tout est gratuit ;-)

http://synapse.ararat.cz/

Si tu utilise la vcl DCPCrypt celui ci ma posé ce genre de probleme avec
3DES les diverses implémentation dans d'autre langague étais incapable de
décrypter les donnés crypter avec cet librairie et vice versa
je n'ai pas trop compris pourquoi
j'ai utlisé l'api Wincrypt de microsoft pour pallier a ca c'est assez
chiant a utiliser mais au moins ca fonctionne
les headers correspondante pour l'api http://jedi-apilib.sourceforge.net/
Voila si tu trouve une autre librairie tu peux me dire



"Pierre Y." <pierre.y@gmail.com> a écrit dans le message de news:
mn.ec677d816338b536.63766@gmail.com...
> Francois PIETTE [ICS-MidWare] a écrit :
>>> Merci. Mais ce n'est pas SHA1 mon problème, c'est AES. Je n'arrive pas à
>>> générer une clé AES compatible entre Ruby et Delphi.
>>
>> Je ne connais pas spécifiquement AES, mais ton problème me semble
>> bizarre. Le standard c'est le standard et donc je ne vois pas trop le
>> problème que tu pourrais avoir si ce n'est la représentation - binaire,
>> hexadécimale ou autre - de la clé en question.
>
> Il y a plusieurs manières d'obtenir une clé pour un algorithme symétrique
> comme AES ou 3-DES.
>
> Le plus sécurisé est HMAC + SHA1, HMAC crée un hash en remixant sur lui
> même le résultat d'un hash sha1 d'un mot de passe éventuellement salé
> (auquel on a ajouté devant ou derrière des données fixes qu'on oubliera
> pas d'envoyer avec le contenu crypté de manière que la méthode de
> génération du mot de passe côté client suive la même procédure : salage du
> mot de passe et moulinette HMAC avec SHA-1)
>
> Dans le cas d'AES, la clé attendue est de 128 bits, or SHA-1 génère des
> hashes de 160 bits. Une des solutions consiste à ne prendre que les 16
> premiers octets (128 bits) du hash SHA-1 généré.
>
> Donc voilà... c'est pô si simple mon capitaine.
>
> Ensuite il y a le problème du padding. Les algorithmes comme AES
> travaillent sur blocs de taille constante. Si le dernier bloc à chiffrer
> ne fait pas la bonne taille on ajoute un pattern d'octets connus (que des
> $0 ou des $F$0 ou la taille du padding suivi de $80 ou l'inverse...)
>
>> PS: Cherche toujours AES dans les sources de ICS-SSL car c'est bien
>> possible que quelqu'un l'ait implémenté !
>
> J'ai cherché :-)
>
> --
> Pierre Y.
>
>

lolo avait écrit le 29/01/2008 :
> Salut,
>
> Je pense que tu devrais trouver ton bonheur avec Synapse.
> La partie cryptage est basée sur OpenSSL donc tu devrais pouvoir faire tout
> ce que tu veux je pense.
> Ce n'est pas VCL, dans le sens visuel, mais c'est pas important car c'est
> vraiment la meilleure librairie de communication TCP/IP à mon goût.
> En prime, tout est gratuit ;-)
>
> http://synapse.ararat.cz/

Oui, mais non ;-) Y'a pas les fonctions AES dans le wrapper OpenSSL de
synapse.

--
Pierre Y.

Après mûre réflexion, peter a écrit :
> Si tu utilise la vcl DCPCrypt celui ci ma posé ce genre de probleme avec
> 3DES les diverses implémentation dans d'autre langague étais incapable de
> décrypter les donnés crypter avec cet librairie et vice versa
> je n'ai pas trop compris pourquoi
> j'ai utlisé l'api Wincrypt de microsoft pour pallier a ca c'est assez chiant
> a utiliser mais au moins ca fonctionne
> les headers correspondante pour l'api http://jedi-apilib.sourceforge.net/
> Voila si tu trouve une autre librairie tu peux me dire

Il semblerait que le problème vienne de DCPCrypt qui ne pad pas
correctement le dernier bloc, donc il ne fait pas la bonne taille et
donc ça foire au décryptage avec les implémentations AES d'OpenSSL.

--
Pierre Y.

Pierre Y. a écrit :
>
> Oui, mais non ;-) Y'a pas les fonctions AES dans le wrapper OpenSSL de
> synapse.
>

Qu'appelles-tu wrapper OpenSSL ?

Bonjour,
Puis-je vous proposer de jeter un coup d'oeil sur :

http://home.netsurf.de/wolfgang.ehrhardt

Je ne sais pas si vous y trouverez votre bonheur, mais j'y ai trouvé le mien
dans les différentes
ressources mentionnées. Et ça marche, en particulier pour l'aes 256 bits en
bcb.
Ce n'est pas compliqué , j'ai compris l"aes en grande partie grâce aux codes
trouvés. Cela demande,
je ne vous le cache pas, *un peu * d'investissement intellectuel, et *
beaucoup * d'aspirine.
Digérer un tel travail, cela se mérite.
Si vous avez du mal à trouver ce qu'il vous faut, le zip de tous les sources
devrait peser environ 200 K,
je pourrai le joindre dans un courrier dans ce groupe si toutefois cela est
permis (taille etc ...).
Veuillez naturellement respecter l'auteur et ses droits si vous utilisez
l'implémentation qu'il a faite.
Sous D6, ça passe sans un seul warning et vous avez une petite dll qui vous
rendra les meilleurs services!

Maintenant transformer la chose en "wrapper" comme vous les souhaitez, ça,
ce sera votre petit défi !

Cordialement,

--
Phil



"Pierre Y." <pierre.y@gmail.com> a écrit dans le message de news:
mn.f26d7d81894ccb7d.63766@gmail.com...
> lolo avait écrit le 29/01/2008 :
>> Salut,
>>
>> Je pense que tu devrais trouver ton bonheur avec Synapse.
>> La partie cryptage est basée sur OpenSSL donc tu devrais pouvoir faire
>> tout ce que tu veux je pense.
>> Ce n'est pas VCL, dans le sens visuel, mais c'est pas important car c'est
>> vraiment la meilleure librairie de communication TCP/IP à mon goût.
>> En prime, tout est gratuit ;-)
>>
>> http://synapse.ararat.cz/
>
> Oui, mais non ;-) Y'a pas les fonctions AES dans le wrapper OpenSSL de
> synapse.
>
> --
> Pierre Y.
>
>

lolo a écrit :
> Qu'appelles-tu wrapper OpenSSL ?

le fait de déclarer en Delphi les fonctions et les imports de DLL
nécessaires à l'appel de fonctions dans les librairies SSL.

Pierre Y. a formulé ce mercredi :
> Après mûre réflexion, peter a écrit :
>> Si tu utilise la vcl DCPCrypt celui ci ma posé ce genre de probleme avec
>> 3DES les diverses implémentation dans d'autre langague étais incapable de
>> décrypter les donnés crypter avec cet librairie et vice versa
>> je n'ai pas trop compris pourquoi
>> j'ai utlisé l'api Wincrypt de microsoft pour pallier a ca c'est assez
>> chiant a utiliser mais au moins ca fonctionne
>> les headers correspondante pour l'api http://jedi-apilib.sourceforge.net/
>> Voila si tu trouve une autre librairie tu peux me dire
>
> Il semblerait que le problème vienne de DCPCrypt qui ne pad pas correctement
> le dernier bloc, donc il ne fait pas la bonne taille et donc ça foire au
> décryptage avec les implémentations AES d'OpenSSL.

Celui là fonctionne correctement et, niveaux performances, est pas loin
de 3x plus rapide que DCPCrypt.

http://home.netsurf.de/wolfgang.ehrhardt/index.html

Dans les unités Hash/CRC il y a HMAC.

--
Pierre Y.

sheep a pensé très fort :
> Bonjour,
> Puis-je vous proposer de jeter un coup d'oeil sur :
>
> http://home.netsurf.de/wolfgang.ehrhardt

Cette implémentation d'AES est compatible avec celle d'OpenSSL. C'est
celle là que j'ai choisi. Note que cette API est relativement simple à
utiliser (par rapport à celle d'OpenSSL par exemple...) et surtout très
très rapide.

--
Pierre Y.

C'est vrai.
On ne peut , en plus que sélectionner que les parties
qui sont intéressantes pour l'emploi envisagé,
car le découpage en units est très bien fait.

Perso, après avoir bien compris les mécanismes grâce à ce code, j'ai
fabriqué
ma propre implémentation où Delphi n'est que le squelette, le reste étant,
je vous le donne en 1000, ... en assembleur, avec du mmx et tout et tout.
Mais c'est du spécifique à mort pour un codec vidéo.
Cela n'a plus rien à voir avec le code de Mr ehrhardt, mais je lui dois un
grand
merci de m'avoir évité le syndrome de la page blanche.

Bonne utilisation P.Y.

--
Phil

"Pierre Y." <pierre.y@gmail.com> a écrit dans le message de news:
mn.fa9d7d8158694d06.63766@gmail.com...
> sheep a pensé très fort :
>> Bonjour,
>> Puis-je vous proposer de jeter un coup d'oeil sur :
>>
>> http://home.netsurf.de/wolfgang.ehrhardt
>
> Cette implémentation d'AES est compatible avec celle d'OpenSSL. C'est
> celle là que j'ai choisi. Note que cette API est relativement simple à
> utiliser (par rapport à celle d'OpenSSL par exemple...) et surtout très
> très rapide.
>
> --
> Pierre Y.
>
>

sheep a écrit :
> C'est vrai.
> On ne peut , en plus que sélectionner que les parties
> qui sont intéressantes pour l'emploi envisagé,
> car le découpage en units est très bien fait.
>
> Perso, après avoir bien compris les mécanismes grâce à ce code, j'ai
> fabriqué
> ma propre implémentation où Delphi n'est que le squelette, le reste étant,
> je vous le donne en 1000, ... en assembleur, avec du mmx et tout et tout.
> Mais c'est du spécifique à mort pour un codec vidéo.
> Cela n'a plus rien à voir avec le code de Mr ehrhardt, mais je lui dois un
> grand
> merci de m'avoir évité le syndrome de la page blanche.

Juste parce que j'aime bien ajouter des cheveux dans la soupe :-)

Est-ce que tu as jeté un oeil à l'implémentation proposée par le projet
FastCode ?

http://fastcode.sourceforge.net/
http://fastcode.sourceforge.net/chal...ntent/AES.html

Le code et les outils qui vont avec sont dans le zip là :
http://fastcode.sourceforge.net/Fast...ds/AESBV15.zip

Connaissant le projet FastCode ca doit être de l'assembleur pas piqué
des annetons là dedans.

@+

Pierre Y. a écrit :
> sheep a écrit :
>> C'est vrai.
>> On ne peut , en plus que sélectionner que les parties
>> qui sont intéressantes pour l'emploi envisagé,
>> car le découpage en units est très bien fait.
>>
>> Perso, après avoir bien compris les mécanismes grâce à ce code, j'ai
>> fabriqué
>> ma propre implémentation où Delphi n'est que le squelette, le reste
>> étant,
>> je vous le donne en 1000, ... en assembleur, avec du mmx et tout et tout.
>> Mais c'est du spécifique à mort pour un codec vidéo.
>> Cela n'a plus rien à voir avec le code de Mr ehrhardt, mais je lui
>> dois un grand
>> merci de m'avoir évité le syndrome de la page blanche.
>
> Juste parce que j'aime bien ajouter des cheveux dans la soupe :-)
>
> Est-ce que tu as jeté un oeil à l'implémentation proposée par le projet
> FastCode ?
>
> http://fastcode.sourceforge.net/
> http://fastcode.sourceforge.net/chal...ntent/AES.html
>
> Le code et les outils qui vont avec sont dans le zip là :
> http://fastcode.sourceforge.net/Fast...ds/AESBV15.zip
>
> Connaissant le projet FastCode ca doit être de l'assembleur pas piqué
> des annetons là dedans.
>
> @+

C'est amusant cette utilisation de l'assembleur à une époque où on ne
jure que par les sur-couches...

>> Connaissant le projet FastCode ca doit être de l'assembleur pas piqué
>> des annetons là dedans.
>>
> C'est amusant cette utilisation de l'assembleur à une époque où on ne
> jure que par les sur-couches...

Pour moi c'est comme de la plomberie, un métier inconnu dans lequel il
n'existe que des spécialistes, qui se perd et pour lequel il n'existera
bientôt plus de remplacants.

Donc je prend ça pour ce que c'est, une prouesse technologique sans même
ce petit quelque chose qui me titille le dessous de la curiosité et je
suis bien content que d'autres sachent le faire à ma place.

L'assembleur est un langage comme un autre.
Rien de mystique dans cette affaire.
Et en plus, cela permet de voir le génie du compilateur
en regard du code Delphi d'origine.
L'utilisation de composants tout faits ?
Oui, bien sûr, on ne va pas ré inventer la roue à chaque fois !
C'est vrai qu'aujourd'hui, on en est même plus là.
On dit ce qu'on veut de manière graphique, un générateur de code
pisse un machin qui est compilé ou interprété et roule.
.... Et quand ça merde, bonjour le déverminage !
Cela dit, dans certaines units Delphi (D6), il y a toujours de l'assembleur
(Ex : dans SysUtils, la procédure DivMod etc ...)

Bon , j'accepte d'être traité de dinosaure.

--
Phil




"Pierre Y." <pierre.y@gmail.com> a écrit dans le message de news:
fnum3i$47l$1@sd-6836.dedibox.fr...
>>> Connaissant le projet FastCode ca doit être de l'assembleur pas piqué
>>> des annetons là dedans.
>>>
>> C'est amusant cette utilisation de l'assembleur à une époque où on ne
>> jure que par les sur-couches...
>
> Pour moi c'est comme de la plomberie, un métier inconnu dans lequel il
> n'existe que des spécialistes, qui se perd et pour lequel il n'existera
> bientôt plus de remplacants.
>
> Donc je prend ça pour ce que c'est, une prouesse technologique sans même
> ce petit quelque chose qui me titille le dessous de la curiosité et je
> suis bien content que d'autres sachent le faire à ma place.

Pierre Y. a écrit :
> Pour moi c'est comme de la plomberie, un métier inconnu dans lequel il
> n'existe que des spécialistes, qui se perd et pour lequel il n'existera
> bientôt plus de remplacants.

ftp://download.intel.com/design/Pentium4/manuals

> Donc je prend ça pour ce que c'est, une prouesse technologique sans même
> ce petit quelque chose qui me titille le dessous de la curiosité et je
> suis bien content que d'autres sachent le faire à ma place.

pourtant t'as bien du faire des µP à l'IUT non?

Flo a écrit :
> Pierre Y. a écrit :
>> Pour moi c'est comme de la plomberie, un métier inconnu dans lequel il
>> n'existe que des spécialistes, qui se perd et pour lequel il
>> n'existera bientôt plus de remplacants.
>
> ftp://download.intel.com/design/Pentium4/manuals

Plus rien de neuf depuis le P4 ?

>> Donc je prend ça pour ce que c'est, une prouesse technologique sans
>> même ce petit quelque chose qui me titille le dessous de la curiosité
>> et je suis bien content que d'autres sachent le faire à ma place.
>
> pourtant t'as bien du faire des µP à l'IUT non?

Yep. Et ?

Je ne sais pas ce qu'il en est côté jeu d'instructions du CPU mais selon
moi, c'est plus intéressant de savoir optimiser l'utilisation de
multiples coeurs (et d'avoir des outils qui permettent de le faire au
niveau du langage) que de réimplémenter en moins bien les algorithmes
qui ont déjà été optimisés par d'autres.

sheep a écrit :
> L'assembleur est un langage comme un autre.

Euh, non. L'assembleur N'EST PAS un langage comme un autre. Aucun
langage n'est comme les autres d'ailleurs sinon on ne verrait pas autant
de code dégueulasse puisque tout le monde saurait maîtriser à la
perfection toutes les finesses de tous les langages.

> Rien de mystique dans cette affaire.

Rien de mystique si ce ne sont les communautés de "gourous", comme dans
tous les domaines de l'informatique. Gourous... Mysticisme... Bref.

> Et en plus, cela permet de voir le génie du compilateur
> en regard du code Delphi d'origine.

Le génie du mec qui a écrit le compilateur.

> L'utilisation de composants tout faits ?

J'ai du sauter une étape. Soit, les composants, moi ça me va tant que
c'est les autres qui les font ;-)

> Oui, bien sûr, on ne va pas ré inventer la roue à chaque fois !
> C'est vrai qu'aujourd'hui, on en est même plus là.
> On dit ce qu'on veut de manière graphique, un générateur de code
> pisse un machin qui est compilé ou interprété et roule.

Certains ont besoin que l'informatique devienne une activité productive,
comme dans l'industrie, on produit beaucoup avec une qualité constante,
une richesse fonctionnelle en constante augmentation avec le même nombre
de doigts et de cerveaux et le même nombre d'heures de sommeil.

> ... Et quand ça merde, bonjour le déverminage !

Les nouvelles méthodes de programmation (celles dont les utilisateurs de
Delphi n'ont jamais entendu parler en général) insistent sur l'écriture
de tests unitaires, tests d'intégration continue, tests de non
régression. Le tout autmatisé. Ca change la vie. D'ailleurs W.Ehrhardt
dispose dans ses librairies de tout un framework de test. C'est bien,
c'est un exemple à suivre. Sauf que ces exemples ne sont pas
automatisables. (Par automatisable j'entend qu'il existe quelque part un
truc qui fait un checkout des sources à chaque changement dans le
repository, compile, vérifie que ca a compilé correctement et lance le
framework de test d'intégration, de non régression... lorsque tout est
passé, il génère un snapshot des sources ou des exécutables pour les
tests manuels. Puis il averti les développeurs que les tests continuent
à passer.) A l'arrivée il y a plus de test que de code, mais...
finalement... n'y a-t-il pas, dans le wild wild world, plus de code qui
utilise un outil (compilateur, composant, framework, librairie...) que
de code dans l'outil lui même ?

Tenez, un truc m'a bluffé, je suis le projet Rubinius, une machine
virtuelle pour Ruby basée sur les concepts de SmallTalk, la crème de la
crème en matière de conception de machine virtuelle.

Le projet est géré par Lighthouse (une application de suivi de projet,
comme Mingle) et GIT (le SVN de Linus). A chaque commit, le code est
recompilé et les tests d'intégration sont lancés. Le résultat des tests
est posté sur le chan IRC de #rubinius sur FreeNode.

C'est rigolo à voir, les développeurs causent des problèmes qu'ils
rencontrent, et de temps en temps on voit les messages des bots qui
observent les commits, réalisent les tests et postent les résultats.

Les tests dans rubinius sont basés sur rspec, un framework de tests
écrit en Ruby qui permet de décrire un test comme une histoire, un
scénario en somme et sont la synthèse de tous les tests existants dans
la machine virtuelle Ruby de référence (MRI : Matz Ruby Interpreter) et
de ceux du projet JRuby (un interpréteur Ruby pour la JVM qui garantit
l'intéropérabilité des classes Ruby avec le code Java et vice versa)

> Cela dit, dans certaines units Delphi (D6), il y a toujours de l'assembleur
> (Ex : dans SysUtils, la procédure DivMod etc ...)

Oui et dans D2006/D2007 il y en a encore plus : le gestionnaire de
mémoire et toutes les fonctions de traitement sur les chaînes réalisées
par les membres du projet... FastCode.

> Bon , j'accepte d'être traité de dinosaure.

Je dis que je suis incapable de faire ce que tu as fait, que je n'en
éprouve pas le besoin et que je suis content que des gens comme toi
sachent le faire. Je ne te "traite" pas de dinosaure.

Finalement, toute cette discussion pour en arriver où ? Habituellement
c'est le djob de Merlin, François et Jean de philosopher sur le boulot
de développeur et sur les avantages et les inconvénients des langages...

@+

PS : J'accepte d'être traîté de con s'il le faut.

Pierre Y. a écrit :
> Plus rien de neuf depuis le P4 ?

ils ont fait n'importe quoi dans la gestion de leurs docs, bilan le
répertoire du Pentium4 a servi à spécifier tous les core actuels. Mais
ils ont l'air de mettre leurs docs maintenant dans:
ftp://download.intel.com/design/processor
mais y a d'autres fichiers plus à jour sur le site oueb.

> Je ne sais pas ce qu'il en est côté jeu d'instructions du CPU mais selon
> moi, c'est plus intéressant de savoir optimiser l'utilisation de
> multiples coeurs (et d'avoir des outils qui permettent de le faire au
> niveau du langage) que de réimplémenter en moins bien les algorithmes
> qui ont déjà été optimisés par d'autres.

parfaitement d'accord, mais ma remarque était plus à l'origine sur le
sens mystique, il n'y a rien de sorcier dans l'assembleur pour x86/x64,
ce ne sont que quelques milliers de pages de documentation.

- Florent

Le plus difficile, maintenant, c'est effectivement le multi coeur.
Ce n'étais déjà pas facile d'organiser les instructions pour éviter
les ruptures de flux d'instruction et aller dans le sens de la prédiction,
mais avec 2 coeurs, là ... Je ne sais pas si un compilateur saura
un jour en tirer parti ...
Quant aux évolutions depuis le p4, j'aurais bien aimé pouvoir faire avec la
partie
haute des registres ce qu'on ne peut faire qu'avec la partie basse.
Actuellement, des registres à 64 bits, ça aide, mais à moins de travailler
en décalage...
Et puis ce cache qu'on ne maîtrise toujours pas ! (le proc peut "décider" de
ne pas
cacher ce qu'on lui demande de cacher en L1 ou L2).
Quant aux milliers de pages, ça vient peu à peu. Il y a beaucoup de redites
et même des choses que je ne trouve pas vraies en pratique, sur les boucles
ou
sur l'alignement en mémoire. Je n'y croyais pas moi même. Et pourtant.
Par exemple, travailler avec un tableau d'integers (donc bien alignés en
mémoire)
dont chaque élément a une valeur est comprise entre 0 et 255 est plus lent
que travailler sur un tableau de bytes (dont 3 éléments sur 4 ne sont pas
alignés en mémoire).
Tout s'explique, évidemment ...

--
Phil


"Flo" <flouc@laposte.net> a écrit dans le message de news:
fo29f9$sa4$1@sd-6836.dedibox.fr...
> Pierre Y. a écrit :
>> Plus rien de neuf depuis le P4 ?
>
> ils ont fait n'importe quoi dans la gestion de leurs docs, bilan le
> répertoire du Pentium4 a servi à spécifier tous les core actuels. Mais ils
> ont l'air de mettre leurs docs maintenant dans:
> ftp://download.intel.com/design/processor
> mais y a d'autres fichiers plus à jour sur le site oueb.
>
>> Je ne sais pas ce qu'il en est côté jeu d'instructions du CPU mais selon
>> moi, c'est plus intéressant de savoir optimiser l'utilisation de
>> multiples coeurs (et d'avoir des outils qui permettent de le faire au
>> niveau du langage) que de réimplémenter en moins bien les algorithmes qui
>> ont déjà été optimisés par d'autres.
>
> parfaitement d'accord, mais ma remarque était plus à l'origine sur le sens
> mystique, il n'y a rien de sorcier dans l'assembleur pour x86/x64, ce ne
> sont que quelques milliers de pages de documentation.
>
> - Florent