Quantized variants of [Qwen32B-N64-Decomp-16bit]: https://huggingface.co/Allomgie/Qwen32b-N64-Decomp-GGUF.

Qwen32B-N64-Decomp-16bit (Stage 2 Master)

This model is a specialized fine-tune of Qwen2.5-Coder-32B-Instruct, specifically engineered for decompiling MIPS assembly into C code compatible with the SGI IDO 5.3 compiler.

It has been trained in a two-stage process on a verified dataset. The final Stage 2 utilized an 8192-token context length and achieved a mean token accuracy of 96.5% on complex 8k-token samples.

The model focuses on:

Logical reconstruction
Precise register mapping
Compiler-specific patterns
Nintendo 64 reverse engineering workflows

Experimental Status

Project State

Advanced Testing Phase

This is the unquantized 16-bit (BF16) master checkpoint. While it performs exceptionally well and understands complex control flows (e.g. nested ternary operators and switch tables), the output must still be verified by a human.

It acts as an expert assistant for IDO decompilation, not an autonomous compiler.

Model Variants

BF16 (65.5GB) → maximum precision, server use
Q8_0 (ca. 35GB) → near-lossless, RE work
Q6_K (ca. 27GB) → balanced accuracy
Q5_K_M (ca. 23GB) → 24GB GPU optimal
Q4_K_M (ca. 20GB) → consumer fast inference

Hardware Requirements

BF16: ca. 80GB VRAM (H100 / A100 / multi-GPU)
Q8_0: ca. 40GB VRAM
Q6_K: ca. 32GB VRAM
Q5_K_M / Q4_K_M: ca. 24GB VRAM

CPU inference: ≥64GB RAM recommended

Data Provenance & Training

The dataset is fully clean-room, compiler-verified, and does NOT include raw copyrighted source leaks.

Pipeline

Compiler-Guided Delta Debugging (IDO 5.3)
Hash verification of compiled output
Semantic pruning (dead code / noise removal)

1. The IDO-5.3 Verification Pipeline

Every single MIPS-to-C pair in the dataset was verified using the original SGI IDO 5.3 compiler.

The dataset was processed through a custom Compiler-Guided Delta Debugging Pipeline inspired by C-Reduce, but specifically tailored for IDO 5.3.

This pipeline guarantees that the C code is a minimal representation of the target assembly.

Verification Process

Hash Verification
Every C snippet is freshly compiled. The resulting MIPS assembly hash is compared against the target baseline. If they match exactly, the sample is considered valid.
Semantic Noise Reduction
The pipeline removes dead code, unused variables, phantom branches, and non-essential artifacts.
Result
The model learns a near 1:1 mapping of logical C constructs to MIPS instructions while remaining largely free of human formatting bias and unrelated source artifacts.

2. Dataset Composition

The dataset consists of over 200,000 strictly validated pairs heavily weighted toward generated, stressed, and reconstructed logic.

Structurally Accurate Synthetic Data

To closely align the model with real Nintendo 64 development environments without relying on proprietary source code, the dataset utilizes custom-generated synthetic C files.

These files were algorithmically generated to mimic:

authentic naming conventions
global variable layouts
struct-heavy logic
late-90s game-engine patterns

Synthetic Torture Tests

Alongside established generators such as:

Csmith
YARPGen

the dataset incorporates deeply nested control flow, complex arithmetic, branch-heavy logic, and intentionally convoluted compiler edge cases.

This forces the model to infer compiler behavior rather than memorize standard functions.

Normalized Algorithmic Patterns

The dataset additionally includes clean-room implementations of:

math routines
sorting algorithms
state machines
pointer-heavy control structures

compiled directly to MIPS-II.

Switch-Case Generators

Custom-generated datasets specifically target:

IDO jump-table generation
branch-delay slot behavior
switch lowering patterns
compiler-specific branch scheduling

3. The Two-Stage SFT Process

Stage 1 — Architectural Foundation

Trained on the full 200k+ dataset using a 4096-token context window.

Primary objectives:

MIPS-II semantics
IDO register allocation behavior
stack-frame reconstruction
C-type mapping
branch reconstruction

Stage 2 — Semantic Precision

Trained exclusively on a curated "Golden Dataset" of 40,000 highly complex and heavily reduced samples using an 8192-token context window.

Primary objectives:

long-form context retention
precise struct-offset tracking
complex nested ternary reconstruction
switch-table reconstruction
compiler-faithful control-flow generation

Model Specifications

Specification	Value
Base Model	Qwen2.5-Coder-32B-Instruct
Context Length	8192 tokens
Compiler Target	SGI IDO 5.3 (Nintendo 64)
Architecture	32 Billion Parameters
Precision	BF16 (~65.5 GB)

Recommended for professional environments requiring maximum accuracy.

Hardware Requirements

Version	VRAM / RAM	Recommended Setup
BF16	~70 GB VRAM	1× H200 (80GB), 2× A100/H100 (40GB), or serverless providers such as Modal / RunPod

The Prompting Workflow (Critical)

To get valid results, you must follow the Semantic Expert IR – v16 format.

The model expects:

A JSON-formatted Technical Environment
The cleaned assembly

1. Preprocessing and Environment Building

The model does not understand raw disassembler output.

It requires two distinct pieces of input.

Cleaned Assembly

Requirements:

Remove block comments
Prefix each instruction with its 8-digit hexadecimal opcode

Example:

8c2e4e70 lw $t6, %lo(...)($at)

Technical Environment JSON (v16)

A context object that extracts:

C types
Struct definitions
Function signatures
Stack-frame metadata
Branch metadata
Global access patterns
Instruction-class flags

from associated header files and assembly.

