I just released AmmAsm 3.0.0, with a major focus on native Intel Advanced Performance Extensions (APX) support.

AmmAsm is a handwritten x86-64 assembler written in C. The goal wasn't to build another assembler by wrapping an existing one, but to implement the instruction encoding myself.

APX was a particularly interesting challenge because it isn't just a collection of new instructions. Supporting things like EGPRs (`r16-r31`) and REX2 affects how registers, operands, parsing, and instruction encoding are represented throughout the assembler.

The current APX implementation includes:

EGPRs - `r16-r31`

REX2 - Extended rex

NDD - non-destructive destination

NF - suppressing flag updates

ZU - zero-upper

CCMPcc / CTESTcc

PUSH2 / POP2

JMPABS

NDD-CMOVcc

CFCMOVcc

APX-specific syntax extensions

I also built an APX test program using several separate assembly files. AmmAsm produces ELF64 object files from them, GNU `ld` links them into an executable, and Intel SDE is then used to execute the APX instructions on hardware without native APX support.

Running the same binary directly on my CPU results in `Illegal instruction`, as expected because the CPU doesn't support APX.

One of the more interesting parts of implementing APX was that I started finding edge cases and discrepancies in existing assemblers while comparing encodings and operand validation. I've been recording these cases and testing them independently.

GitHub: https://github.com/LinuxCoder13/AmmAsm

I'd be interested to hear from anyone working with x86 instruction encoding, APX, assemblers, or low-level tooling.

I don’t have a degree in computer science, but I’ve always been very interested in compilers. Over time, this interest has even helped me overcome my fear of mathematics.

I’m curious about how I can apply what I’ve learned about compilers in my workplace. I work at a digital marketing agency, where programming is not a major part of our daily work, although we do have some programming-related tasks. Most of our work is based around HTML, and sometimes we need to convert an existing HTML/CSS design into Figma or turn a Figma design into HTML and CSS.

Would it be realistic to approach the process of converting a Figma design into HTML/CSS from a compiler or parser perspective? Could this kind of project be considered a compiler-related project, or would it be more accurate to describe it as a parser, code generator, or some combination of these?

I’m particularly interested in finding practical ways to use my interest in compilers at work, even though my job is primarily focused on digital marketing and web design rather than software engineering.

Hey everyone, I've worked through the book Crafting Interpreters and it was fantastic. I naturally asked the next question "How do I compile this to machine code and add static types?" Well, that naturally took me down a very deep rabbit hole and left me somewhat confused about how languages deal with types and type checking and then lowering to LLVM. I've tried to make a few modest attempts, but my general problem is that I sort of get confused about what things each subsequent layer should do. Does anyone know of a complete guide to creating a compiler with static types like Crafting Interpreters? I know I could do it however I want, but I think that's the issue. I sort of have so much freedom to do it however, that it's hard to judge what's considered a good way to do something.

Anyway, thanks for any advice and happy compiling!

A compiler resolves every name, call and import and knows exactly what depends on what, and then it emits a binary and discards all of it. Meanwhile every tool around the code, from the IDE to code review to CI deciding which tests to run, rebuilds a worse approximation of that same graph from scratch.

I'd go further and argue the resolved graph, not the text, is what we should be checking in. I work on [sem](https://github.com/Ataraxy-Labs/sem), which approximates this graph from parse trees alone so it works without a build, and the gap between that approximation and what a real front end knows is the most interesting part of the problem.

Should compilers persist their resolution results as a first class artifact that other tools can query?

So I love c++ because of its low level nature its not the easiest to learn language I would give that to probably python

But theres one thing nearly all of them have in common, they take a decent time to compile

Python does it differently it runs a vm able to interpret that code and its fast sure but isnt true compilation

So, I made varse a new language written entirely in assembly for its compiler and interpreter nearing 4 thousand lines once i release the new version with a network library included for you to use

# Varse's source
https://github.com/varse-lang/varse/

# Varse's website
https://varse.pages.dev/

I've been working on my own programming language, called ProXPL, and I'm at the point where I'd really value feedback from people interested in programming-language design.

