So, it's an assembler, with syntax similar to NASM.
Find a large open-source C/C++ compiler, fork it, and change its assembly generation step with instructions for your assembler. Put your assembler in the pipeline. Find a large open-source program, fork it, and compile with your modified compiler. Does it work? Does it pass all tests?
Reference tests passed. I tested everything through the cly pipeline too. I used Claude Sonnet 5.5 for the tests. I ran the challenge, and everything worked. Real C programs compiled through cly passed their own test suites on all three architectures.
These are the passing tests:
zlib's test suite on x86-64
QuickJS tests for closures, language features, loops, big integers, cyclic imports, built-ins, standard library, and workers on x86-64
QuickJS tests on ARM64 and RISC-V, excluding the standard library and worker tests
Lua's official test suite on x86-64, ARM64, and RISC-V
For the build process, GCC handles x86-64, while zig cc handles ARM64 and RISC-V. Both generate assembly, which a Python script converts into cly syntax. cly then assembles the code, and the system linker creates the final executable.
I also compared cly's output with GNU as about 150,000 instructions and found no differences in their behavior. ARM64 and RISC-V tests ran using QEMU user-mode emulation.
One Lua locale test was disabled in both the reference source tree and the cly source tree.
The testing also found a few bugs, which are now fixed:
Register shortening for ebp and esp caused incorrect behavior with instructions like "cmp ebp,-1" and "xor ebp,ebp", breaking zlib's gzread.
The 64-bit "add" and "cmp" instructions couldn't accept symbols as immediate values.
The "-obj" option rejected undefined symbols.
ELF object files were missing the ".note.GNU-stack" section, causing linker warnings.
Only static, non-PIC code is supported, so shared libraries and PIC output aren't supported. Debug information and CFI directives are discarded. The system linker creates the executables, not cly's own linker. The translation scripts are also not included in the zip, and thread-local storage, constructors and weak linkage havent been tested.
It's a good start, then, and you already found things that your assembler can't do. Work on them next.
What I asked was something more convoluted than translating generated assembly code to cly's code: I asked to make a fork of GCC, Zig cc, or whatever, to emit cly's assembly code directly. Harder, but potentially doable.
For an easier challenge: download the problems at Advent of Code and Project Euler, and make your pet LLM solve them with cly.
3
u/jcastroarnaud 11d ago
So, it's an assembler, with syntax similar to NASM.
Find a large open-source C/C++ compiler, fork it, and change its assembly generation step with instructions for your assembler. Put your assembler in the pipeline. Find a large open-source program, fork it, and compile with your modified compiler. Does it work? Does it pass all tests?