Note: The official asm_cleanup.py and techenv_builder.py scripts are available both in this Hugging Face repository and in the standalone TechEnv Builder repository:

https://github.com/Allomgie/AI_Decomp_Tools/tree/4671144486a5a5dd0f818999c277691945e6ad6b/TechEnv_Builder

Additional details about the Technical Environment structure, schema, and formatting rules can be found in FORMAT.md.

2. The Prompt Structure

This model was fine-tuned using the ChatML format.

Wrap your input using:

<|im_start|>
<|im_end|>

and assign the roles correctly.

Raw Prompt Template

<|im_start|>system
Decompile N64 MIPS assembly to C (IDO compiler). Use the technical environment for types, struct layouts, and calling context.
<|im_end|>

<|im_start|>user
### Technical Environment:
{
  "env": {
    "s": {},
    "sym": {
      "var_6": "int",
      "var_7": "unsigned int"
    },
    "ext": {}
  },
  "funcs": [
    {
      "n": "test",
      "sf": 56,
      "stk": {
        "saved": {
          "ra": "0x1c",
          "gp": "0x18"
        },
        "locals": {
          "blocks": [
            {
              "off": "0x38",
              "size": 24
            }
          ],
          "singles": 1
        }
      },
      "mem": [
        {
          "base": "var_6",
          "fields": [
            {
              "off": "0x0",
              "rw": "w"
            }
          ]
        }
      ],
      "br": [
        {
          "op": "beqz"
        }
      ],
      "calls": [
        {
          "type": "direct",
          "name": "max",
          "argc": 3
        }
      ],
      "args": ["a0", "a1", "a2", "a3"],
      "argc_conf": "medium",
      "ret": "void",
      "ret_conf": "medium",
      "globals": {
        "var_6": "rw",
        "var_7": "rw"
      }
    }
  ]
}

### MIPS Assembly:
.section .text
glabel test # 0

8f810000 lw          $at, %got(var_6)($gp)
27bdffc8 addiu       $sp, $sp, -0x38
[...]

03e00008 jr          $ra
00000000 nop

endlabel test
<|im_end|>

<|im_start|>assistant

3. Understanding the v16 Technical Environment

The Technical Environment JSON block is the most critical part of the prompt.

It acts as the model's symbol table and guarantees that memory offsets and registers are mapped to the exact C types used by the IDO compiler.

Omitting this information can cause hallucinations.

Key concepts in v16

`env.s`

Struct definitions extracted from .h files.

`env.sym`

Global variable declarations and their associated C types.

`env.ext`

External function signatures. When a function is declared here, args and ret are ground truth and argc_conf / ret_conf are omitted.

`funcs`

Metadata describing the target function.

Includes:

sf → Stack-frame size
stk → Saved registers and local-variable block sizes
mem → Memory accesses and read/write flags
args / ret → Parameter registers and inferred return type
argc_conf / ret_conf → Confidence levels (high, medium, low) when inferred from ASM rather than declared in headers
globals → Summary of which global variables this function reads or writes
flags → Instruction-class indicators (e.g. has_fpu, has_64bit)
calls[].tail → true for tail calls (j target instead of jal)

Polymorphic `args`

When ground truth is available from env.ext, args is an array of objects:

"args": [
  {"reg": "a0", "type": "ALCSeq *"},
  {"reg": "a1", "type": "s32"}
]

When inferred heuristically from the ASM, args is a string array and argc_conf is present:

"args": ["a0", "a1"],
"argc_conf": "medium"

Why Is This Strictness Required?

The SGI IDO compiler translates different C types into entirely different MIPS instructions.

Examples:

lb → signed char
lw → int

The Technical Environment prevents the model from generating incorrect casts that would fail binary matching.

4. Generation Parameters

Parameter	Recommendation
Temperature	0.1 – 0.2
Sampling	`do_sample=False`
Search Strategy	Greedy Search
max_new_tokens	Scale from 4096 to 8192 depending on function size

Higher temperatures often produce code that does not compile correctly.

Best Practices

Always provide a Technical Environment
Use cleaned assembly only
Prefer greedy decoding
Keep functions isolated whenever possible
Preserve exact stack-frame metadata
Avoid truncated assembly blocks

Disclaimer

This model is provided "as is" for research and reverse engineering purposes.

The developers are not responsible for:

misuse
copyright infringement
damages resulting from use of this tool

License

This model is released under the Apache 2.0 License.

Downloads last month: 14

Safetensors

Model size

33B params

Tensor type

BF16

Inference Providers NEW

This model isn't deployed by any Inference Provider. 🙋 Ask for provider support

Qwen32B-N64-Decomp-16bit (Stage 2 Master)

Experimental Status

Project State

Model Variants

Hardware Requirements

Data Provenance & Training

Pipeline

1. The IDO-5.3 Verification Pipeline

Verification Process

2. Dataset Composition

Structurally Accurate Synthetic Data

Synthetic Torture Tests

Normalized Algorithmic Patterns

Switch-Case Generators

3. The Two-Stage SFT Process

Stage 1 — Architectural Foundation

Stage 2 — Semantic Precision

Model Specifications

Hardware Requirements

The Prompting Workflow (Critical)

1. Preprocessing and Environment Building

Cleaned Assembly

Technical Environment JSON (v16)

2. The Prompt Structure

Raw Prompt Template

3. Understanding the v16 Technical Environment

Key concepts in v16

env.s

env.sym

env.ext

funcs

Polymorphic args

Why Is This Strictness Required?

4. Generation Parameters

Best Practices

Disclaimer

License

`env.s`

`env.sym`

`env.ext`

`funcs`

Polymorphic `args`