Intel Backend for Custom Assembler
Budget: $30 – $250 USD
I built Seedling, an assembler that takes my two-function language Illeshian and pipes it through NASM and ld. That extra hop is slowing everything down and hiding the elegance of its universal / global / local /global block scope /local block scope scoping system. Seedling is scope based with sections where normal assembler are pure section based. I’m ready to give Seedling its own Intel x86-64 backend so it can emit machine code directly.
Here’s the goal: when someone passes -b on the command line, Seedling should translate its mnemonics straight into Intel opcodes and write a standard relocatable object file (.o). Once that file exists, my usual linker does the rest—no NASM in the middle, no fragile text parsing, just a clean, fast compilation path.
You’ll be working only on the back-end stage:
• build the opcode tables, handle REX prefixes, align data, lay out sections, symbol tables, and relocations;
• ensure the generated ELF object links without complaint on a Windows wsl2 toolchain;
• leave the existing parser, AST, and one-to-one Illeshian-to-Seedling mapping exactly as they are;
• extend the CLI so -b switches to the new backend.
I’m looking for someone comfortable at an intermediate compiler-construction level—enough to reason about encodings and relocation records without rewriting the whole codebase. A small test suite or sample programs that compile, link, and run will serve as proof it works. This is without LLVM.
If the challenge sounds fun, let me know how you’d tackle it and roughly how long you’d need.
Here’s the goal: when someone passes -b on the command line, Seedling should translate its mnemonics straight into Intel opcodes and write a standard relocatable object file (.o). Once that file exists, my usual linker does the rest—no NASM in the middle, no fragile text parsing, just a clean, fast compilation path.
You’ll be working only on the back-end stage:
• build the opcode tables, handle REX prefixes, align data, lay out sections, symbol tables, and relocations;
• ensure the generated ELF object links without complaint on a Windows wsl2 toolchain;
• leave the existing parser, AST, and one-to-one Illeshian-to-Seedling mapping exactly as they are;
• extend the CLI so -b switches to the new backend.
I’m looking for someone comfortable at an intermediate compiler-construction level—enough to reason about encodings and relocation records without rewriting the whole codebase. A small test suite or sample programs that compile, link, and run will serve as proof it works. This is without LLVM.
If the challenge sounds fun, let me know how you’d tackle it and roughly how long you’d need.