Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #3695 > unrolled thread
| Started by | John R Levine <johnl@taugh.com> |
|---|---|
| First post | 2025-09-01 11:16 +0200 |
| Last post | 2025-09-02 12:45 +0100 |
| Articles | 2 — 2 participants |
Back to article view | Back to comp.compilers
Paper: CrossTL: A Universal Programming Language Translator with Unified Intermediate Representation John R Levine <johnl@taugh.com> - 2025-09-01 11:16 +0200
Re: Paper: CrossTL: A Universal Programming Language Translator with Unified Intermediate Representation Derek <derek@shape-of-code.com> - 2025-09-02 12:45 +0100
| From | John R Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-09-01 11:16 +0200 |
| Subject | Paper: CrossTL: A Universal Programming Language Translator with Unified Intermediate Representation |
| Message-ID | <25-09-001@comp.compilers> |
This is a very old idea, dating back to UNCOL in the late 1950s. Invent a universal intermediate language so you just have to write a front end or back end per input or output language. It works somewhat when the inputs and outputs are semantically close enough, viz the LLVM intermediate language, but has always hit the wall when the languages are too different. https://arxiv.org/abs/2508.21256 Abstract We present CrossTL, a universal programming language translator enabling bidirectional translation between multiple languages through a unified intermediate representation called CrossGL. Traditional approaches require separate translators for each language pair, leading to exponential complexity growth. CrossTL uses a single universal IR to facilitate translations between CUDA, HIP, Metal, DirectX HLSL, OpenGL GLSL, Vulkan SPIR-V, Rust, and Mojo, with Slang support in development. Our system consists of: language-specific lexers/parsers converting source code to ASTs, bidirectional CrossGL translation modules implementing ToCrossGLConverter classes for importing code and CodeGen classes for target generation, and comprehensive backend implementations handling full translation pipelines. We demonstrate effectiveness through comprehensive evaluation across programming domains, achieving successful compilation and execution across all supported backends. The universal IR design enables adding new languages with minimal effort, requiring only language-specific frontend/backend components. Our contributions include: (1) a unified IR capturing semantics of multiple programming paradigms, (2) a modular architecture enabling extensibility, (3) a comprehensive framework supporting GPU compute, graphics programming, and systems languages, and (4) empirical validation demonstrating practical viability of universal code translation. CrossTL represents a significant step toward language-agnostic programming, enabling write-once, deploy-everywhere development. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [next] | [standalone]
| From | Derek <derek@shape-of-code.com> |
|---|---|
| Date | 2025-09-02 12:45 +0100 |
| Message-ID | <25-09-002@comp.compilers> |
| In reply to | #3695 |
John, > Invent a universal intermediate language so you just have to write a front > end or back end per input or output language. It works somewhat when the > inputs and outputs are semantically close enough, viz the LLVM > intermediate language, but has always hit the wall when the languages are > too different. The purpose of a universal intermediate language is to reduce the cost of 1-to-1 translation from an n^2 problem to a linear problem in n. An alternative approach is to brute force it by training an LLM on lots of code. "In the WMT25 competition, the model achieved first place in 30 out of the 31 language categories it participated in." https://github.com/Tencent-Hunyuan/Hunyuan-MT [That model translates natural languages, like Ukranian to Mongolian. I don't see how that's relevant to translating computer languages. In the former case, pretty close is useful, in the latter, pretty close is a program that doesn't work. -John]
[toc] | [prev] | [standalone]
Back to top | Article view | comp.compilers
csiph-web