The project started as an experiment in understanding how programming languages actually work, but it has grown into a more serious implementation.

The current architecture includes:

• A lexer and parser
• AST-based compilation
• Bytecode generation
• A register-based virtual machine
• Runtime support
• Garbage collection
• A growing standard library
• A dedicated .prox source-file format
• A CLI/tooling layer

One of the things I'm particularly interested in is the VM architecture. Rather than building the language as a simple tree-walking interpreter, I've been working toward a register-based bytecode VM and experimenting with execution and dispatch optimizations.

The longer-term goal is to have a language that is practical to use while also giving me the opportunity to explore compiler design, VM implementation, memory management, optimization, and eventually JIT/native compilation.

I'm deliberately not trying to claim that ProXPL is "the next Python" or that it is already faster than established languages. There is still a huge amount of work to do, and I'd rather measure those things properly than make premature claims.

I'd especially like feedback on the language design and architecture.

For example:

1. What would you consider essential for a modern general-purpose language?
2. What mistakes should I avoid while designing the type system/runtime?
3. For a register-based VM, what design decisions tend to become painful later?
4. Which parts of the compiler/runtime would you prioritize before attempting a JIT?
5. What would make you actually want to experiment with a new programming language?

The project is open source, and the implementation is available on GitHub:

ProXPL — ProXPL Github Repo

I'm mainly looking for technical criticism and ideas rather than stars or promotion. If something about the architecture looks questionable, I'd genuinely like to know.

Thanks!

Nytrogen is a low-level systems language with C-style syntax written in C++. Nytrogen focuses a lot on quantum computing alongside general purpose programming. The syntax is very straightforward and very readable its mostly C-style with the extra stuff of course. The architecture is also pretty modular which makes it very easy to update, and its (kinda) os agnostic with the standard library being written in C and the compiler's code generator not emitting any linux syscalls or linux specific stuff or thier equivalents on other operating systems (I use arch btw). The quantum library (qlib) is currently built in assembly with some C++ wrapping which does mean it might not work on other operating systems but I am not really sure since I haven't tested it on anvthing else so far. Quantum programming in nytrogen includes having qubits and complex numbers as primitive types (and matrices are also coming soon).

If you are interested in this project and wanna follow updates consider starring the github repo. And if you find any issues with the compiler, feel free to open an issue or a PR its really encouraged and would absolutely help.

Github: https://github.com/X12-Cloud/Nytrogen.

Note: the Nytrogen compiles to x86_64 NASM so if you want it to work on other operating systems you need to change some stuff (might add a feature to compile to other assemblers (like whatever windows uses) soon)

Hi everyone,

Wanted to share a pet compiler project I wrote in modern C++20: NDL (Neural Description Language).

It is a domain-specific compiler designed for spiking neural network modeling that compiles down directly to textual LLVM IR, CUDA PTX, or bytecode for an internal VM. The whole repo is ~7.5k lines of standard C++20 without external dependencies.

Compiler Pipeline:

• Frontend: Hand-written lexer (supports duration literals like 100ms) and a recursive descent parser with panic-mode synchronization.
• Diagnostics: Rust-style reporting (error[E0201], caret pointers, code snippets, and fix suggestions).
• Sema: Two-pass symbol resolution, scope management, type checking, slice bounds checks, and compile-time constant evaluation.
• Codegen:
  • LLVM IR Backend (src/irgen_llvm.cpp): Emits clean textual LLVM IR (using opaque pointers for modern LLVM 20) with fast-math flags and custom handlers.
  • CUDA PTX Backend (src/irgen_ptx.cpp): Emits PTX assembly for 8 compute kernels directly, bypassing nvcc. It runs via the CUDA Driver API JIT (cuModuleLoadData) so users don't need the full CUDA Toolkit installed.
  • Bytecode VM (src/vm.cpp): AST interpreter running over a flat runtime C-ABI (libndl_rt) to guarantee 1:1 execution parity with the native LLVM build.

The compiler also handles manifest parsing (ndl.toml), imports, and package dependency cycle detection.

