L'apprentissage FORTRAN Dans l'Ère Moderne

Que vous avez pour obtenir une "sensation" pour ce que les programmeurs ont dû faire retour dans la journée. La grande majorité du code, je travaille avec est plus âgé que moi et a couru sur des machines qui étaient "nouveaux" quand mes parents étaient au lycée.

Commune FORTRAN-ismes, j'ai traiter avec, qui nuisent à la lisibilité sont:

• Blocs communs
• Implicite des variables
• Deux ou trois FAIRE des boucles avec un partage des instructions continue
• GOTO en place de boucles NE
• Arithmétique SI les déclarations
• Calculée GOTO
• Équivalence RÉEL/ENTIER/des autres dans certaines communes bloc

Des stratégies pour la résolution de ces impliquent:

1. Obtenir Spag /plusFORT, la peine de l'argent, il résout un grand nombre d'entre eux automatiquement et sans Bug(tm)
2. Déplacer à Fortran 90, si possible, si pas déplacer gratuit-format Fortran 77
3. Ajouter IMPLICIT NONE pour chaque sous-programme, puis fixer toutes les erreurs lors de la compilation, beaucoup de temps, mais finalement nécessaire, certains programmes peuvent le faire automatiquement pour vous (ou vous pouvez le script)
4. De déplacer tous les blocs COMMUNS aux MODULEs, fruits mûrs, la peine
5. Convertir arithmétique SI les déclarations de SI....ELSEIF ELSE blocs
6. Convertir calculée GOTOs pour SÉLECTIONNER les CAS les blocs

7. Convertir tous FAIRE des boucles à la nouvelle F90 syntaxe

   myloop: do ii = 1, nloops
       ! do something
   enddo myloop
   

8. Convertir equivalenced commune bloc membres AFFECTABLES la mémoire allouée dans un module, ou de leur véritable caractère routines si c'est Hollerith être stockés dans un VÉRITABLE

Si vous avait des questions plus précises quant à la façon d'accomplir une partie de la lisibilité des tâches, je peux donner des conseils. J'ai un code de base de quelques centaines de milliers de lignes de Fortran qui a été écrit sur une période de 40 ans que je suis en quelque sorte responsable, donc j'ai probablement courir à travers toutes les "problèmes" que vous pourriez avoir trouvé.

Il y a quelque chose dans la question d'origine que j'aurais de la prudence. Vous dites que le code est en proie à "l'amélioration de la performance des améliorations". Depuis le Fortran problèmes sont généralement d'un scientifique et mathématique de la nature, de ne pas assumer ces astuces sont là pour améliorer la compilation. Ce n'est probablement pas à propos de la langue. En Fortran, la solution est rarement au sujet de l'efficacité du code lui-même, mais les mathématiques sous-jacentes à résoudre le problème. Les options peuvent faire la compilation plus lent, peut même faire de la logique apparaissent en désordre, mais l'intention est de rendre la solution plus rapidement. Sauf si vous savez exactement ce qu'il fait et pourquoi, le laisser seul.

Même simple, comme le changement du muet à la recherche de noms de variables peuvent être un gros piège. Historiquement standard des équations mathématiques dans un domaine donné de la science ont utilisé un abrégée depuis les jours de Maxwell. Donc, pour voir un tableau nommé B(:) dans l'électromagnétisme indique tous les Emag ingénieurs exactement ce qui est en train d'être résolu. Changement à vos risques et périls. Morale, apprendre à connaître la norme de la nomenclature de la science avant de le renommer trop.

J'ai utilisé Fortran en commençant par l'66 version depuis 1967 (sur un IBM 7090 avec 32 k mots de mémoire). J'ai ensuite utilisé PL/1 pour un certain temps, mais revint plus tard à Fortran 95, car il est idéalement adapté pour la matrice/complexe-nombre des problèmes que nous avons. Je voudrais ajouter aux considérations qu'une grande partie de la structure alambiquée de vieux codes est tout simplement en raison de la faible quantité de mémoire disponible, forçant une telle chose comme la réutilisation de quelques lignes de code via calculées ou affectés GOTOs. Un autre problème est l'optimisation par la définition des variables auxiliaires pour chaque sous-expression répétée - les compilateurs n'ont tout simplement pas optimiser pour cela. En outre, il n'était pas autorisé à écrire DO i=1,n+1; on devait écrire n1=n+1; DO i=1,n1. En conséquence vieux codes sont débordés avec superflu des variables. Quand j'ai réécrit un code en Fortran 95, 10% seulement des variables survécu. Si vous voulez rendre le code plus lisible, je recommande fortement la recherche de variables qui peuvent facilement être éliminés.

