Discussion :

[rt15]

Re-bonjour,
... j'avais bien cité deux *.exe distincts.
... l'exe 64 bits appelle l'exe 32 bits avec ShellExecute en lui transmettant les paramètres pour les calculs : jusqu'ici pas de problème (j'ai testé avec deux exe 32 bits) par contre je n'ai pas encore trouvé la manip pour récupérer le résultat du calcul de l'"esclave" par l'appli-"maître" sans passer par le presse-papier.
Comme la source de l'"esclave" est un *.dpr qui commence par :
programme VaCalculer(input,output);
je ne parviens pas à récupérer le "output" pour l'envoyer en retour à l'appli-maître. (je n'ai jamais travaillé en mode console).

Tu as tous les mécanismes IPC (Inter Process Communication) pour récupérer l'output. Il y a les pipes, les mémoires partagées, les messages...
Si tu veux te prendre la tête avec les technos M$, tu peux aussi faire un serveur COM 32 bits qui sera utilisé par ton appli 64 bits.
Il y a aussi des méthodes plus crades genre Read/WriteProcessMemory ou encore passer par un fichier...

[edit]
Forcément, il y a une perte de performance importante dans l'échange par rapport à un appel de fonction. Mais il n'y a pas de solution (Connue...) pour exécuter du code 32 bits dans un processus 64 bits.

[tourlourou]

Bonjour René et Gilbert.

L'asm n'est pas mort, on dirait !

Avec des perspectives intéressantes, même si le multi-(toti ?)-plateformes est le Graal...

[CapJack]

par contre je n'ai pas encore trouvé la manip pour récupérer le résultat du calcul de l'"esclave" par l'appli-"maître"

Utiliser les primitives des protocoles DDE et COM ? Ça marche même entre un exe et une dll, j'ai pas testé entre deux dll. Pas besoin du presse-papier, c'est une zone de mémoire partagée entre deux processus.

Mots clefs de départ :
CreateFileMapping();
OpenFileMapping();
MapViewOfFile();
UnmapViewOfFile();

Tout est sur msdn.

[rt15]

Le lien vers la source n'est pas bon.
Le bon lien est le suivant :
http://www.jcolibri.com/articles/del...elphi_xe2.html

[John Colibri]

notre présentation Delphi XE2 - Delphi 2012 ("plus technique" que la petite intro ci dessus que j'avais envoyé à Gordon Fowler ce matin)

http://www.jcolibri.com/articles/del...elphi_xe2.html

a été mise à jour avec les nouvelles informations sur les Proxy Connectors pour Android, BlackBerry, Windows Phone 7 et Ios. Avec les liens correspondant à ces informations.

D'autres informations devraient tomber après l'annonce officielle, et je continuerai à mettre à jour l'article. "Stay tuned"

Merci aussi à "rt5" pour avoir signalé que le lien "source" du début de page vers notre article est incorrect. Je mentionnerais aussi que les références à Pascalissime (où je n'étais d'ailleurs pas le seul à publier) me sont allées droit au coeur.

John COLIBRI
jcolibri@jcolibri.com

[Gilbert Geyer]

Bonjour,

A Rekin85 : merci René pour ta réponse. Et comme tu dis :

Mais attention elles ne tourneront que sur du 64 bits et le nombre de machines concernées est petit en regard de tout ce qui tourne encore sur du 32.

... il n'y a pas le feu au lac : les NewGint et NewGCent ont encore du temps devant elles.

A Rt15 et à CapJack à propos de la récupération de l'output.
... Merci beaucoup pour vos pistes de résolution.
... Mais je dois vous dire que mon idée est carrément idiote pour la raison suivante : Utiliser un *.exe 64 bits qui lance un *.exe 32 bits truffé d'Asm+Pascal pour lui faire-faire les calculs et renvoyer le résultat à l'exe 64 bits ... à qui il ne reste plus qu'à afficher le résultat du calcul ... donc autant se passer de l'exe 64 bits et faire afficher le résultat directement par l'exe 32 bits. Faut savoir que le cas qui me préoccupe concerne des calculs effectués par les Unités NewGint et NewGcent précitées et qui renvoient des résultats de calcul dont le nombre de digits n'est limité que par la taille d'une string donc limité par la mem-vive disponible ... donc des résultats de calcul avec lesquels l'exe 64 bits ne pourrait évidemment faire rien d'autre que de les afficher.

A J. Colibri : Mon attention a été attirée par :

2.4 - Migration 64 bits Delphi: les points à surveiller
...
... inclusion de blocs assembleur:
- il n'est plus permis de mélanger des blocs Asm avec des instructions Pascal // ça à été déjà cité par Sjrd mais pas la suite :
- seules les procédures ayant l'attribut Asm sont possibles

... compte tenu de ceci je pense qu'on peut en déduire que sous XE2 il est possible d'avoir dans la même unité des procédures et des fonctions qui depuis l'attribut Asm jusqu'au end final sont totalement en Asm et d'autres qui depuis le premier begin jusqu'au dernier end sont entièrement en Pascal. Oui/Non ?

Si Oui il n'y a plus raison de s'affoler vu qu'une routine en Asm peut être appelée par une autre en Pascal et inversement.

A+.

[tourlourou]

Il est effectivement probable que seul le mix soit interdit.

Quid alors d'une procédure pascal qui appelle une procédure inline en asm ? Cas un peu tiré par les cheveux, pê, et qui ne pose pas forcément plus de problème...

[Gilbert Geyer]

Bonjour Tourlourou,

Il est effectivement probable que seul le mix soit interdit.

... si on prend chaque mot à la lettre cela devrait être le cas.
... mais une bonne confirmation serait rassurante.

Quid alors d'une procédure pascal qui appelle une procédure inline en asm ? Cas un peu tiré par les cheveux, pê, et qui ne pose pas forcément plus de problème...

... ça c'est vite dit car le problème sera de savoir tricoter du code Asm-64bits
... demandes donc à René ce qu'il en pense.

A+.

[guillemouze]

Quid alors d'une procédure pascal qui appelle une procédure inline en asm ? Cas un peu tiré par les cheveux, pê, et qui ne pose pas forcément plus de problème...

A priori, une procedure inline est equivalente a faire un $include ou a recopier le contenu à l'endroit de l'appel -> donc mix impossible ... mais ce n'est qu'une impression

[Rekin85]

Bonjour les amis

... ça c'est vite dit car le problème sera de savoir tricoter du code Asm-64bits
... demandes donc à René ce qu'il en pense.

Moi je veux bien essayer de le faire car l'extension des registres-processeurs 32 => 64 bits ainsi que la mise à disposition de registres supplémentaires peut s'entrevoir aussi naturellement que lorsqu'il s'est agi du passage 16 => 32 bits... Mais comment le faire avec Delphi si l'EDI ne donne pas les outils pour ?

(Je précise que je ne dispose actuellement ni d'une machine à proc 64 bits et a forciori ni d'un environnement Delphi XE2... Donc je parle un peu à vide...)

[Gilbert Geyer]

Bonjour,

A Rekin85 :

... Mais comment le faire avec Delphi si l'EDI ne donne pas les outils pour ?

... là je ne comprends pas bien René, je m'explique :
... puisque sur le site de J. Colibri il est écrit :

- seules les procédures ayant l'attribut Asm sont possibles

je suppose que l'EDI de XE2 donne un minimum de choses pour accepter ces procédures en Asm. Bien entendu une confirmation vaudrait mieux qu'une supposition.

De toutes façons comme on n'est pas pressés vaut mieux consolider la connaissance du sujet avant de passer aux actes si l'envie nous en prend.

A+.

[Rekin85]

Salut Gilbert

Alors on continue à parler dans le vide ou la supposition... Tant qu'on ne disposera pas du gros bébé francisé après avoir jeté nos tacots en 32 bits en déchetterie, on risque de se faire de fausses idées. Voici ce que j'ai lu sur le site de J. Colibri :

inclusion de blocs assembleur:

• il n'est plus permis de mélanger des blocs Asm avec des instructions Pascal
  seules les procédures ayant l'attribut Asm sont possibles
• la pile doit être alignée sur un multiple de 16 octets au début de chaque instruction
• le stockage temporaire doit utiliser des locales
• il n'est pas permis de modifier le pointeur de pile RSP
• il faut utiliser la convention d'appel unique; les 4 premiers paramètres sont dans les registres RCXn RDX (ou XMM0-XMM3)

Bon, l'important est donc que le bloc ASM...END dans du Pascal est maintenant interdit par le compilateur ? Il n'est permis que de bâtir du pur ASM en procedure ? Cela voudrait dire qu'on peut s'éclater avec de l'ASM sur du registre 64 bits (Wah ! le rêve ! ) quand même ?

Pour le reste il fallait s'y attendre... Plus dur : convention d'appel unique. Quid du stdCall pour établir les dll ?

Bon tu vois Gilbert, du positif à l'horizon... mais j'ai aussi relevé cette assertion qui dit bien ce qu'elle veut dire :

Et en général, il convient peut être de profiter de ce passage pour remplacer certaines "optimisation assembleur" par un refactoring en Pascal qui pourrait bien en finale s'avérer plus efficace

Bin oui, si Delphi compile en 64 pourquoi se casser le tronc à tricoter de l'ASM ? Note toutefois que nos types GInt et GCent ne seront sans doute jamais inclus dans Delphi et que l'aventure, si elle continue retera dans de l'ASM bien réflèchi...

[Gilbert Geyer]

Re-Salut René,

Cela voudrait dire qu'on peut s'éclater avec de l'ASM sur du registre 64 bits (Wah ! le rêve ! )

... bonne nouvelle : je vois que ça te met l'eau à la bouche.

Et en général, il convient peut être de profiter de ce passage pour remplacer certaines "optimisation assembleur" par un refactoring en Pascal qui pourrait bien en finale s'avérer plus efficace.

... tu nous vois re-convertir les Gint et les GCent en Pascal ???

Note toutefois que nos types GInt et GCent ne seront sans doute jamais inclus dans Delphi

... je note ... mais mais même dans mes rêves cela ne m'était jamais venu à l'esprit et de toutes façons comme on peut ajouter les Units sous Delphi c'est une autre façon de les inclure.

En attendant comme on ne dispose pour l'instant, ni d'XE2 ni de processeur 64 bits, ça nous laisse le temps de cogiter sereinement le sujet.

A+.

[tourlourou]

Note toutefois que nos types GInt et GCent ne seront sans doute jamais inclus dans Delphi

Cela serait peut être plus facilement réalisable dans Lazarus ?

A priori, une procedure inline est equivalente a faire un $include ou a recopier le contenu à l'endroit de l'appel -> donc mix impossible

Un peu, mais en fait :
http://laurent-dardenne.developpez.c...ution/Langage/
Donc impossible en D2005, et sûrement en 64 bits ! Je me suis emballé...

En attendant, bonjour à tous et bon code !

[rt15]

Pour le reste il fallait s'y attendre... Plus dur : convention d'appel unique. Quid du stdCall pour établir les dll ?

Les conventions d'appel ont été complètement revues avec le passage en x64. Notamment pour profiter des nouveaux registres (En plus de ce qu'on avait déjà qui se sont étendus eax -> rax, ebx -> rbx... on a par exemple r8, r9, r10, r11, r12, r13, r14, r15 en plus en x64). Ces nouveaux registres sont paraît il bien pratique : qui n'a jamais maudit le peu de registres dispos en x86 obligeant très souvent à mettre des variables locales dans la pile.

Microsoft est parti sur une convention d'appel unique. Visiblement, Embarcadero s'est aligné dessus (J'espère bien ! )

Mais il semble que sous unix, une autre convention ait été adoptée. Pas de chance, ça va pas aider à la portabilité tout ça.

[Caribensila]

Salut,

En matière de performances, dans un environnement 32 bits, le type Integer est le plus adapté.
Dans un environnement 64 bits, je suppose que le type Int64 jouera l'ancien rôle de l'Integer (puisque Integer restera en 32 bits).

En pratique, que faudra-t'il changer dans nos anciennes routines utilisant le type Integer pour tirer parti du nouvel environnement 64 bits :
- Rien ?
- Passer en Int64 ?
- Exploiter le fait qu'il y a 2 Integers dans un Int64 ?

Corollaire :
Les applications graphiques basées sur des pixels au format pf32bit risquent-elles d'en pâtir ou,
au contraire, de pouvoir en tirer parti en traitant 2 pixels en même temps par exemple ?

Question subsidiaire :
Je viens d'acheter un bouquin pour (enfin!) m'initier à l'ASM (en 32 bits).
Me conseillez-vous de me lancer ou est-il urgent d'attendre ?

Merci d'éclairer mon amateurisme.

[Thierry Laborde]

Bonjour à tous,

je vois que l'arrivée du 64bits passionne.

En pratique, que faudra-t'il changer dans nos anciennes routines utilisant le type Integer pour tirer parti du nouvel environnement 64 bits :
- Rien ?
- Passer en Int64 ?
- Exploiter le fait qu'il y a 2 Integers dans un Int64 ?

Allez quelques infos :

• Le type integer reste 32 bits
• Le type int64 reste 64 bits
• Arrivée d'un nouveau type NativeInt qui sera 32 bits ou 64 Bits selon que l'on compile pour Win32 ou Win64.

Voili, voila.

[guillemouze]

En matière de performances, dans un environnement 32 bits, le type Integer est le plus adapté.
Dans un environnement 64 bits, je suppose que le type Int64 jouera l'ancien rôle de l'Integer (puisque Integer restera en 32 bits).

En pratique, que faudra-t'il changer dans nos anciennes routines utilisant le type Integer pour tirer parti du nouvel environnement 64 bits :
- Rien ?
- Passer en Int64 ?
- Exploiter le fait qu'il y a 2 Integers dans un Int64 ?

NativeInt qui s'adaptera en fonction de si tu compiles en 32 ou 64.

Corollaire :
Les applications graphiques basées sur des pixels au format pf32bit risquent-elles d'en pâtir ou,
au contraire, de pouvoir en tirer parti en traitant 2 pixels en même temps par exemple ?

ce n'est que mon pressentiment (qui est loin d’être celui d'un éclairé sur le sujet), mais je penses que ca va pas changer grand chose. On utilisera que 32 des 64 bits dispo pour les opération. Enfin ca dépend des operations; ca sera a priori le meme comportement que un pf16bit dans un exe 32bits.

[Gilbert Geyer]

Re-bonjour,

Guillemouze : On utilisera que 32 des 64 bits dispo pour les opération.

... on peut quand-même espérer qu'avec du 64 bits on disposera d'un pf64bit offrant de nouvelles possibilités !!!

A+.

[rt15]

Salut Caribensila !

Je vais essayer de compléter un peu ces réponses.

En pratique, que faudra-t'il changer dans nos anciennes routines utilisant le type Integer pour tirer parti du nouvel environnement 64 bits :
- Rien ?
- Passer en Int64 ?
- Exploiter le fait qu'il y a 2 Integers dans un Int64 ?

Déjà, ce qu'il faut savoir, c'est que le 64 bits n'apporte généralement pas grand chose si ce n'est rien au niveau des performances. D'un côté certains "travaux" souvent utilisés sur la mémoire (Ajoutées par le compilateur) peuvent être plus rapides tel que CopyMemory/Move, ZeroMemory (Encore que ça dépend beaucoup de l'implémentation)... De l'autre, le code est beaucoup plus gros en mémoire (Les instructions ont des opérandes sur 64 bits qui prenne de la place), et les données aussi ce qui pose problème pour tout ce qui est cache processeur. Il y a plus de transferts des caches vers la RAM ce qui est préjudiciable.

