Simply Fortran is a relatively new integrated development environment for the Microsoft Windows operating system. As the name suggests, the environment specifically targets Fortran development, and the environment’s features reflect this design decision. Simply Fortran relies on an included version of GNU Fortran as its primary compiler, although the environment can be easily configured to utilize other compilers. The open-source Insight debugger, a graphical wrapper around GNU debugger (GDB), is included as a debugging solution. The software is distributed as “trialware,” allowing the user full access to all features for thirty days, after which a US$25 registration can be purchased.
{"title":"Introducing simply Fortran","authors":"J. B. Armstrong","doi":"10.1145/2338786.2338788","DOIUrl":"https://doi.org/10.1145/2338786.2338788","url":null,"abstract":"Simply Fortran is a relatively new integrated development environment for the Microsoft Windows operating system. As the name suggests, the environment specifically targets Fortran development, and the environment’s features reflect this design decision. Simply Fortran relies on an included version of GNU Fortran as its primary compiler, although the environment can be easily configured to utilize other compilers. The open-source Insight debugger, a graphical wrapper around GNU debugger (GDB), is included as a debugging solution. The software is distributed as “trialware,” allowing the user full access to all features for thirty days, after which a US$25 registration can be purchased.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"31 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-07-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130829583","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
We are working on a process for carrying out a set of transformations on Fortran legacy projects. We started our work for parallelization and reduction of runtime at least on multiprocessing systems, but we found necessary to update several old Fortran features and/or legacy software issues as a previous task. We present how to define and implement several source code transformations in order to enhance readability and, also, provide a source code that we think is more likely to be parallelized in subsequent work. Furthermore, we propose that some parallelization (e.g. for shared memory parallel computers) can be made at least as a tool-guided process, i.e. as other source code transformations. In the most simple cases, some transformations from sequential to parallel processing could be made automatically by a source code software analysis and transformation tool, which could provide the user (programmer/developer) a suggested way of Parallelisation. Source code transformations are initially approached as restructurings, and implemented by changing the abstract syntax tree (AST) program representation. We provide some comments on our preliminary work on the source code transformations directly focussed on parallelization that we expect to implement almost automatically.
{"title":"Fortran Legacy software: source code update and possible parallelisation issues","authors":"F. Tinetti, M. Méndez","doi":"10.1145/2179280.2179281","DOIUrl":"https://doi.org/10.1145/2179280.2179281","url":null,"abstract":"We are working on a process for carrying out a set of transformations on Fortran legacy projects. We started our work for parallelization and reduction of runtime at least on multiprocessing systems, but we found necessary to update several old Fortran features and/or legacy software issues as a previous task. We present how to define and implement several source code transformations in order to enhance readability and, also, provide a source code that we think is more likely to be parallelized in subsequent work. Furthermore, we propose that some parallelization (e.g. for shared memory parallel computers) can be made at least as a tool-guided process, i.e. as other source code transformations. In the most simple cases, some transformations from sequential to parallel processing could be made automatically by a source code software analysis and transformation tool, which could provide the user (programmer/developer) a suggested way of Parallelisation. Source code transformations are initially approached as restructurings, and implemented by changing the abstract syntax tree (AST) program representation. We provide some comments on our preliminary work on the source code transformations directly focussed on parallelization that we expect to implement almost automatically.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"31 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-03-29","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130716379","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Compiler support for the Fortran 2003 and 2008 standards revision 9","authors":"I. Chivers, J. Sleightholme","doi":"10.1145/2179280.2179282","DOIUrl":"https://doi.org/10.1145/2179280.2179282","url":null,"abstract":"","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"34 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-03-29","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134478766","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Compiler support for the Fortran 2003 and 2008 standards revision 8","authors":"I. Chivers, J. Sleightholme","doi":"10.1145/2073761.2073762","DOIUrl":"https://doi.org/10.1145/2073761.2073762","url":null,"abstract":"","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"9 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-11-29","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116506083","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
This paper outlines a revised reference counting programming pattern for derived types in Fortran 2003. It extends the method described by Car [1] to work with polymorphic types (i.e. using the class keyword). This reference counting pattern reduces the possibility of memory leaks by allowing the object itself to manage allocations and deallocations. It follows the pattern found in many modern object oriented languages like Java [2,3] and Python[4,5] and the auto_ptr template class in C++ [6]. The reference counting pattern described here is being used in conjunction with the PyF95++ pre-processor [7,8] and the accompanying Standard Template Library (STL). All the containers in that project are reference counted and employ the original pattern for derived types. Some of the intricacies of working with polymorphic types in Fortran are described as the implementation is discussed.
{"title":"A polymorphic reference counting implementation in Fortran 2003","authors":"Michael List, David Car","doi":"10.1145/2007333.2007334","DOIUrl":"https://doi.org/10.1145/2007333.2007334","url":null,"abstract":"This paper outlines a revised reference counting programming pattern for derived types in Fortran 2003. It extends the method described by Car [1] to work with polymorphic types (i.e. using the class keyword). This reference counting pattern reduces the possibility of memory leaks by allowing the object itself to manage allocations and deallocations. It follows the pattern found in many modern object oriented languages like Java [2,3] and Python[4,5] and the auto_ptr template class in C++ [6]. The reference counting pattern described here is being used in conjunction with the PyF95++ pre-processor [7,8] and the accompanying Standard Template Library (STL). All the containers in that project are reference counted and employ the original pattern for derived types. Some of the intricacies of working with polymorphic types in Fortran are described as the implementation is discussed.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"58 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-07-18","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114253274","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Compiler support for the Fortran 2003 and 2008 standards revision 7","authors":"I. Chivers, J. Sleightholme","doi":"10.1145/1961363.1961365","DOIUrl":"https://doi.org/10.1145/1961363.1961365","url":null,"abstract":"","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"71 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-03-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132293502","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
A simple unit testing framework has been developed utilizing a templating capability and Python based preprocessor for Fortran. The implementation of this framework and its use for testing serial and parallel components is discussed. The capability was successfully applied to the development of a Fortran Standard Template Library and associated toolsets.
{"title":"A fortran unit-testing framework utilizing templating and the PyF95++ toolset","authors":"Michael List, David Car","doi":"10.1145/1961363.1961364","DOIUrl":"https://doi.org/10.1145/1961363.1961364","url":null,"abstract":"A simple unit testing framework has been developed utilizing a templating capability and Python based preprocessor for Fortran. The implementation of this framework and its use for testing serial and parallel components is discussed. The capability was successfully applied to the development of a Fortran Standard Template Library and associated toolsets.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"28 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2011-03-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133642431","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
J. Overbey, Matthew J. Fotzler, Ashley J. Kasza, Ralph E. Johnson
This article contains detailed specifications of several automated refactorings for Fortran 95. These have been used to implement refactorings in Photran [1], an integrated development environment and refactoring tool based on Eclipse. Our purpose in publishing these specifications is twofold. First, we would like to encourage other Fortran tool vendors to consider adding refactoring support to their own IDEs; we hope that making our detailed specifications publicly available will allow others to benefit from our experience. Indeed, many details of the refactorings are quite subtle. Second, we are interested in receiving feedback on both the form and content of these specifications. Although they been carefully constructed and used as a basis for implementation, some errors, oversights, and ambiguities are inevitable. The first author will post errata, clarifications, and links to updated versions of this document at [2]. To the extent possible, we have attempted to use the same terminology as the Fortran 95 ISO standard [3], and we have attempted to describe the mechanics of the refactorings syntactically (i.e., in terms of the standard grammar). For example, we define an External Subprogram to be a 〈 function-subprogram〉 or a 〈subroutine-subprogram〉 in the context of an 〈external-subprogram〉. Such 〈bracketed-names〉 correspond to nonterminal symbols in the ISO grammar. Section numbers (e.g., §14.1.1) and rule numbers (e.g., R201) are also references to the ISO standard. All algorithms are described imperatively, as a sequence of steps that may be executed to test the precondition or perform the transformation. It is not always essential that an implementation execute these steps in the order listed; in many cases, the steps can be reordered and still produce the same results. For example, many precondition checks require a number of conditions to be checked, but these conditions are mutually disjoint, and therefore the order in which they are checked is inconsequential.
{"title":"A collection of refactoring specifications for fortran 95","authors":"J. Overbey, Matthew J. Fotzler, Ashley J. Kasza, Ralph E. Johnson","doi":"10.1145/1883575.1883577","DOIUrl":"https://doi.org/10.1145/1883575.1883577","url":null,"abstract":"This article contains detailed specifications of several automated refactorings for Fortran 95. These have been used to implement refactorings in Photran [1], an integrated development environment and refactoring tool based on Eclipse. Our purpose in publishing these specifications is twofold. First, we would like to encourage other Fortran tool vendors to consider adding refactoring support to their own IDEs; we hope that making our detailed specifications publicly available will allow others to benefit from our experience. Indeed, many details of the refactorings are quite subtle. Second, we are interested in receiving feedback on both the form and content of these specifications. Although they been carefully constructed and used as a basis for implementation, some errors, oversights, and ambiguities are inevitable. The first author will post errata, clarifications, and links to updated versions of this document at [2]. To the extent possible, we have attempted to use the same terminology as the Fortran 95 ISO standard [3], and we have attempted to describe the mechanics of the refactorings syntactically (i.e., in terms of the standard grammar). For example, we define an External Subprogram to be a 〈 function-subprogram〉 or a 〈subroutine-subprogram〉 in the context of an 〈external-subprogram〉. Such 〈bracketed-names〉 correspond to nonterminal symbols in the ISO grammar. Section numbers (e.g., §14.1.1) and rule numbers (e.g., R201) are also references to the ISO standard. All algorithms are described imperatively, as a sequence of steps that may be executed to test the precondition or perform the transformation. It is not always essential that an implementation execute these steps in the order listed; in many cases, the steps can be reordered and still produce the same results. For example, many precondition checks require a number of conditions to be checked, but these conditions are mutually disjoint, and therefore the order in which they are checked is inconsequential.","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"336 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-11-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114269235","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Compiler support for the fortran 2003 and 2008 standards revision 6","authors":"I. Chivers, J. Sleightholme","doi":"10.1145/1883575.1883578","DOIUrl":"https://doi.org/10.1145/1883575.1883578","url":null,"abstract":"","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"43 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-11-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133401549","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Since its inception in 1956 Fortran, and indeed FORTRAN, has been the computational language of science and engineering. Through Fortran aeroplanes fly, drugs are designed and nuclear reactors react. But though codes from the original manual still look familiar [1] Fortran itself has changed much over the last half century and more. So how is it currently being used on modern architectures, particularly at the high end? And how has the recent (in Fortran terms!) move from serial architectures to parallel ones affected practice? And indeed how has the evolution of those parallel platforms affected practice?
{"title":"The view from the high end fortran, parallelism and the HECToR service","authors":"I. Bush","doi":"10.1145/1883575.1883576","DOIUrl":"https://doi.org/10.1145/1883575.1883576","url":null,"abstract":"Since its inception in 1956 Fortran, and indeed FORTRAN, has been the computational language of science and engineering. Through Fortran aeroplanes fly, drugs are designed and nuclear reactors react. But though codes from the original manual still look familiar [1] Fortran itself has changed much over the last half century and more. So how is it currently being used on modern architectures, particularly at the high end? And how has the recent (in Fortran terms!) move from serial architectures to parallel ones affected practice? And indeed how has the evolution of those parallel platforms affected practice?","PeriodicalId":379614,"journal":{"name":"ACM SIGPLAN Fortran Forum","volume":"4 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2010-11-12","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123224071","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：