Une autre chose que je pourrais mentionner, c'est que pendant de nombreuses années complexe de l'arithmétique et de tableaux multidimensionnels ont été très inefficace. C'est pourquoi vous trouverez souvent des code réécrit pour effectuer des calculs complexes en utilisant uniquement des variables réelles, et les matrices traitées avec un seul linéaire de l'indice.

Pourriez-vous expliquer ce que vous avez à faire dans le maintien du code? Avez-vous vraiment modifier le code? Si vous pouvez vous en sortir en modifiant juste l'interface de ce code, plutôt que le code lui-même, qui serait le meilleur.

Le problème inhérent lorsqu'ils traitent avec un grand scientifique de code (et pas seulement FORTRAN), c'est que les mathématiques sous-jacentes et la mise en œuvre sont à la fois complexes. Presque par défaut, la mise en œuvre a pour comprennent l'optimisation du code, afin de l'exécuter dans des délais raisonnables. Cette situation est aggravée par le fait que beaucoup de code dans ce champ est créé par les scientifiques, les ingénieurs qui sont des experts dans leur domaine, mais pas dans le développement de logiciels. Disons simplement que "facile à comprendre" n'est pas la première priorité pour eux (j'étais l'un d'entre eux, encore à apprendre à être un meilleur développeur de logiciels).

En raison de la nature du problème, je ne pense pas que d'une manière générale, la question et la réponse est assez pour être utile. Je vous suggère de poster une série de questions spécifiques extrait de code ci-joint. Peut-être en commençant par celui qui vous donne le plus de maux de tête?

J'ai commencé sur le Fortran IV (WATFIV) sur des cartes perforées, et mes premières années de travail ont été VS FORTRAN v1 (IBM, Fortran 77 niveau). Beaucoup de bons conseils dans ce fil.

Je voudrais ajouter que vous avez à distinguer entre les choses faire pour amener la bête du tout, par rapport à des choses qui "optimiser" le code, par rapport à des choses qui sont à la fois plus lisible et maintenable. Je me souviens de traiter avec VAX superpositions en essayant d'obtenir DOE code de simulation pour fonctionner sur IBM avec de la mémoire virtuelle (ils devaient être supprimés et le tout tourné en un seul espace d'adressage).

Je doute de commencer par prendre soin de bien la restructuration FORTRAN IV structures de contrôle d'au moins FORTRAN 77 niveau, avec une bonne indentation et de la commenter. Essayer de se débarrasser de la primitive de structures de contrôle comme ASSIGN et CALCULÉE GOTO et à l'arithmétique, SI, et bien sûr, comme de nombreux GOTOs comme vous pouvez le (à l'aide de if-then-ELSE-ENDIF). Certainement utiliser IMPLICIT NONE dans chaque routine, à force de vous pour bien déclarer toutes les variables (vous ne croiriez pas combien de bugs que j'ai pris dans d'autres gens du code -- les fautes de frappe dans les noms de variables). Faites attention à la "prématuré optimisations" que vous êtes mieux de laisser le compilateur gérer par lui-même.

Si ce code est de continuer à vivre et être facile à entretenir, vous le devez à vous-même et vos ayants droit, pour le rendre lisible et compréhensible. Juste être certain de ce que vous faites comme vous le modifiez le code! FORTRAN a beaucoup de particulières les constructions qui peuvent facilement trébucher quelqu'un venant du côté C de le monde de la programmation. Rappelez-vous que le FORTRAN remonte à la mi-fin des années 50, quand il n'y a pas une telle chose comme une science de la langue et de la conception du compilateur, juste ad hoc piratage ensemble de quelque chose (désolé, le Dr B!).