Par exemple dans le code suivant (Du moins la partie gestion de i et j en mémoire, l'addition...) tourne très probablement à la même vitesse sur un processeur 64 bit, qu'il soit compilé vers une appli 32 ou 64. Et passer par du Int64 pour la compilation vers 64 ne changerait rien non plus aux perfs.

Code delphi :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
var
  i, j: Integer;
begin
  i:= Random(200);
  j:= Random(200);
  ShowMessage(IntToStr(i + j));
end;

Par contre, utiliser un Int64 est désastreux pour les perfs quand on compile vers du 32 !
Et c'est là le principal avantage de compiler vers du 64 bits. Le processeur devient capable de travailler efficacement sur des entiers non signés supérieurs à 4294967295.

Avant, si l'application devait traiter des entiers supérieurs à 4294967295, soit on passait par un Int64 plus lent (Mais aussi limité), soit par une librairie dédiée au calcul sur grands entiers (Tel que gmp ou peut être NewGInt et NewGCent évoquées sur ce thread), encore plus lente.
Maintenant, on n'aura plus ce problème de lenteur avec les Int64, et on aura moins tendance à utiliser une "lente" librairie pour les grands entiers. 4 milliards et des brouettes, c'est un chiffre plus facile à dépasser que 18446744073709551615.

Les applications monétaires actuelles en Delphi utilisent probablement le type Currency pour la plupart. C'est en gros un Int64 auquel on met virtuellement une virgule au niveau du 4ème chiffre. Compilé en 32 bit, ce type est strictement équivalent à un un Int64, donc lent. Compilé en 64 bit, le type Currency devient aussi rapide que ne l'était le type Integer.

Le processeur devient aussi un peu plus à l'aise avec le type Double (flottant 64 bit). Pas dans les calculs, vu que ça reste le boulot de la FPU qui les gérait déjà, mais dans certains déplacements de Double (Mais bon ça doit rester vraiment marginal. Et dans le domaine du jeux vidéo, passer du Single au Double n'est pas forcément intéressant non plus pour les perfs niveau carte graphique).

Bref, porter une appli 32 bits en 64 bits n'apporte généralement pas grand chose, et souvent, ceux qui le font conservent pas mal d'entiers en 32 bits ! Faut par exemple savoir que sous Visual C++, si on cible x64 le type C int est sur 32 bits (Relativement normal, de même avec pas mal de compilo sous unix), mais le type long est aussi en 32 bits !
Mais c'est sûr que comme dit plus, réécrire certaines procédures classiques avec du NativeInt doit parfois être pertinent.

Je viens d'acheter un bouquin pour (enfin!) m'initier à l'ASM (en 32 bits).
Me conseillez-vous de me lancer ou est-il urgent d'attendre ?

Franchement, je te conseillerais de te lancer dans le 32 bits, vu que comme dit partout, le x64 est une "extension" du x86 (Donc facile d'apprendre le x64 après le x86). Tu peux même commencer par du 16 bits si tu veux ! C'est d'ailleurs à peine plus facile pour les humains car les opérandes sont moins grandes.

En tout cas l'IDE de Delphi (Tout du moins les versions 6 et 7) est vraiment bien pour apprendre l'assembleur, peut être le meilleur produit à ce niveau.