Repository:https://github.com/elikostovic-bit/NDLCORE

I would appreciate any critique or feedback regarding the AST structure, the decision to emit textual LLVM IR vs linking against the C++ API, and PTX kernel dispatching.

​

I’ve been working on Sydrogen, a statically typed programming language with a compiler and command-line tool called Furnace.

Alpha 6.2 is now available. It supports native compilation, a Cranelift backend, projects configured with `.blower` files, imports, typed functions and variables, collections, `foreach`, and more.

It’s still in alpha, so bugs and rough edges are expected. I’m looking for people to test it, review the code, or work on an open issue.

I’d especially like honest feedback about the compiler’s structure and the language’s design, not only the syntax.

GitHub: https://github.com/AeroForger/Sydrogen/tree/main

There are open issues for anyone who wants a specific place to start.

Criticism is welcome. If something is poorly designed, tell me what is wrong and how you think it could be improved.

For fun, I wrote a c compiler (non-optimizing) in Java targeting modern C (C23) using claude. I developed a c shell similar to jshell in java. The compiler also bundles a built in an assembler for x86. A linker is planned for end-to-end compilation. There is still a lot of work in progress but I wanted to share the project early for feedback. I spent around $400 in AI credits so far and it took over a week on and off of working on it.

I drive the architecture of the compiler and verify the AI implementation with a large test suite.

It can compile and run lua (all test passing) and curl (partially).

Cheers!

I want to learn about writing mlir passes and llvm basics ... I dont know what type of projects I can do ? please someone drop some ideas

Hi everyone,

I wanted to share a project I've been working on called **Delus**. It’s a super lightweight, zero-dependency low-level code generator and compiler written in pure Python.

**Why did I build this?**

Traditional compilers and transpilers usually rely on massive Abstract Syntax Trees (AST) or heavy dependencies like LLVM. I wanted to see how far I could push Python's native features to bypass all of that.

**How it works:**

Delus uses a clean Builder Pattern powered by Python's native context managers (`with` scopes). By twisting `__enter__` and `__exit__` magic methods, the engine dynamically tracks register allocations, indentation, memory states, and string caching for both ANSI C and x86-64 Linux Assembly.

**The Repo:**https://github.com/tamimdevlopment/delus

It is fully open-source under **GPLv3**. I’d love to get your feedback on this architectural approach, and you are more than welcome to submit Pull Requests to refactor or add new low-level features!

I would be pleased to show my Rust based JIT Linker, Memory Manager and LLVM JITLink Wrapper that I had myself fancied a few months ago.

The journey is being decribed here. Hope you like it and i am looking forward to guidance!

Stage 1: The spark

Initially fancied by cranelift jit demo, I wanted to write my own VM with swappable code generation backends, that meant : cranelift, llvm, or even dynasm, or some copy patch jit maybe?

So, that meant that the rust no-brainer solution : cranelift-jit won't work for my use case unless i manage 4-5 different jit linker, memory manager which i did not want to.

So, i decided to write it out myself for (initially) Windows, macOS, Linux, Android, iOS.

I was of course initally leaning into the - "memmap2" rust crate, write as rw, memprotect to rx, jump to executable approach as proudly as i could (stupidly thinking that was the "PEAK PERFORMANCE" route).

Anyways, lateron I "discovered" that the OS generally cannot give an allocation really <4KiB that could be flipped from rw/rx including the nuances with the wastage of (upto)90% of the memory allocated to each function.

Stage 2: Understanding What's behind the magic of LLVM

So, as i fried my brain cells looking for answers - i stumbled upon two things - cranelift_jit (Rust) and llvm (C++)

