Fuzion Toolchain Design

The goal of the Fuzion toolchain is to convert Fuzion source code into highly-optimized binary applications and to detect and report errors while doing this. Also, the toolchain should provide intermediate representations of the application as an input for development tools such as static analyzers.

Fuzion Front End

The purpose of the Fuzion Front End fufe is to convert one or several fuzion source code files into a fuzion module file fum. A module file can either be an application module, which only export one single feature as the application entry point, or a library module, that provides an APIs to be used by other modules.

The tasks performed by fufe include

• Parsing of the source code
• Checking for compile-time errors: type checking, etc.
• Replacing syntactic sugar by features and calls
• Checking feature visibility on calls, visibility in a module will be reduced to exported or internal.
• Checking race-freedom for library modules (maybe limited to modules or features that are marked to be thread-safe?)

Fuzion Module File

A Fuzion module file contains

• Feature declarations, including
  • feature names
  • formal argument lists
  • formal generic argument lists
  • inheritance calls
  • feature contracts (pre- and post-conditions)
  • feature implementation: field or routine
• Feature code for routines consisting of calls and control statements (if, match)
• List of exported (public) library features
• List of dependencies on other modules

The Fuzion code does not contain operations on basic types such as adding two integers. Instead, these operations are implemented by intrinsic features. Tools working on module files hence do not need to implement support for many intermediate commands, they work mostly on feature calls. As needed, semantic descriptions of intrinsics can be provided for these tools.

Fuzion Middle End

The purpose of the Fuzion middle end fume is to link an application module together with several library modules into a Fuzion app file fapp.

The tasks performed by fume include

• Collecting all fuzion modules the application depends upon
• Replacing formal generic arguments by actual generics.
• Smart linking: Removing unreachable code
• Removing contracts that have not been enabled for analysis or run-time checking
• Performing static code analysis to detect errors such as race conditions.
• Packaging the modules into a fuzion fapp.

Fuzion Application File

A Fuzion application file contains

• Run-time classes, i.e., features combined with actual generic arguments
• Feature declarations, including
  • feature names
  • formal argument lists
  • inheritance calls
  • contracts that were enabled for run-time checks
  • feature implementation: field or routine
• Feature code for routines consisting of calls, assignments, and control statements (if, match)
• Main entry point feature

Fuzion Application files are the basis for whole-program analysis that will be done by the Fuzion Optimizer in the next step or any other static analysis tools.

Fuzion Optimizer

The purpose of the Fuzion optimizer fuom is to perform target platform independent optimizations on a Fuzion application file.

The tasks performed by fuom include

• Compile-time evaluation
  • replace features depending on compile-time constants only by the result of their execution. To do this, the optimizer makes use of actual backends, in particular the interpreter backend, such that code to evaluate Fuzion calls does not need to be duplicated.
• Feature specialization
  • replace dynamic binding by specialized features
  • specialize features for constant arguments
• Call-graph Analysis
• Inlining
• Lifespan analysis
  • Analyze the life-time of fields
  • Analyze mutability of fields
  • Decide where to store a field depending on life-time and mutability
  • locally in stack frame of outer feature's routine
  • locally in stack frame of the a caller
  • if non-mutable, create copies for uses in closures with longer life-span
  • heap-allocate if really needed
• Replace inheritance calls by normal calls
• Replace contracts by control statements and calls
• Build tables for dynamic binding
• Replace dynamic calls by either
  • direct calls, if possible,
  • dynamic lookup followed by call, otherwise
• Replace match-expressions by conditional statements or table look ups.
• Detect and replace tail-calls

Fuzion Intermediate Representation File

A Fuzion intermediate representation file contains

• Main entry point feature
• Run-time classes, including
  • tables for dynamic binding
  • fields stored in instances
• Routines
  • formal argument lists
  • fields stored in routine's stack frame
  • intermediate code consisting of calls, assignments, conditional statements, tail-calls (jump to code start).
• Feature code for routines consisting of calls and control statements (if, match)

Fuzion Back End

The purpose of the Fuzion back end fube is to create a binary executable for a given platform. There will be different back ends for different platforms (x86, ARM, Windows, Linux, etc.) or using different technologies (LLVM, JVM, C source, OMR, etc.).

The tasks performed by fube include

• Setting up run-time data structure for classes on the target
• Creating code executable on the target for the routines in the fir file
• Performing target platform-specific optimizations
• performing low-level object- and stack layout and register allocation

Toolchain overview

Putting all the tools together, we get this data flow through the tools: