Hubbry Logo
Source-to-source compilerSource-to-source compilerMain
Open search
Source-to-source compiler
Community hub
Source-to-source compiler
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Source-to-source compiler
Source-to-source compiler
Source-to-source compiler
View on Wikipedia
from Wikipedia

Program execution
General concepts
Types of code
Compilation strategies
Notable runtimes
Notable compilers & toolchains
Data transformation
Concepts
Transformation languages
Techniques and transforms
Applications
Related

A source-to-source translator, source-to-source compiler (S2S compiler), transcompiler, or transpiler[1][2][3] is a type of translator that takes the source code of a program written in a programming language as its input and produces an equivalent source code in the same or a different programming language, usually as an intermediate representation. A source-to-source translator converts between programming languages that operate at approximately the same level of abstraction, while a traditional compiler translates from a higher level language to a lower level language. For example, a source-to-source translator may perform a translation of a program from Python to JavaScript, while a traditional compiler translates from a language like C to assembly or Java to bytecode.[4] An automatic parallelizing compiler will frequently take in a high level language program as an input and then transform the code and annotate it with parallel code annotations (e.g., OpenMP) or language constructs (e.g. Fortran's forall statements).[2][5]

Another purpose of source-to-source-compiling is translating legacy code to use the next version of the underlying programming language or an application programming interface (API) that breaks backward compatibility. It will perform automatic code refactoring which is useful when the programs to refactor are outside the control of the original implementer (for example, converting programs from Python 2 to Python 3, or converting programs from an old API to the new API) or when the size of the program makes it impractical or time-consuming to refactor it by hand.

Transcompilers may either keep translated code structure as close to the source code as possible to ease development and debugging of the original source code or may change the structure of the original code so much that the translated code does not look like the source code.[6] There are also debugging utilities that map the transcompiled source code back to the original code; for example, the JavaScript Source Map standard[citation needed] allows mapping of the JavaScript code executed by a web browser back to the original source when the JavaScript code was, for example, minified or produced by a transcompiled-to-JavaScript language.[citation needed]

Examples include Closure Compiler, CoffeeScript, Dart, Haxe, Opal, TypeScript and Emscripten.[7]

Assembly language translators

[edit]

So called Assembly language translators are a class of source-to-source translators converting code from one assembly language into another, including (but not limited to) across different processor families and system platforms.

Intel CONV86

[edit]

Intel marketed their 16-bit processor 8086 to be source compatible to the 8080, an 8-bit processor.[8] To support this, Intel had an ISIS-II-based translator from 8080 to 8086 source code named CONV86[9][10][11][12] (also referred to as CONV-86[13] and CONVERT 86[14][15]) available to OEM customers since 1978, possibly the earliest program of this kind.[nb 1] It supported multiple levels of translation and ran at 2 MHz on an Intel Microprocessor Development System MDS-800 with 8-inch floppy drives. According to user reports, it did not work very reliably.[16][17]

SCP TRANS86

[edit]

Seattle Computer Products (SCP) offered TRANS86.COM,[15][18][19] written by Tim Paterson in 1980 while developing 86-DOS.[20][21][22] The utility could translate Intel 8080 and Zilog Z80 assembly source code (with Zilog/Mostek mnemonics) into .ASM source code for the Intel 8086 (in a format only compatible with SCP's cross-assembler ASM86 for CP/M-80), but supported only a subset of opcodes, registers and modes, and often still required significant manual correction and rework afterwards.[23][20] Also, performing only a mere transliteration,[14][18][9][10] the brute-force single-pass translator did not carry out any register and jump optimizations.[24][25] It took about 24 KB of RAM.[15] The SCP version 1 of TRANS86.COM ran on Z80-based systems.[15][18] Once 86-DOS was running, Paterson, in a self-hosting-inspired approach, utilized TRANS86 to convert itself into a program running under 86-DOS.[22][18] Numbered version 2, this was named TRANS.COM instead.[18][25][24][26][27] Later in 1982, the translator was apparently also available from Microsoft.[15][28]

Sorcim TRANS86

[edit]

Also named TRANS86, Sorcim offered an 8080 to 8086 translator as well since December 1980.[29][14] Like SCP's program it was designed to port CP/M-80 application code (in ASM, MAC, RMAC or ACT80 assembly format) to MS-DOS (in a format compatible with ACT86).[29][15][30][31] In ACT80 format it also supported a few Z80 mnemonics. The translation occurred on an instruction-by-instruction basis with some optimization applied to conditional jumps. The program ran under CP/M-80, MP/M-80 and Cromemco DOS with a minimum of 24 KB of RAM, and had no restrictions on the source file size.[15][32]

Digital Research XLT86

[edit]

Much more sophisticated and the first to introduce optimizing compiler technologies into the source translation process was Digital Research's XLT86 1.0 in September 1981. XLT86 1.1 was available by April 1982.[33] The program was written by Gary Kildall[14][34][35][36] and translated .ASM source code for the Intel 8080 processor (in a format compatible with ASM, MAC or RMAC assemblers) into .A86 source code for the 8086 (compatible with ASM86). Using global data flow analysis on 8080 register usage,[37][14][38][39] the five-phase multi-pass translator would also optimize the output for code size and take care of calling conventions (CP/M-80 BDOS calls were mapped into BDOS calls for CP/M-86), so that CP/M-80 and MP/M-80 programs could be ported to the CP/M-86 and MP/M-86 platforms automatically. XLT86.COM itself was written in PL/I-80 for CP/M-80 platforms.[40][15][33][41] The program occupied 30 KB of RAM for itself plus additional memory for the program graph. On a 64 KB memory system, the maximum source file size supported was about 6 KB,[40][15][42][33] so that larger files had to be broken down accordingly before translation.[15][33] Alternatively, XLT86 was also available for DEC VAX/VMS.[15][33] Although XLT86's input and output worked on source-code level, the translator's in-memory representation of the program and the applied code optimizing technologies set the foundation to binary recompilation.[43][44][45]

Others

[edit]

2500 AD Software offered an 8080 to 8086 source-code translator as part of their XASM suite for CP/M-80 machines with Z80 as well as for Zilog ZEUS and Olivetti PCOS systems.[46]

Since 1979, Zilog offered a Z80 to Z8000 translator as part of their PDS 8000 development system.[47][48][49][50][51][17] Advanced Micro Computers (AMC)[51][17] and 2500 AD Software offered Z80 to Z8000 translators as well.[46] The latter was named TRANS[52][53] and was available for Z80 CP/M, CP/M-86, MS-DOS and PCOS.[46]

The Z88DK development kit provides a Z80 to i486 source code translator targeting nasm named "to86.awk", written in 2008 by Stefano Bodrato.[54] It is in turn based on an 8080 to Z80 converter written in 2003 by Douglas Beattie, Jr., named "toz80.awk".[54]

In 2021, Brian Callahan wrote an 8080 CP/M 2.2 to MS-DOS source code translator targeting nasm named 8088ify.[55]

Programming language implementations

[edit]

The first implementations of some programming languages started as transcompilers, and the default implementation for some of those languages are still transcompilers. In addition to the table below, a CoffeeScript maintainer provides a list of languages that compile to JavaScript.[56]

List of transcompilers[4]
Name Source language Target language Comments
Babel ECMAScript 6+ (JavaScript) ES5
Cerberus X Cerberus JavaScript, Java, C++, C#
Cfront C++ C
ClojureScript Clojure JavaScript
CoffeeScript CoffeeScript JavaScript
Dafny Dafny C#, JavaScript, Java, C++, Go, Python
Dart Dart JavaScript
h5[57] C# JavaScript
Eiffel, via EiffelStudio Eiffel C, Common Intermediate Language
Elm Elm JavaScript
Haxe Haxe ActionScript 3, JavaScript, Java, C++, C#, PHP, Python, Lua
HipHop for PHP (HPHPc) PHP C++
J2ObjC[58] Java Objective-C
JSweet[59] Java TypeScript
Maia[60] Maia Verilog
NACA COBOL, Java COBOL, Java
mrustc Rust C Experimental compiler able to bootstrap official Rust compiler (rustc)
Nim Nim C, C++, Objective-C, JavaScript
PureScript PureScript JavaScript
ReasonML Reason JavaScript
ReScript OCaml JavaScript
Sather Sather C
Scala.js Scala JavaScript
Swiftify[61] Objective-C Swift
V V C
Vala Vala C
Visual Eiffel Eiffel C
Fable F# JavaScript
Fable Python F# Python

Porting a codebase

[edit]

When developers want to switch to a different language while retaining most of an existing codebase, it might be better to use a transcompiler compared to rewriting the whole software by hand. Depending on the quality of the transcompiler, the code may or may not need manual intervention in order to work properly. This is different from "transcompiled languages" where the specifications demand that the output source code always works without modification. All transcompilers used to port a codebase will expect manual adjustment of the output source code if there is a need to achieve maximum code quality in terms of readability and platform convention.

Tool Source language Target language Comments
2to3 script Python 2 Python 3 Even though 2to3 does its best at automating the translation process, further manual corrections are often needed.
Emscripten LLVM bytecode JavaScript This allows running C/C++ codebases in a browser for example
c2go[62] C Go Before the 1.5 release, the Go compiler was written in C. An automatic translator was developed to automatically convert the compiler codebase from C into Go.[63][64] Since Go 1.5, the "compiler and runtime are now implemented in Go and assembler, without C".
C2Rust[65] C Rust C2Rust takes C code as input and outputs unsafe Rust code, focusing on preserving compatibility with the original codebase. Several documented limitations exist for this process. Converting the resulting code to safe and idiomatic Rust code is a manual effort post translation, although an automated tool exists to ease this task.[65]
Google Web Toolkit Java program that uses a specific API JavaScript The Java code is a little bit constrained compared to normal Java code.
Js_of_ocaml[66] of Ocsigen OCaml JavaScript
J2Eif[67] Java Eiffel The resulting Eiffel code has classes and structures similar to the Java program but following Eiffel syntax and conventions.
C2Eif[68] C Eiffel The resulting Eiffel code has classes and structures that try to be as clean as possible. The tool is complete and relies on embedding the C and assembly code if it cannot translate it properly.
Skip[69] Swift Kotlin Skip is an Xcode plug-in that transpiles a Swift iOS app or library using SwiftUI into equivalent native Kotlin code for Android using Jetpack Compose.
Swiftify[70] Objective-C Swift Swiftify is an online source to source conversion tool from Objective-C into Swift. It assists developers who are migrating all or part of their iOS codebase into Swift. The conversion is aimed primarily at converting the syntax between Objective-C and Swift, and is helped because Apple took efforts to ensure compatibility between Swift and Objective-C runtimes.
Runtime Converter[71] PHP Java The Runtime Converter is an automatic tool which converts PHP source code into Java source code. There is a Java runtime library for certain features of the PHP language, as well as the ability to call into the PHP binary itself using JNI for PHP standard library and extension function calls.

Transcompiler pipelines

[edit]

A transcompiler pipeline is what results from recursive transcompiling. By stringing together multiple layers of tech, with a transcompile step between each layer, technology can be repeatedly transformed, effectively creating a distributed language independent specification.

XSLT is a general-purpose transform tool that can be used between many different technologies, to create such a derivative code pipeline.[72]

Recursive transcompiling

[edit]

Recursive transcompilation (or recursive transpiling) is the process of applying the notion of transcompiling recursively, to create a pipeline of transformations (often starting from a single source of truth) which repeatedly turn one technology into another.

By repeating this process, one can turn A → B → C → D → E → F and then back into A(v2). Some information will be preserved through this pipeline, from A → A(v2), and that information (at an abstract level) demonstrates what each of the components A–F agree on.

In each of the different versions that the transcompiler pipeline produces, that information is preserved. It might take on many different shapes and sizes, but by the time it comes back to A (v2), having been transcompiled six times in the pipeline above, the information returns to its original state.

This information which survives the transform through each format, from A–F–A(v2), is (by definition) derivative content or derivative code.

Recursive transcompilation takes advantage of the fact that transcompilers may either keep translated code as close to the source code as possible to ease development and debugging of the original source code, or else they may change the structure of the original code so much, that the translated code does not look like the source code. There are also debugging utilities that map the transcompiled source code back to the original code; for example, JavaScript source maps allow mapping of the JavaScript code executed by a web browser back to the original source in a transcompiled-to-JavaScript language.

See also

[edit]

Notes

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Source-to-source compiler

View on Grokipedia
from Grokipedia
A source-to-source compiler, also known as a transpiler, is a type of compiler that translates source code from one programming language into equivalent source code in another programming language, typically operating at the same level of abstraction rather than generating lower-level machine code. Unlike traditional compilers that produce object code or assembly, these tools generate human-readable output that can be further processed by standard compilers, facilitating tasks such as code migration, optimization, and extension of language features. The concept of source-to-source compilation emerged in the early 1980s, with one of the earliest notable examples being Digital Research's XLT86, released in 1981, which translated 8080 assembly source code into 8086-compatible assembly to support the transition to new hardware architectures under operating systems. This approach gained prominence in academic and research settings during the and , driven by the need for portable optimizations and parallelization in scientific computing, leading to infrastructure like the ROSE compiler framework developed at for transforming C/C++ and code. Subsequent advancements focused on extensible frameworks to handle complex analyses, such as data dependence and alias resolution, without requiring full generation. Source-to-source compilers are widely used today for diverse applications, including of sequential code, as seen in tools like Cetus, which applies interprocedural optimizations to programs for multi-core execution. In software maintenance, projects like employ semantic patch languages to refactor large codebases, such as the , by matching and transforming code patterns across millions of lines. For , transpilers enable modern JavaScript dialects like or to compile into standard , bridging syntactic sugar and compatibility gaps in browser environments. These tools lower barriers for compiler research by preserving high-level semantics, though they face challenges in handling intricate language features like templates or pointers that may lead to unintended interactions with downstream compilers.

Fundamentals

Definition and Purpose

A source-to-source compiler, also known as a transpiler, is a specialized type of compiler that accepts source code written in one high-level programming language as input and generates equivalent source code in another high-level programming language as output, without producing intermediate machine code or object files. This process maintains the same level of abstraction between the input and output, focusing on syntactic and structural transformations rather than low-level optimizations. Unlike traditional compilers, source-to-source compilers prioritize generating human-readable code that can be further compiled or interpreted by standard tools for the target language. The primary purpose of source-to-source compilers is to enable and migration across different programming languages or versions, allowing developers to adapt existing software to new environments without rewriting from scratch. They facilitate the integration of modern language features into legacy codebases, support cross-platform development by translating code to languages with better platform compatibility, and aid in automated code analysis, transformation, and optimization tasks such as parallelization. By operating at the source level, these compilers enhance debuggability and , as the output remains expressive and editable by humans. Key characteristics of source-to-source compilers include the preservation of the original program's semantics—ensuring functional equivalence—while adapting syntax and idioms to the target language. They typically employ an , such as an (AST), for parsing, analysis, and code generation, which allows for modular transformations. This approach contrasts with binary-focused compilation by emphasizing readability over performance at the translation stage.

Comparison to Traditional Compilers

Source-to-source compilers differ fundamentally from traditional compilers in their output format and target abstraction level. Traditional compilers translate high-level source code into low-level machine code or bytecode suitable for direct execution by hardware or virtual machines, such as converting C to assembly via GCC. In contrast, source-to-source compilers generate equivalent source code in another high-level programming language, maintaining human readability and operating at a similar level of abstraction, for instance, transforming C++ to C or TypeScript to JavaScript. This structural distinction enables source-to-source tools to focus on language interoperability rather than hardware-specific optimization. The compilation process for source-to-source compilers mirrors the early phases of traditional compilers but diverges in the backend. Both involve to tokenize input, syntactic analysis to build an , and semantic analysis to verify meaning and consistency. However, source-to-source compilers then perform intermediate code generation—often in a structured format like three-address code or XML—and apply machine-independent optimizations before translating to the target high-level language, frequently reusing the frontend of existing compilers for parsing. Traditional compilers, by comparison, proceed to backend phases that include , instruction selection, and assembly code emission tailored to specific architectures. This source-level code generation allows for easier integration into development workflows but limits access to hardware-specific transformations. Source-to-source compilers offer several advantages over traditional ones, particularly in and flexibility. The human-readable output facilitates and manual refinement, as developers can inspect and modify the generated code directly, unlike opaque . They also enhance portability by allowing code to be retargeted to different compilers or ecosystems without recompilation from scratch, supporting iterative development in polyglot environments. However, a key disadvantage is the potential forfeiture of low-level optimizations, such as or cache-aware transformations, which traditional compilers can apply during backend processing, potentially resulting in less efficient runtime performance. Unlike interpreters, which execute source code line-by-line without producing a separate artifact, source-to-source compilers perform a complete upfront akin to traditional compilers, generating a standalone output program for subsequent compilation or execution. This batch-processing approach ensures semantic equivalence but avoids the runtime overhead of interpretation. In modern usage, the term "transpiler" is often preferred for source-to-source compilers to emphasize their distinction from binary-targeting traditional compilers, highlighting their role in high-level language migration.

Historical Development

Early Assembly Translators

The origins of source-to-source compilation trace back to the late 1970s and early 1980s, when the rapid evolution of microprocessor architectures, particularly the shift from 8-bit processors like the to 16-bit models such as the 8086, created a need for tools to port existing low-level software without full rewrites. These early assembly translators focused on converting assembly code between architectures, preserving functionality while addressing differences in instruction sets, registers, and addressing modes. Academic experiments in the 1970s explored formalisms for translator interactions, providing conceptual foundations for handling low-level language mappings, though practical implementations were limited at the time. By the early 1980s, commercial tools emerged primarily for the x86 family, enabling developers to migrate -based applications to emerging 16-bit environments like and . 's CONV86, released in February 1980 as part of the MCS-86 development system under ISIS-II, converted error-free 8080/8085 assembly source files to 8086 assembly by mapping instructions (e.g., ADD A,B to ADD AL,CH), registers (e.g., A to AL), and flags, while generating caution messages for manual review of ambiguities like symbol types or stack handling. Seattle Computer Products (SCP) introduced TRANS86 in 1980, authored by during the development of ; a variant for Z80 to 8086 translation accepted Z80 source files using / mnemonics and produced 8086 equivalents, handling conditional assembly and requiring input free of assembler errors. Sorcim's TRANS86, available since December 1980, similarly targeted 8080 to 8086 conversion for -80 portability. Digital Research's XLT86, released in September 1981, advanced these efforts with optimization features, employing global to improve register allocation and minimize instruction count, translating at 120-150 lines per minute on a 4 MHz Z80 system while supporting and MP/M environments. These tools facilitated the rapid migration of DOS-era software, allowing thousands of 8-bit applications to be adapted for 16-bit platforms with minimal manual intervention, though challenges persisted in areas like differences and segment management, often necessitating post-translation edits. Outside the ecosystem, similar transitions occurred; for instance, the architectural similarities between the PDP-11 and VAX enabled straightforward manual conversion of PDP-11 assembly programs to VAX equivalents, highlighting the era's emphasis on compatibility over fully automated translation. Overall, these early translators demonstrated the viability of source-to-source approaches for low-level code, setting precedents for handling architectural shifts in subsequent decades.

Emergence in High-Level Languages

The emergence of source-to-source compilers in high-level languages marked a significant evolution from earlier low-level assembly translators, beginning in the mid-1980s as new paradigms like object-orientation gained traction. A pivotal milestone was the 1983 introduction of by at , which translated code into to leverage existing C compilers for portability and rapid development. This approach addressed the absence of native C++ backends, enabling early adoption despite the immaturity of the language. In the 1980s, similar translators appeared for other emerging languages, such as , originally developed as an object-oriented extension to by and at Productivity Products International (PPI). The initial implementation functioned as a that translated Objective-C's Smalltalk-inspired syntax into standard , facilitating integration with Unix environments and legacy systems without requiring full compiler redesigns. By the 1990s, tools like f2c extended this paradigm to legacy languages, converting Fortran 77 code to to modernize scientific computing applications and improve interoperability on diverse platforms. Driving factors included the scarcity of native compilers for novel high-level languages and the need for seamless integration, such as compiling C++ subsets alongside codebases. Technically, these compilers evolved to incorporate abstract syntax trees (ASTs) to parse source code and preserve semantics during translation, ensuring the generated output maintained the original program's behavior. However, challenges arose in handling advanced features; for instance, Cfront's implementation of templates in version 3.0 (1991) required complex instantiation mechanisms, while exceptions planned for version 4.0 (1993) demanded intricate runtime support to propagate errors across translated C code without semantic loss. By the early 2000s, source-to-source techniques proliferated in domain-specific contexts, exemplified by ' Real-Time Workshop, which generated C code from and models for embedded systems deployment. This period also saw growing application to scripting languages, where transpilers facilitated feature extension and cross-environment compatibility, laying groundwork for later web-focused tools.

Key Examples

Assembly-to-Assembly Tools

Assembly-to-assembly tools emerged in the late 1970s and early 1980s to facilitate the migration of software from 8-bit to 16-bit architectures, particularly during the transition from / systems to the 8086. These translators automated the conversion of assembly by mapping opcodes, registers, and basic control structures, though they often produced output requiring human intervention for full functionality. Key examples include tools developed by , Computer Products, Sorcim, and , each tailored to specific ecosystems like . Intel's CONV86, released around 1980-1981, automated the migration of 8080/8085 assembly code to 8086 assembly, handling mapping and register translations such as converting the 8080's A register to the 8086's AX. It processed line-by-line, expanding each 8080 instruction into one or more 8086 equivalents while preserving compatibility features like little-endian byte order and flag behaviors inherited from earlier designs. However, CONV86 required manual tweaks for timing-sensitive code, self-modifying instructions, and 8085-specific operations like RIM/SIM, as it could not fully resolve architectural differences; the resulting code was often 25% larger due to the 8086's longer instructions and suboptimal mappings. Seattle Computer Products' (SCP) TRANS86, developed in 1980 by during the creation of , focused on porting CP/M-80 applications, including spreadsheet software like , to 8086-based systems. Released commercially around 1982, it improved upon CONV86 by incorporating additional optimization passes to better align translated code with the target architecture's memory model and handling. TRANS86 emphasized compatibility with , enabling smoother transitions for business applications but still necessitating post-translation adjustments for performance. Sorcim's TRANS86, available since December 1980, served as a variant optimized for and porting within the environment. It prioritized code size reduction through efficient instruction substitutions and optimizations, producing more compact 8086 output compared to basic mappers, which was critical for resource-constrained 16-bit systems. Like its contemporaries, it supported direct translation of common 8080 constructs but relied on user verification for complex data structures. Digital Research's XLT86, part of the CP/M ecosystem and documented in its 1981 user's guide, translated 8080/Z80 assembly to 8086 code using global to optimize and reduce instruction counts. It supported cross-architecture extensions by accommodating and MP/M-80 specifics, such as system calls and conditional assembly, while generating output compatible with and MP/M-86; translation rates reached 120-150 lines per minute on a 4 MHz Z80 host. XLT86 included parameters for compact memory models and block tracing, facilitating during migration. In academia during the , prototypes like early retargetable assemblers explored automated remapping between mainframe architectures, influencing commercial designs through concepts of modular translation pipelines. Common limitations across these tools involved incomplete handling of architecture-specific idioms, such as vectors or addressing modes unique to the source processor, often resulting in output that required human review for correctness and efficiency. Despite these constraints, assembly-to-assembly tools played a pivotal role in accelerating early adoption by enabling rapid software porting to new platforms.

High-Level Transpilers

High-level transpilers, also known as source-to-source compilers for high-level languages, enable the transformation of code between languages or dialects at a similar level, facilitating compatibility, optimization, and feature extension without delving into low-level . These tools have become essential in modern , particularly for web ecosystems where browser inconsistencies necessitate , and in where legacy code migration demands precise semantic preservation. By generating readable output in target languages like or enhanced variants of C++, they support rapid iteration while maintaining developer productivity. In , Babel, originally released as 6to5 in 2014 and rebranded in 2015, transpiles modern features (ES6 and beyond) into ES5-compatible to ensure broad browser support. Similarly, the compiler (tsc), introduced by in 2012 with its 1.0 stable release in 2014, converts —a typed superset of —into plain while performing static type checking to catch errors early in large-scale applications. , launched in 2009, provides such as significant whitespace and simplified function definitions, compiling one-to-one into clean to make the language more approachable without runtime overhead. Google's Dart, announced in 2011, includes a compiler that translates Dart code to , allowing developers to leverage Dart's object-oriented features and asynchronous programming in web environments. For systems and legacy code, the framework, developed at since 1993, supports source-to-source transformations for C, C++ (up to ), Fortran, and other languages, enabling advanced analysis, optimization, and enhancements like parallelization for . This builds on historical precursors like , AT&T's 1985 source-to-source compiler that translated early C++ ("C with Classes") to C, influencing subsequent object-oriented language implementations. , released in 2011, compiles C and C++ code via to or , facilitating the porting of native applications to web platforms with support for APIs like and SDL. In domain-specific contexts, , an construction language from UC Berkeley introduced in 2012, uses embedded Scala to generate synthesizable for digital circuits, promoting reusable and parameterized hardware designs through paradigms. Recent trends up to 2025 incorporate AI assistance to improve transpilation accuracy, such as frameworks using large language models (LLMs) for iterative error correction in converting C to , achieving higher fidelity in safety-critical translations. For instance, DARPA's program, initiated in 2024, aims to automate the translation of legacy C and C++ code to using AI techniques to enhance in critical systems. Tools like CodeConverter leverage AI for Rust-to-C conversions, addressing semantic gaps in performance-sensitive code. These transpilers demonstrate strong adoption; for instance, Babel's core packages exceed 70 million npm downloads weekly as of late 2024, powering a significant portion of projects for feature polyfilling. However, challenges persist in maintaining for complex features, including preserving style, handling language-specific idioms, and avoiding unintended modifications due to the intricate semantics of high-level constructs like templates or concurrency models.

Applications

Code Porting and Migration

Source-to-source compilers enable code porting and migration by automating the translation of syntax and semantics from one high-level language to another, preserving the original program's structure and intent while adapting it to the target language's paradigms. This process typically involves the to build an (AST), performing semantic analysis to map constructs like data types, control flows, and function calls to equivalents in the target language, and generating new that compiles natively in the destination environment. Following automation, the output undergoes validation through testing and , often requiring manual refinement to address language-specific nuances or performance issues. A notable case study is the porting of Fortran 77 code to for NASA's Toolkit in the 1990s, where the f2c translator converted over 79,000 lines of legacy Fortran scientific computing code. This effort supported NASA's space mission analysis tools by leveraging f2c's automated conversion of Fortran's array operations and subroutines into equivalents. Similarly, in the banking sector during the 2000s, tools facilitated migrations of applications to , as seen in provider FIS, which used Visual COBOL to compile mainframe directly to , enabling modernization of systems while retaining core functionality. These migrations offer significant benefits, including a substantial reduction in manual coding effort by automating repetitive translations and preserving the original embedded in legacy systems. For instance, f2c's application at avoided routine-by-routine manual , allowing focus on integration rather than recreation. Such approaches minimize errors from human intervention and accelerate deployment to new platforms. However, challenges arise when source languages feature idioms without direct equivalents in the target, such as C's unrestricted pointer arithmetic, which lacks safe counterparts in memory-safe languages like and requires additional static analysis to infer bounds and prevent . Translating these demands careful handling of implicit assumptions, like pointer offsets, to ensure and avoid runtime panics in the generated code. Real-world metrics highlight the scale: NASA's f2c-based porting handled over 79,000 lines efficiently. Tools like further exemplify this for C to JavaScript porting in web applications.

Optimization and Feature Adaptation

Source-to-source compilers facilitate optimization by leveraging (AST) manipulations to refactor code for enhanced performance without altering the original language semantics. For instance, AST-based techniques enable , where iterative structures in C code are expanded into explicit sequences to reduce overhead from branch predictions and increment operations, potentially yielding runtime improvements of up to 50% in benchmarks involving numerical computations. Similarly, frameworks like OptiTrust apply source-to-source transformations such as loop tiling and data layout restructuring (e.g., array-of-structures to structure-of-arrays conversions) to C programs, achieving throughput gains of around 19% in simulations like methods. Feature adaptation through source-to-source compilation often involves polyfilling modern constructs for legacy environments. Babel, a prominent transpiler, uses plugins to convert ES2020 features like async/await into compatible older syntax, such as generator functions or chains, ensuring asynchronous code runs in environments lacking native support while preserving functionality. In C++, the framework, developed under U.S. Department of Energy (DOE) projects in the , supports AST-driven injections of checks, such as runtime assertions or bounds validation, into existing codebases to enhance robustness without manual rewrites. 's infrastructure has been applied in DOE laboratories for optimizing large-scale applications, including empirical tuning that selects parameterized transformations to boost execution speed on high-performance architectures. Adaptation scenarios extend to backporting advanced language features and generating specialized code variants. The compiler transpiles generics—parametric types for reusable components—into plain by type erasure, producing idiomatic functions that maintain flexibility across browser environments without runtime overhead. For domain-specific adaptations, tools like sqlc employ source-to-source generation to convert SQL queries into type-safe ORM method calls in languages such as Go, automating boilerplate while ensuring compile-time verification of query structures. These approaches improve maintainability by enforcing standardized idioms and reducing error-prone manual adaptations. Looking ahead, integration of into source-to-source compilers is emerging by , enabling automated optimization through -driven transformation selection, as seen in AI-aware frameworks that learn optimal code patterns from data to supercharge workloads.

Advanced Techniques

Pipeline Architectures

Pipeline architectures in source-to-source compilers involve a sequence of processing stages that transform input code through multiple passes, enabling complex translations that a single stage might not handle efficiently. Typically, this begins with a frontend that parses the source code into an (IR), followed by one or more transformation stages that analyze and modify the IR, and concludes with a backend that generates the target source code. This linear, modular setup allows for repeatable chains across languages, such as parsing C++ code, applying optimizations, and outputting equivalent optimized C++ source. Key components include frontends for language-specific parsing, IRs for abstract representation of code structure, and extensible systems like plugins for custom transformations. For instance, the compiler framework uses the Edison Design Group (EDG) frontend to parse and code into an initial representation, which is then converted to ROSE's IR to capture detailed semantic information for analysis and rewriting in subsequent stages. Similarly, Babel's transformation pipeline uses an (AST) as the central IR, where plugins are applied sequentially to traverse and modify the tree, providing extensibility for JavaScript-specific features like ES6-to-ES5 conversion. These architectures offer benefits such as modularity, which promotes across projects by isolating stages for independent development and testing. In polyglot codebases mixing languages like C++ and , pipelines facilitate unified handling through shared IRs, reducing redundancy in toolchains. exemplifies this by supporting multiple frontends while reusing transformation logic, enabling developers to build custom analyzers without reimplementing parsing. Examples include experimental LLVM-based tools like C2Rust, which leverages Clang's AST (an LLVM component) in a multi-stage pipeline to translate C code to idiomatic Rust, involving parsing, type inference, and code generation passes developed in the late 2010s. In web development, Webpack integrates transpilers like Babel into its loader pipeline, where modules undergo chained transformations—such as TypeScript to JavaScript transpilation—before bundling, supporting polyglot frontends efficiently. However, pipeline architectures introduce drawbacks, including heightened complexity from managing inter-stage data flow and the risk of error propagation, where issues in early stages like can amplify in later transformations, complicating .

Recursive and Multi-Stage Methods

Recursive transcompiling involves repeatedly applying a source-to-source compiler to its own output, enabling iterative refinement of code to resolve dependencies, approximate complex structures, or specialize programs with partial information. This approach extends traditional one-pass transformations by feeding generated code back into the compiler, often to handle self-referential elements or evolve approximations toward a form. Key methods include , where the compiler applies transformations until the output converges to a least fixed point, ensuring termination on monotone functions over complete lattices. Such iteration is central to partial evaluation, a technique that partially executes programs with static inputs to produce optimized residuals, and to controlled macro expansion, where definitions are recursively substituted until no further expansions occur, preventing cycles through hygiene rules or depth limits. In partial evaluation, binding-time analysis uses fixed-point computation to classify expressions as static or dynamic, enabling recursive unfolding of loops and calls. Early examples appear in 1980s assembly-level optimizers, such as a recursive optimizer integrated into a Coral 66 compiler's code generator, which pipelined intermediate code sequences across activation levels to mimic multi-pass refinement without full recompilation. In modern contexts, partial evaluation frameworks like those for Scheme or demonstrate recursive specialization, unfolding static recursive calls (e.g., in the function via the ) to generate efficient . Emerging 2020s prototypes in AI-assisted code generation, such as the See-Saw mechanism, employ recursion to iteratively generate and synchronize interdependent files, alternating between main code updates and dependency creation for scalable project assembly. These methods excel at managing self-referential code, such as mutually recursive functions, by iteratively resolving interdependencies, and achieve higher fidelity in approximations through successive refinements, as seen in partial evaluation's polyvariant specialization that produces multiple tailored versions. However, they risk infinite loops without safeguards like termination checks or bounded iterations, incur high computational costs from repeated passes, and demand explicit convergence criteria, such as fixed-point detection in abstract domains.

References

  1. https://diposit.ub.edu/dspace/bitstream/2445/122786/3/memoria.pdf
  2. https://engineering.purdue.edu/Cetus/Documentation/manual/manual.html
  3. http://www.bitsavers.org/pdf/digitalResearch/cpm/XLT86_Users_Guide_Sep81.pdf
  4. http://rosecompiler.org/
  5. https://engineering.purdue.edu/paramnt/publications/IJPP-Cetus.pdf
  6. https://sites.udel.edu/cetus-cid/
  7. https://drops.dagstuhl.de/storage/01oasics/oasics-vol107-parma-ditam2023/OASIcs.PARMA-DITAM.2023.2/OASIcs.PARMA-DITAM.2023.2.pdf
  8. http://injoit.ru/index.php/j1/article/download/295/242
  9. https://www.sciencedirect.com/science/article/pii/S0164121224000499
  10. https://engineering.purdue.edu/Cetus/cetusworkshop/papers/4-1.pdf
  11. https://www.ijcsit.com/docs/Volume%206/vol6issue02/ijcsit20150602159.pdf
  12. https://www.geeksforgeeks.org/compiler-design/source-to-source-compiler/
  13. https://dl.acm.org/doi/pdf/10.1145/355598.362740
  14. http://www.bitsavers.org/pdf/intel/ISIS_II/9800642-02_MCS-86_Assembly_Language_Converter_Feb80.pdf
  15. http://www.bitsavers.org/pdf/seattleComputer/Z80_to_8086_Translator.pdf
  16. https://bitsavers.org/pdf/dec/vax/EG-21731-18_VAX_Product_Sales_Guide_Apr82.pdf
  17. https://www.stroustrup.com/hopl2.pdf
  18. https://doi.org/10.1145/3386332
  19. https://www.netlib.org/f2c/f2c.pdf
  20. https://www.mathworks.com/content/dam/mathworks/mathworks-dot-com/solutions/automotive/files/macde2008/08_themathworks_pcg_timemaschine.pdf
  21. http://www.righto.com/2023/08/datapoint-to-8086.html
  22. https://retrocomputing.stackexchange.com/questions/19613/z80-to-x86-asm-translator
  23. https://www.usenix.org/system/files/sec23winter-prepub-381-dramko.pdf
  24. https://dev.to/letanure/babel-6-first-look-at-the-new-transpiler-3ple
  25. https://devblogs.microsoft.com/typescript/announcing-typescript-1-0/
  26. https://coffeescript.org/
  27. https://www.wired.com/2011/10/google-throws-new-dart-programming-language-at-the-web/
  28. https://www.researchgate.net/publication/221320724_Emscripten_an_LLVM-to-JavaScript_compiler
  29. https://aspire.eecs.berkeley.edu/chisel-archive/chisel-dac2012.pdf
  30. https://arxiv.org/html/2505.10708v1
  31. https://skywork.ai/skypage/en/rust-to-c-conversion/1977627442484285440
  32. https://www.npmjs.com/package/@babel/core
  33. https://www.sciencedirect.com/science/article/pii/S0167642307000718
  34. https://emscripten.org/docs/porting/index.html
  35. https://jacobfilipp.com/DrDobbs/articles/DDJ/1999/9912/9912h/9912h.htm
  36. https://naif.jpl.nasa.gov/pub/naif/toolkit_docs/Tutorials/pdf/individual_docs/08_intro_to_toolkit.pdf
  37. https://www.microfocus.com/media/case-study/fis-cs.pdf
  38. https://arxiv.org/pdf/2412.15042
  39. https://libraopen.lib.virginia.edu/downloads/1544bp163
  40. https://inria.hal.science/hal-03773485v1/document/
  41. https://babeljs.io/docs/babel-polyfill
  42. https://www.osti.gov/servlets/purl/962808
  43. https://computing.llnl.gov/projects/rose-compiler
  44. https://sqlc.dev/
  45. https://babeljs.io/docs/plugins
  46. https://aicompetence.org/ai-aware-compilers-supercharge-the-ml-stack/
  47. https://github.com/jamiebuilds/babel-handbook
  48. https://github.com/rose-compiler/rose/wiki
  49. https://github.com/immunant/c2rust
  50. https://webpack.js.org/concepts/loaders/
  51. https://www.meegle.com/en_us/topics/compiler-design/compiler-design-risks
  52. https://www.cs.utexas.edu/~novak/jonesgomardsestoft.pdf
  53. https://www.utdallas.edu/~gupta/courses/apl/neil.pdf
  54. https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380100507
  55. https://arxiv.org/abs/2411.10861
Add your contribution
Related Hubs
User Avatar
No comments yet.