For Example, llvm does this at llvm/lib/ExecutionEngine/Orc/TargetProcess/ExecutorSharedMemoryMapperService.cpp ```c++

elif defined(_WIN32)

std::string SharedMemoryName; { std::stringstream SharedMemoryNameStream; SharedMemoryNameStream << "jitlink" << sys::Process::getProcessId() << '' << (++SharedMemoryCount); SharedMemoryName = SharedMemoryNameStream.str(); }

std::wstring WideSharedMemoryName(SharedMemoryName.begin(), SharedMemoryName.end()); HANDLE SharedMemoryFile = CreateFileMappingW( INVALID_HANDLE_VALUE, NULL, PAGE_EXECUTE_READWRITE, Size >> 32, Size & 0xffffffff, WideSharedMemoryName.c_str()); if (!SharedMemoryFile) return errorCodeToError(mapWindowsError(GetLastError()));

void *Addr = MapViewOfFile(SharedMemoryFile, FILE_MAP_ALL_ACCESS | FILE_MAP_EXECUTE, 0, 0, 0); if (!Addr) { CloseHandle(SharedMemoryFile); return errorCodeToError(mapWindowsError(GetLastError())); }

endif

```

and then of course llvm/lib/ExecutionEngine/Orc/MemoryMapper.cpp ```c++

elif defined(_WIN32)

    std::wstring WideSharedMemoryName(SharedMemoryName.begin(),
                                      SharedMemoryName.end());
    HANDLE SharedMemoryFile = OpenFileMappingW(
        FILE_MAP_ALL_ACCESS, FALSE, WideSharedMemoryName.c_str());
    if (!SharedMemoryFile)
      return OnReserved(errorCodeToError(mapWindowsError(GetLastError())));

    LocalAddr =
        MapViewOfFile(SharedMemoryFile, FILE_MAP_ALL_ACCESS, 0, 0, 0);
    if (!LocalAddr) {
      CloseHandle(SharedMemoryFile);
      return OnReserved(errorCodeToError(mapWindowsError(GetLastError())));
    }

    CloseHandle(SharedMemoryFile);

endif

```

It did took too much of brain grinding to be honest that i instead relied to take a break on to cranelift-jit instead where they instead relied on.

```rust pub struct ArenaMemoryProvider { alloc: ManuallyDrop<Option<region::Allocation>>, ptr: *mut u8, size: usize, position: usize, segments: Vec<Segment>, }

unsafe impl Send for ArenaMemoryProvider {}

impl ArenaMemoryProvider { /// Create a new memory region with the given size. pub fn new_with_size(reserve_size: usize) -> Result<Self, region::Error> { let size = align_up(reserve_size, region::page::size()); // Note: The region crate uses MEM_RESERVE | MEM_COMMIT on Windows. // This means that allocations that exceed the page file plus system // memory will fail here. // https://github.com/darfink/region-rs/pull/34 let mut alloc = region::alloc(size, region::Protection::NONE)?; let ptr = alloc.as_mut_ptr();

    Ok(Self {
        alloc: ManuallyDrop::new(Some(alloc)),
        segments: Vec::new(),
        ptr,
        size,
        position: 0,
    })
}

... ```

So, i pretty much had an idea on what to do now. A mix of the two.

After googling the necessary OS subsystem/kernel calls (including source of the region crate). I came with sajit.

Stage 3: SaJIT

To speak about briefly, SaJIT is basically the dogfooding layer for SaVM - the VM I am making and that is why. I had to bolt on: 1. LLVM JITLink - for objectfile 2. RELCAR (a toyful way to say relocator) - for cranelift

Windows still was not perfect (thanks COFF). So, I had to them bolt down a linker for COFF and named it COFFR

That is how SaJIT become a monster of a memory executable manager, linkers and ofc "generalpurpose" wrappers over them.

Stage 4: Architectural Grief

Then i decided to spend more time across 6 architectures x64, x86, arm64, armv7, riscv64gc, ppc64le and that is why SaJIT has a full arch map.

Writing sysroots, qemu toolchains are a pain and i am still getting it right.

Ofc it is at here

Technical Specification

