Comment dois-je préparer mon 32 bits de Delphi programmes pour une éventuelle compilateur 64 bits?

Question

Double Possible:
Comment préparer également pour la version 64 bits lors de la migration vers Delphi 2010 et Unicode

Depuis je crois que 64 bits de Delphi compilateur va bientôt apparaître, Je suis curieux de savoir si quelqu'un sait quel genre de programmes qui sont maintenant 32 bits de compiler et fonctionner sans aucune modification lors de l'utilisation de 64bit compilateur.

Et si il y a une règle générale, ce genre de changements que doit-on faire systématiquement dans nos anciens programmes compilés comme 64bit?

Il est bon d'être prêt lorsque le 64 bits, le compilateur va soudainement être ici...

Toute suggestion sera apprécié.

Answer 1

Tout d'abord, un avertissement: bien que je travaille pour Embarcadero. Je ne peux pas parler pour mon employeur. Ce que je vais écrire est basé sur ma propre opinion de la façon dont un hypothétique 64 bits de Delphi devrait fonctionner, mais il peut ou peut ne pas être en concurrence des avis et d'autres prévus ou imprévus des incompatibilités et des événements qui provoquent des alternatives de conception des décisions à prendre.

Qui a dit:

• Il existe deux types d'entiers, NativeInt et NativeUInt, dont la taille va flotter entre 32 bits et 64 bits en fonction de la plateforme. Ils ont été depuis assez peu de rejets. Pas d'autres types d'entiers vont changer la taille en fonction du nombre de bits de la cible.

• Assurez-vous que n'importe quel endroit qui s'appuie sur le casting d'une valeur de pointeur à une entier ou vice versa, est à l'aide de NativeInt ou NativeUInt pour l'entier type. TComponent.Balise doit être NativeInt dans les versions de Delphi.

• Je vous suggère de ne pas utiliser NativeInt ou NativeUInt pour les non-pointeur de base de valeurs. Essayez de garder votre code sémantiquement le même entre les versions 32 bits et 64 bits. Si vous avez besoin de 32 bits de gamme, utilisez Entier; si vous avez besoin de 64 bits, utilisez Int64. De cette façon, votre code doit s'exécuter de la même manière sur les deux bitnesses. Seulement si vous êtes à la conversion et à partir d'une valeur de Pointeur de quelque sorte, comme une référence ou un THandle, devriez-vous utiliser NativeInt.

• Utiliser PByte pour l'arithmétique des pointeurs, si possible, de préférence à d' NativeInt ou NativeUInt. Il suffira pour la plupart des fins, et est plus typesafe, car il ne peut pas être (facilement) pris pour une normale de type entier, et vice versa.

• Pointeur-comme les choses doivent suivre des règles similaires pour les pointeurs: objet références (évidemment), mais aussi des choses comme HWND, THandle, etc.

• Ne comptez pas sur les détails internes de chaînes de caractères et les tableaux dynamiques, comme leurs données d'en-tête.

• Notre politique générale sur les changements de l'API pour 64-bit devrait être de garder les même API entre 32 bits et 64 bits si possible, même si cela signifie que la version 64 bits de l'API ne permet pas nécessairement de prendre avantage de la machine. Pour exemple, TList sera probablement la seule poignée exemple maxint div SizeOf(Pointeur) éléments, afin de tenir compte, index etc. en tant qu'Entier. Parce que le Type entier ne flotteront pas (c'est à dire changer de taille en fonction du nombre de bits), nous ne voulez pas avoir des effets positifs sur le code client: tous les index aller-retour à travers un Entier de type de variable, ou indice de boucle, serait tronquée et potentiellement causer des bogues subtils.

• Où Api sont étendues pour la version 64 bits, ils seront très probablement être fait avec un supplément de fonction / méthode / propriété pour accéder aux données supplémentaires, et ce API sera également pris en charge en 32 bits. Par exemple, la Longueur() standard la routine sera probablement de retour des valeurs de type Entier pour les arguments de type chaîne de caractères ou un tableau dynamique; si l'on veut traiter de très grandes les tableaux dynamiques, il peut y avoir un LongLength() de la routine, dont le mise en œuvre dans le 32 bits est la même que la Longueur(). Longueur() throw une exception en 64 bits si elle est appliquée à un tableau dynamique avec plus de 2^32 éléments.

• À cet égard, il y aura probablement d'amélioration de la vérification des erreurs pour rétrécissement des opérations dans la langue, surtout le rétrécissement des valeurs 64 bits à 32 bits endroits. Ce serait frappé de la facilité d'utilisation de l'assignation de la valeur de retour de la Longueur de l'emplacement de type entier (Integer) si la Longueur(), retourné Int64. D'autre part, plus spécifiquement pour le compilateur de la magie des fonctions comme la Longueur(), il peut y avoir un certain avantage de la magie prises, par exemple basculer le type de retour fondées sur le contexte. Mais l'avantage ne peut pas être de même prises en non-magie de l'Api.

• Tableaux dynamiques vont probablement prendre en charge 64 bits d'indexation. Notez que Java les tableaux sont limités à 32 bits de l'indexation, même sur les plates-formes 64 bits.

• Les chaînes seront probablement limité à 32 bits d'indexation. Nous avons un dur du temps avec des raisons pour les gens qui veulent 4GO+ cordes qui sont vraiment les cordes, et pas seulement réussi gouttes de données, pour lesquels tableaux dynamiques peut servir tout aussi bien.

• Peut-être intégré dans l'assembleur, mais avec des restrictions, comme pas de pouvoir librement mélanger avec le code Delphi; il y a aussi des règles en matière d'exceptions et de la pile structure du châssis qui doivent être suivies sur x64.

Answer 2

Tout d'abord, FreePascal propose déjà une version 64 bits de soutien. Ce n'est pas Delphi, cependant.
Deuxième de tous, je m'attends à environ les mêmes problèmes qui existaient dans le temps Delphi 1 a été mis à jour à Delphes 2. Le plus gros problème, c'est surtout un espace d'adressage et que le problème ici est que les pointeurs sera élargi à partir de 4 octets 8 octets. Dans WIN16 ils utilisent à 2 octets et un truc qui était nécessaire pour obtenir au-dessus de la limite de 64 ko en utilisant des segments et des compensations pour les pointeurs. (Avec la possibilité d'utiliser des segments par défaut pour plusieurs tâches.)
Il est également probable que certains types de données va devenir plus gros qu'ils ne le sont maintenant. Le type entier sera de 8 octets, le plus probable. (Utilisé à seulement 2 octets dans Windows 2.) Les énumérations sont susceptibles de devenir plus trop. Mais la plupart des autres types de données sont susceptibles de garder leur taille actuelle, donc pas trop de changements ici.
Une autre question sera à la mémoire. Puisque les pointeurs sera de 8 octets de long, une application qui utilise beaucoup d'entre eux mangent aussi beaucoup plus de mémoire. Une liste avec 10.000 pointeurs augmentera de 40 000 octets à 80.000 octets. Vous pourriez utiliser un peu plus de mémoire que sur un système 32 bits.
La vitesse va aussi changer un peu. Depuis le processeur gère maintenant 8 octets dans le même temps, il peut traiter des données beaucoup plus rapide. Mais puisque les pointeurs et certains types de données deviennent plus gros, de la réception ou de l'envoi de ces de certains de l'appareil ou de la mémoire sera un peu plus lent. En général, votre demande sera légèrement plus rapide en général, mais certaines parties pourrait en fait devenir plus lent!
Enfin, les changements dans l'API Windows exigera de vous d'utiliser la version 64 bits fonctions de l'API. Peut-être que le compilateur Delphi va faire quelque chose d'intelligent pour permettre au code d'appel fonctions d'API 32 bits, mais ce serait de ralentir les performances, car le processeur passe maintenant entre les natifs 64 bits et en mode émulé 32-bits mode.

Answer 3

En fonction de votre code, vous pouvez essayer de le compiler à l'aide de FreePascal, qui prend en charge les versions 32 bits et 64 bits de compilation. Le compilateur va vous en avertir éventuellement erronées endroits dans votre code.

Answer 4

De nombreuses questions similaires ont été posées quand il a été annoncé que Delphi 2009 ne ferait que créer de l'Unicode des applications. En fin de compte il s'est avéré que la plupart des code a fonctionné très bien sans modifications. Difficile parties du code qui suppose que la SizeOf(Char) = 1 et la 3ème partie des composants qui pourraient faire ça.

Je dirais que le passage à 64 bits de Delphi pour être une expérience similaire. Tout fonctionne, tout simplement hors de la boite, sauf pour le code qui joue des tours avec des pointeurs et suppose qu' SizeOf(Pointer) = 4 ou SizeOf(Pointer) = SizeOf(Integer). Vous pouvez déjà résoudre ces problèmes dès aujourd'hui en appelant SizeOf(Pointer) plutôt que de coder en dur 4 et à l'aide de NativeInt ou NativeUInt quand vous avez besoin de pointeur de la taille des entiers.

Vous devez utiliser SizeOf(Pointer) plutôt que d' SizeOf(NativeInt) si vous voulez que votre code fonctionne avec Delphi 2007. Delphi 2007 a un malheureux bug qui provoque SizeOf(NativeInt) de retour 8 au lieu de 4 comme il se doit. Ceci a été corrigé dans Delphi 2009.

Answer 5

La grande majorité des applications simples devrait fonctionner parfaitement. Aussi loin que je peux voir, que les applications manuellement utiliser les pointeurs sont à un risque. En effet, si un pointeur est maintenant 64 bits, et de l'utiliser dans des calculs avec des entiers ou des cardinaux (qui sont encore en 32 bits par défaut), vous allez avoir des ennuis. Je pense aussi que c'est assez courant que les déclarations de fonctions de l'API qui prennent des pointeurs comme arguments à l'aide de cardinals au lieu de la (non signé) originaire de type entier.

Afin de rendre le code qui fonctionne bien sur toute plate-forme, il faut utiliser NativeUInts (IIRC, n'ont pas une Deplhi compilateur pour le moment) au lieu de cardinals lorsque l'on travaille avec des pointeurs et des entiers simultanément.