Technical Summary: Migrating Esope to Fortran 2008 using Model Transformations

1. Problem Statement

The paper addresses the challenge of migrating legacy industrial software written in FORTRAN 77 extended with a proprietary language called Esope to Fortran 2008.

Context and Motivation:

• Legacy Dependency: Framatome, a nuclear energy leader, relies on critical systems built on FORTRAN 77 and Esope.
• Esope Limitations: Created in the early 1980s by the CEA, Esope acts as a transpiler to FORTRAN 77, adding features like dynamic memory allocation and structured data types (segments) via a custom heap management system. It relies on "double indirection" (managing pointers as indices in a large array of descriptors) to ensure that resizing data structures does not change the pointer addresses held by developers.
• The Crisis: Modern Fortran compilers are incompatible with the low-level memory management "tricks" used by Esope. While the code currently compiles, it cannot be highly optimized, posing a risk to High Performance Computing (HPC) performance and long-term compilability.
• The Goal: Migrate the codebase to Fortran 2008 to ensure longevity, compatibility, and maintainability.
• Specific Challenges:
  • Abstraction Preservation: The migration must not force developers to deal with low-level memory management (pointers, heap offsets) but should preserve the high-level abstractions provided by Esope.
  • Code Inflation: Esope instructions often expand significantly (up to 100x) into Fortran 2008 code.
  • Semantic Gaps: Fortran 2008 lacks native support for Esope's specific pointer behaviors (e.g., negative pointers for read-only segments), implicit typing conventions, and "double indirection" mechanisms.
  • Readability: The generated code must remain readable and familiar to physicists who are experts in FORTRAN 77 but not necessarily in modern Fortran constructs.

2. Methodology

The authors propose a Model-Driven Engineering (MDE) approach, utilizing a hybrid of Model-to-Model (M2M) and Model-to-Text (M2T) transformations.

2.1 Architecture and Tools

• Metamodels: The solution uses the Famix metamodel (for high-level dependencies) and the FAST (Famix AST) metamodel (for detailed Abstract Syntax Tree representation).
• Parsing: Since no formal grammar existed for Esope, a custom "island grammar" parser was developed. It converts Esope code into valid FORTRAN 77 by commenting out Esope-specific commands, allowing a standard FORTRAN 77 parser to generate the AST. A second pass extracts the commented Esope commands to build the complete AST.
• Transformation Strategy:
  • Visitor Pattern: Used to traverse the source AST (Esope/FORTRAN 77) and generate a target AST (Fortran 2008).
  • String Templates: To handle the massive code expansion (e.g., generating boilerplate for every segment command), the authors use string templates with placeholders. These strings are treated as nodes within the AST via traits, allowing the generation of large code chunks without manually constructing complex AST nodes for every line.

2.2 Key Technical Solutions

The paper details specific strategies for migrating core Esope concepts to Fortran 2008:

1. Segment to Derived Type:

   • Esope SEGMENT definitions are mapped to Fortran 2008 TYPE definitions within modules.
   • To support polymorphism (graphs of heterogeneous segments), all derived types inherit from an abstract segment type containing deferred procedures (abstract methods) for common commands.

2. Dynamic Arrays and Dimensioning:

   • Dimensioning Variables: In Esope, these were global variables. In the migration, they are declared as private fields within the derived type to enforce encapsulation.
   • Dimensioning Expressions: Implemented as private functions within the module to calculate array sizes.
   • Array Fields: Instead of allocatable arrays (which auto-resize on assignment), the authors chose deferred-shape pointers (pointer :: arr(:)). This allows explicit control over resizing via a dedicated segadj command, matching Esope's behavior and preventing unintended memory reallocation.

