Discussion :

[John Colibri]

Première présentation de Delphi XE2
Compilateur 64 bits, DataBindings et framework FireMonkey pour la prochaine version de Delphi

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

[Gilbert Geyer]

Bonjour,

Pour quand la reprise de Pascalissime ? : ça manque dans le bureaux de tabac et autres boutiques.

A+.

[John Colibri]

ah nostalgie, nostalgie ...
en attendant, depuis 2001, c'est http://www.jcolibri.com qui tient lieu de Pascalissime

[Gilbert Geyer]

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.

[sjrd]

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é

[guillemouze]

Merci pour cette petite intro, ça m'a l'air très prometteur
Et c'est vrai qu'on ne trouve pas vraiment d'infos sur XE2, si ce n'est la pub pour le "XE2 World Tour". Je suis allé sur le site d'embarcadero, c'est très pauvre en informations à ce propos !!!

[Gilbert Geyer]

Bonjour,

Sjrd :... En même temps si t'as fait des routines Asm, tu l'as cherché.

... en fait je nul en Asm pour moi c'est du chinois.
... par contre je m'inquiète un peu pour l'avenir de deux units, essentiellement en Asm, auxquelles j'avais participé en tant que testeur lors de leur création par Kinzinger René qu'on trouve ici : http://www.phidels.com/php/index.php...feb15dddb7b356

Et idem pour ce qui est du code qu'on trouve ici : http://www.phidels.com/php/index.php...feb15dddb7b356
qui utilise la version "n-1" de l'une des deux units précitées.

... mais faut se faire une raison : on n'arrête pas le progrès : bienvenue au 64 bits.

A+.

[CapJack]

La dernière version de Delphi que j'ai achetée, c'était 2009 pour l'Unicode, la prochaine sera XE2 pour le 64 bits et le multi-plateforme.
Il est prévu des pré-versions pour les honnêtes clients ?

Nouveau préfixe REX pour l'assembleur 64 bits : et l'heure de REX sonna !
On pourra coder proprement, avec ça ! Euh, oui, euh, la sortie ? euh, inutile de me raccompagner, je connais. Hum.

[sjrd]

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 :

il n'est plus permis de mélanger des blocs Asm avec des instructions Pascal

et pire :

il n'est pas permis de modifier le pointeur de pile RSP

[John Colibri]

> Sébastien Doeraene ... mélange assembleur ... RSP

- mes infos proviennent des transparents de David INTERSIMONE dont le lien exact est dans l'article. Vérifiez à tout hasard

[Paul TOTH]

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 :

et pire :

et que fera tu quand Delphi permettra de compiler pour ARM ?

Par curiosité, que ne peux tu faire en Pascal et que tu dois faire en assembleur ?

[sjrd]

et que fera tu quand Delphi permettra de compiler pour ARM ?

Je ne supporterai pas l'ARM dans Sepi...

Par curiosité, que ne peux tu faire en Pascal et que tu dois faire en assembleur ?

Euh... ça (SepiInCalls.pas)
Et aussi cette méthode (TSepiRuntimeContext.ReadParamsAndCall).

En fait tous ces bouts de code se situent à l'interface entre du code Delphi natif et du code compilé+interprété par Sepi. SepiInCalls.pas s'occupe de toutes transition Delphi vers Sepi. Et ReadParamsAndCall s'occupe des transitions Sepi > Delphi.

[Gilbert Geyer]

Bonjour,

Sjrd 22/08/2011 20h34 : 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

Sjrd 22/08/2011 14h26 En revanche, un proc 64 bits peut faire tourner des programmes 64 mais aussi 32.

On peut donc conserver du code mixte (Pascal+Asm) dans des applis-console compilées en un exe 32 bits que l'on appelle depuis une appli 64 bits. Cela peut être une solution provisoire évitant d'avoir à tout convertir en 64 bits.
Dans ce cas resterait plus qu'à gérer les échanges de données entre l'appli 32 bits et la 64 bit.
Dans ce cas l'exe 32 bits ne serait plus qu'un sous-programme.

A+.

[CapJack]

Pour quand la reprise de Pascalissime ? : ça manque dans le bureaux de tabac et autres boutiques.

(Totalement hors sujet, comme d'hab')

C'est clair. Vu mon grand âge, j'ai connu les premiers numéros, dans la deuxième moitié des années '80. Et j'ai appris énormément de choses grâce à cette publication. Je me rappelle notamment l'extrême rigueur dans le nommage des variables et dans la conception des procédures et fonctions.

Maintenant, nous vivons une époque formidable, où nous pouvons communiquer avec John de façon interactive (je me permets une question indiscrète au passage : Colibri est un vrai patronyme, ou un alias ? ; trop beau pour être vrai ! ).

C'est comme ça, le temps passe.

C'est une autre époque, alors, sachons profiter des gens dont la passion nous fait valoir leurs compétences, John Colibri, mais aussi Paul Toth, et d'autres.

[Paul TOTH]

Dans la séquence nostalgie, vous avez connu DP Tool Club ? ça remonte à l'époque ou on consultait Internet sur CDROM

[dehorter olivier]

Dans le cadre "Ils ne sont jamais contents"

John Colibri a écrit dans son petit topo :

6.6 - Platfoms futures (XE3 ?)
Linux et Android sont prévus, mais pour une version future de XE.

Pour Android, c'est pour quand ?

[Gilbert Geyer]

Re-bonjour,

Ouille! On n'a pas encore XE2 qu'on parle déjà d'XE3 !!!
... "qui va piano va sano".

A+.

[sjrd]

On peut donc conserver du code mixte (Pascal+Asm) dans des applis-console compilées en un exe 32 bits que l'on appelle depuis une appli 64 bits. Cela peut être une solution provisoire évitant d'avoir à tout convertir en 64 bits.
Dans ce cas resterait plus qu'à gérer les échanges de données entre l'appli 32 bits et la 64 bit.
Dans ce cas l'exe 32 bits ne serait plus qu'un sous-programme.

Ce que tu dis est vrai. Mais ça ne fonctionne que si ton code 32 est réellement un sous-programme isolé. Ca ne fonctionne pas si ce code doit à nouveau appeler du code normal, 64 bits.

Or c'est ce qui se passe (tout le temps) dans Sepi. Donc pour moi ça va pas le faire.

[Gilbert Geyer]

Re-bonjour,

Sjrd : Ce que tu dis est vrai. Mais ça ne fonctionne que si ton code 32 est réellement un sous-programme isolé. Ca ne fonctionne pas si ce code doit à nouveau appeler du code normal, 64 bits.

... 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).

A+.

[Rekin85]

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...