Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Première présentation de Delphi XE2
Compilateur 64 bits, DataBindings et framework FireMonkey au menu

Le , par John Colibri

0PARTAGES

3  0 
La prochaine version de Delphi s’appelera Delphi XE2 (pour Delphi 2012). Elle devrait être officiellement annoncée le 24 Août aux "Delphi X2 World Tour" de Buenos Aires.

Cette nouvelle version incorporera :

  • le compilateur 64 bits pour Windows 64 bits. Une simple sélection de la plateforme cible devrait suffire, avec modifications éventuelle des instructions qui font des hypothèses 32 bits explicites
  • un nouveau jeu de composants visuels qui forment le framework FireMonkey. Il s'agit de composants 3D qui utilisent l'accélération des processeurs graphiques et qui seront utilisés pour une cross compilation NATIVE vers les plateformes Mac OsX et iOs (l'Os de iPhone et iPad). La même application Windows pourra donc être portée sur Mac OsX ou distribuée dans les boutiques iPhone
  • des DataBindings qui permettrons de lier des propriétes entre elles. Ces liaisons permettrons de se passer des composants sensibles aux données de la VCL, mais permettent aussi de lier n'importe quelle type d'informations autres que celles relatives aux bases de données. Sera utilisable par FireMonkey


Plus d'infos dans les semaines qui viennent.

Source

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Rekin85
Membre habitué https://www.developpez.com
Le 24/08/2011 à 16:51
Bonjour à tous;

C'est surtout pour faire plaisir à Gilbert, et pour saluer au passage John Colibri dont personne parmi les programmeurs en Pascal ne peut ignorer avec beaucoup de nostalgie le célèbre et très pédagogique "Pascalissime".

Je suis un "intégriste" de l'ASM dans Delphi car les possibilités de concision et vitesse du code qu'il permet (quand on ne peut faire parfois autrement ) sont un plus indéniable à la programmation. Donc j'espère de tout coeur qu'il sera possible de continuer à le faire avec du 64 bits (??!!)

Maintenant, soyons pragmatiques : l'ASM 32 bits dans du Delphi 32 bits pour des applications 32 bits, c'est tout bonnement destiné aux machines à processeurs... 32 bits ! Donc, sans vouloir être simplet, une application développée en Delphi avec de l'ASM et compilée en 32 bits si elle tourne sur du système 32 bits peut sans mal tourner sur un système 64 bits (compatibilité ascendante). Donc, primo, Gilbert n'a pas trop de soucis à se faire avec des unités écrites en ASM 32 bits tant qu'il les compilera en 32 bits !

La question pour le futur est de se demander si des instructions ASM seront encore intégrables dans du Delphi 64 bits ? Je m'explique : le langage de Delphi XE2 est-il pourvu d'un jeu d'instructions ASM 64 bits compilables ? (Cela ne semble pas encore vrai...)

Alors, Gilbert, ne te traumatise pas encore... Quand ce préalable sera réalisé, il sera temps de reprendre nos "vieilles" routines ASM et de les passer en 64 bits ! Je rêve !... Nous leur ferions faire un énorme bond de géant ! Tu serais émerveillé du calcul de la racine carrée ! 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. Je ne veux cependant pas trop m'étendre sur la philosophie de l'utilisation de l'ASM, mais il faudra se dire que nos anciennes conceptions de développement seraient à jeter aux orties; bref il faudrait tout rebâtir en partant de zéro. Quelle aventure au bout du clavier...
2  0 
Avatar de John Colibri
Membre confirmé https://www.developpez.com
Le 24/08/2011 à 21:02
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
2  0 
Avatar de rt15
Membre confirmé https://www.developpez.com
Le 26/08/2011 à 17:57
Salut Caribensila !

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

Citation Envoyé par Caribensila  Voir le message
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
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.

Citation Envoyé par Caribensila  Voir le message
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.
2  0 
Avatar de PushRax
Candidat au Club https://www.developpez.com
Le 27/08/2011 à 21:04
Je suis impatient de voir le compilateur 64 bits final à l'œuvre.

Après l'avoir défendu ardemment pendant très longtemps (envers et contre tous), j'ai finalement dû abandonner Delphi en 2006 à cause de son non support de la compilation native 64 bits. FPC n'est pas une alternative sérieuse pour bien des raisons liées à sa conception. Il a donc fallu passer intégralement au C/C++ sous Visual Studio, qui permet de compiler en 32, AMD64 et IA64 depuis un sacré bout de temps. Dans l'imagerie numérique pro, la 3D et le montage vidéo, les OS 64 bits sont adoptés depuis longtemps (pour la quantité de RAM adressable). L'avantage d'un OS 64 bits est triple : c'est le "langage" natif des processeurs depuis quelques années (les pipelines sont optimisés pour le 64 bits), le plus grand nombre de registres permet enfin de coder efficacement en utilisant moins intensivement la pile et le stockage en mémoire, et bien sur le modèle mémoire permet d'utiliser des applications très gourmandes bien plus efficacement. De plus, sous Windows x64, le sous-système WOW64 pourtant très efficace qui gère les applications 32 bits introduit également des petites pénalités de performances : le basculement du processeur en mode 32 ou 64 bits, la traduction des chemins d'accès ainsi que les wrappers permettant la traduction des conventions d'appel et taille des paramètres a forcement un léger coût, que l'on ressent très nettement si beaucoup d'applications 32 bits tournent en même temps. Et sur plateforme IA64, c'est encore pire vu que le x86 est entièrement émulé...

Bien sur, recompiler un projet prévu pour du 32 bits (utilisant des int 32) en 64 bits n'apportera pas grand chose sinon rien en terme de performances, l'intérêt étant de prévoir son code pour tirer parti des spécificités de l'architecture 64 bits.

Le traitement d'images n'a aucun rapport avec la résolution du processeur ou de l'OS. Une image 8 bits reste 8 bits, une 32 bits reste 32 bits, indépendamment de l'OS ou du processeur. On traitait des images 32 bits sur des processeurs 8 bits (comme les premières palettes graphiques pro qui tournaient sous Z80), et on traite des images 8 bits sur des processeurs 64 bits, cela n'a strictement aucun rapport et ne change rien pour un programmeur en c ou pascal. Les espaces de couleur avec des composants de 16 bits (4x16 = 64) sont réservés à des traitements très spécifiques qui n'ont pas lieu d'être pour le commun des mortels. Par contre, cela fait plus de 10 ans que l'on traite les images grâce aux instructions et registres 64 bits introduits avec le mmx, puis 3D now, SSE, etc... Ainsi, en effet, on peut traiter 2 pixels 32 bits à la fois, 4 pixels 16 bits ou 8 pixels 8 bits (bien que cela ne présente que peu d'intérêt pour les formats palétisés). Cela est aussi très efficace pour le traitement audio. La librairie delphi Graphics32 utilise d'ailleurs abondamment cela pour gérer le blending et l'anti-aliasing de manière 100% software. Mais pour gérer efficacement du traitement d'images, rien n'égale DirectX sous Windows, qui est relativement simple à utiliser et permet de plus de bien comprendre comment les cartes vidéo gèrent les pixels et les espaces de couleur. Le type pf32bit sous delphi, si ma mémoire est bonne, est géré via une DibSection, qui reste le meilleur moyen software de gérer une image bitmap sous GDI, à la manière de DirectDraw. En 2005, j'ai créé une librairie de traitement graphique professionnelle multi-plateformes (d'abord écrite sous delphi puis portée très facilement sous C++), et l'utilisation des dibsection et de SetDIBitsToDevice() sous Windows permettait de limiter le code dépendant Win32 à quelques lignes seulement (tout le traitement possible sur les images en mode software ne nécessitant strictement aucune API ou fonction externe, uniquement des calculs et beaucoup de code machine optimisé pour chaque plateforme cible).
2  0 
Avatar de Thierry Laborde
Membre émérite https://www.developpez.com
Le 26/08/2011 à 16:29
Bonjour à tous,

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

Citation Envoyé par Caribensila Voir le message
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.
1  0 
Avatar de GoustiFruit
Membre éclairé https://www.developpez.com
Le 04/09/2011 à 11:28
Non, aucun soucis avec "Double Driver".
Mais en général je recherche d'abord les pilotes sur le site du constructeur, juste au cas où.
Sinon un coup de "MaConfig" pour récupérer les derniers pilotes...

PS: je ne supporte pas les partitions cachées de restauration du système, ni les suites logicielles préinstallées, genre Norton, Office, "utilitaires" du fabricant, logiciel d'enregistrement auprès du vendeur et autre bidules en période d'évaluation... je préfère partir d'un système propre. Dès que tous les drivers sont fonctionnels, je fais une première image de sauvegarde du système, et ensuite j'installe ce dont j'ai vraiment besoin.
1  0 
Avatar de John Colibri
Membre confirmé https://www.developpez.com
Le 21/08/2011 à 17:25
ah nostalgie, nostalgie ...
en attendant, depuis 2001, c'est http://www.jcolibri.com qui tient lieu de Pascalissime
1  1 
Avatar de Gilbert Geyer
Modérateur https://www.developpez.com
Le 22/08/2011 à 10:28
Bonjour,

John Colibri : ah nostalgie, nostalgie ...
... ce n'est pas uniquement par nostalgie que j'ai posé cette question.
Car comme tout autodidacte quand j'ai démarré avec Delphi j'ai acheté successivement une flopée de bouquins qui m'ont généralement déçu (manque de pédagogie, exemples qui ne fonctionnaient pas, etc) ... jusqu'au jour où j'ai trouvé "Delphi Applis Windows Rapides" : concis, très pédagogique et très digeste, et cela avait été pareil pour la quasi-totalité des articles de Pascalissime.

Mais à propos de Delphi 64 bits : faudra qu'on remplace nos processeurs par des 64 bits pour en profiter pleinement. Et là je me pose une question de compatibilité : Est-ce-que des routines développées en Asm sous les versions 32 bits de Delphi vont fonctionner sous Delphi 64 bits sans avoir à les modifier ou bien faudra-t-il les jeter à la corbeille et tout recommencer ???.

A+.

EDIT : ma question est bête : j'ai trouvé la réponse à la rubrique "Migration 64 bits Delphi: les points à surveiller" ... mais faudra pas seulement surveiller ... faudra certainement modifier.
1  1 
Avatar de sjrd
Expert éminent https://www.developpez.com
Le 22/08/2011 à 14:26
Citation Envoyé par Gilbert Geyer Voir le message
Mais à propos de Delphi 64 bits : faudra qu'on remplace nos processeurs par des 64 bits pour en profiter pleinement. Et là je me pose une question de compatibilité : Est-ce-que des routines développées en Asm sous les versions 32 bits de Delphi vont fonctionner sous Delphi 64 bits sans avoir à les modifier ou bien faudra-t-il les jeter à la corbeille et tout recommencer ???.
Ah oui c'est évident. Pour faire tourner un programme sur un proc 32 bits, il faut un programme 64 bits.

En revanche, un proc 64 bits peut faire tourner des programmes 64 mais aussi 32.

Si ton programme est 32, les routines Asm doivent être en 32. Si tu compiles pour 64, tu dois traduire tes routines Asm pour 64.

En même temps si t'as fait des routines Asm, tu l'as cherché
1  1 
Avatar de sjrd
Expert éminent https://www.developpez.com
Le 22/08/2011 à 20:34
Moi j'espère surtout que les développeurs de Graphics32 vont trouver le temps et le courage de migrer cette biblio en 64 bits.

Et pour ma part je vais devoir fournir un gros effort pour mon moteur de script Sepi. Là il y a certaines parties codées en Assembleur, pas pour des raisons d'optimisation, mais bien parce qu'il est impossible de faire autrement.

Et je dois dire que je m'inquiètes sérieusement en lisant ceci :
Citation Envoyé par jColibri
il n'est plus permis de mélanger des blocs Asm avec des instructions Pascal
et pire :
Citation Envoyé par jColibri
il n'est pas permis de modifier le pointeur de pile RSP
1  1