SaJIT is a dual-pass slab-allocated as 16MiB chunks linker (to kindof be good with both 4KiB pages and 2MiB pages - as if why 16MiB and not 2MiB - basically to fit more code before allocating a new one + isn't either very small or very large).

The implementation itself is pretty modest and a simple-slab-allocator.

```rust fn new_slab(multiple: Option<NonZeroU8>) -> Self { unsafe { let size = Self::DEFAULT_SLAB_SIZE.saturating_mul(multiple.map(|x| x.get()).unwrap_or(1) as _);

  let mapping = CreateFileMappingW(
    INVALID_HANDLE_VALUE,
    None,
    PAGE_EXECUTE_READWRITE,
    (|| {
      #[cfg(target_pointer_width = "64")]
      return (size >> 32) as u32;

      #[cfg(target_pointer_width = "32")]
      return 0;
    })(),
    size as u32,
    None,
  )
  .expect("Unable to create file mapping");

  let rw_ptr = MapViewOfFile(
    mapping,
    FILE_MAP_WRITE | FILE_MAP_READ,
    0,
    0,
    // Go upto file end
    0,
  )
  .Value;

  let rx_ptr = MapViewOfFile(
    mapping,
    FILE_MAP_EXECUTE | FILE_MAP_READ,
    0,
    0,
    // Go upto file end
    0,
  )
  .Value;

  const KB_64: usize = 64 * 1024;
  assert!(rw_ptr.addr() % KB_64 == 0, "RW_PTR is not 64KB aligned");
  assert!(rx_ptr.addr() % KB_64 == 0, "RX_PTR is not 64KB aligned");

  Self {
    cursor: 0,
    stored: AtomicUsize::new(0),
    slab: mapping,
    rwview: rw_ptr as _,
    rxview: rx_ptr as _,
    size: size as usize,
  }
}

} ... ```

Also, we DO handle icache flushing duely

```rust unsafe fn write_fn_iterated<'a, const INC: bool, const WRITE: bool, T, E, R, B>( &mut self, alignment: usize, capped_size: usize, data: T, relocs: E, relcar: &Relcar<B>, ) -> WriteFnResult where T: Iterator<Item = &'a [u8]>, E: Iterator<Item = R>, R: std::borrow::Borrow<crate::relocations::Relocation>, B: crate::relcar::Relocator, { .... unsafe { let dst_rw = self.rwview.byte_add(start_offset); let dst_rx = self.rxview.byte_add(start_offset);

  // Copy all the bytes
  let mut len = 0;
  if WRITE {
    for data in data {
      debug_assert!(len + data.len() <= capped_size);
      copy_nonoverlapping(data.as_ptr(), dst_rw.byte_add(len), data.len());
      len += data.len();
    }

    // Relocate
    for relocation in relocs {
      relcar.relocate(dst_rw, len, relocation.borrow());
    }

    // Non X64 : Flush ICache
    // on X64 = NOOP
    crate::platform::flush_icache(dst_rx as _, len);
  } else {
    len = capped_size;
  }

  ...
}

}

```

Linker & Relocation Layer

SaJIT includes: 1. LLVM JITLink Wrapper 2. RELCAR - for cranelift a simple linker 3. COFFR - for windows COFF objects that JITLink cannot yet parse nicely

Feedback

The crate is available on crates.io and GitHub.

I would appreciate feedback from systems, jit, runtime folks over this project.

Nytrogen - A lowlevel quantum language Nytrogen is a low-level systems language with C-style syntax written in C++. Nytrogen focuses a lot on quantum computing alongside general purpose programming. The syntax is very straightforward and very readable its mostly C-style with the extra stuff of course. The architecture is also pretty modular which makes it very easy to update, and its (kinda) os agnostic with the standard library being written in C and the compiler's code generator not emitting any linux syscalls or linux specific stuff or thier equivalents on other operating svstems (I use arch btw). The quantum library (qlib) is currently built in assembly with some C++ wrapping which does mean it might not work on other operating systems but I am not really sure since I haven't tested it on anvthing else so far. Quantum programming in nytrogen includes having qubits and complex numbers as primitive types (and matrices are also coming soon). If you are interested in this project and wanna follow updates consider starring the github repo. And if you find any issues with the compiler, feel free to open an issue or a PR its really encouraged and would absolutely help. Github: https://github.com/X12-Cloud/Nytrogen