3. Pointer and "Double Indirection" Mechanism:

   • To preserve the "double indirection" (where a developer's pointer never changes even if the underlying data moves), the authors implemented a large array of derived types.
   • "Pointers" in the migrated code are actually integer indexes into this array, rather than Fortran pointers. This maintains the semantic behavior where resizing a segment does not invalidate the reference held by the developer.

4. Command Migration:

   • segini / segadj: Migrated as specific subroutines accepting the dimensioning variables as explicit parameters.
   • segsup / segprt: Migrated as abstract methods in the base segment type.
   • segdes / segact (Swap): Removed, as modern Fortran handles memory swapping automatically.
   • Notation: Esope's dot notation (p.field) and slash notation (p.arr(/1)) are translated to standard Fortran syntax (p%field and size(p%arr, dim=1)).

5. Cleanup and Standardization:

   • Implicit Typing: All implicit statements are removed and replaced with implicit none. Variable types are inferred using standard naming rules (i-n for integers) and explicitly declared.
   • Preprocessor: #include directives are resolved by copying content directly into the host file or migrating segment definitions to their own modules. #define and #ifdef are left to the C preprocessor.
   • Parameter Intent: The tool analyzes parameter usage (read/write patterns) to assign intent(in), intent(out), or intent(inout) attributes, a feature missing in FORTRAN 77.

3. Key Contributions

The paper claims four primary contributions:

1. Implementation of Extensible Structured Types: A Fortran 2008 implementation of structured data types that can be resized, mimicking Esope's capabilities.
2. Abstraction Preservation: A mechanism that frees developers from handling pointer changes after resizing, effectively replicating Esope's "double indirection" logic within Fortran 2008.
3. Tool Positioning: A clear positioning of this approach within the landscape of model transformation tools, specifically highlighting the hybridization of visitor and string template techniques for Model-to-Text generation.
4. Scalable Code Generation: A transformation technique using string templates to efficiently generate large chunks of similar boilerplate code, addressing the issue of code inflation.

4. Results

The approach was validated on a "Bookstore" use case (simulating a library with users, books, and loans).

• Scale: The migration processed 23 files containing 1,611 lines of Esope code, resulting in 23 files with 3,545 lines of Fortran 2008 code.
• Correctness: The migrated code compiles and runs without error, producing identical output to the original Esope application.
• Performance:
  • The migrated Fortran 2008 code was significantly faster than the original Esope code.
  • Esope vs. Fortran 2008: The total execution time for Fortran 2008 was less than half that of the original Esope.
  • Memory: Fortran 2008 utilized less memory. The authors noted that Esope's system time was high due to its default 2GB heap allocation; even when reduced to 32MB, Esope remained slower in "User" time.
  • Optimization: Removing invariant checks from the migrated code (Fortran 2008*) made it approximately three times faster than the reduced-memory Esope version (Esope*).
• Caveat: The authors explicitly state that the "Bookstore" example is small and may not fully represent the complexity of Framatome's real-world HPC applications, so performance gains should be viewed with caution.

5. Significance and Limitations

Significance:
The paper demonstrates that it is possible to automatically migrate complex, proprietary legacy extensions (Esope) to modern standards (Fortran 2008) without losing the high-level abstractions that developers rely on. It proves that model-driven techniques can handle the semantic gap between a transpiler-based legacy system and a modern language, ensuring the longevity of critical industrial software.

Limitations and Future Work:

• Code Inflation: The generated Fortran 2008 modules contain verbose boilerplate for every segment command, making them difficult to read and maintain. The authors propose using a companion Domain Specific Language (DSL) (e.g., TOML or a simplified syntax) to define segments, which would then be converted to the verbose Fortran code.
• Incomplete Coverage: The current parser and transformation do not handle all Esope constructs (e.g., specific segini or segact variations) and rely on external tools for outdated FORTRAN 77 constructs like GOTO, COMMON, and EQUIVALENCE.
• Comment Handling: The migration currently struggles with preserving comments associated with specific entities when code is moved (e.g., from an included file to a module).
• Validation Scope: The evaluation was limited to a single, relatively small use case created by one developer, rather than the full, complex, multi-developer industrial codebase.

The paper concludes that while the migration is successful in preserving functionality and improving performance, further work is needed to improve the maintainability of the generated code and to scale the solution to larger, more complex industrial applications.