This GCN GPU assembly compiler converts human-readable assembly into binary machine code for AMD GCN GPUs. Assembly is a readable abstraction of machine code; most assembly statements map directly to single hardware instructions. Performance-critical software or code that needs special hardware features often uses assembly. A typical example is Bitcoin mining: the workload is compute-bound and benefits from small gains, and assembly can access instructions and options that are otherwise unavailable. Assembly also lets you combine instructions creatively. The trade-offs are maintainability and portability; see Disadvantages section below.

The project includes three Visual Studio projects that wrap one another:

On NVIDIA, CUDA supports inline PTX via asm, which provides a PTX-level "almost assembly" experience. In OpenCL for AMD, there is no straightforward way to inline GCN assembly.

The ideal would be an asm function in OpenCL. Some users have partially made this work, but without variable in/out passing it is not useful, and register clobbering is a risk.

I pursued inline assembly by generating a dummy kernel of the right size and capturing used registers. Reliability was poor, so I pivoted: a cl::program can mix OpenCL __kernel and GCN __asm4GCN kernels. Inline assembly infrastructure remains half-built; capturing registers for dynamic dummy kernels is still the blocker.

A related Windows app is HetPas by Realhet. It produces ELF images loadable into OpenCL and runs GCN assembly kernels with Pascal-like host code. It works well; I struggled with Pascal, which motivated this project.

The solution has three projects: Asm4GCN (assembler), OpenCLwithGCN, and Asm4GcnGUI. The Asm4GCN core converts assembly to raw binary.

Example: s_mov_b32 v1, s0 → 7E020200

Beyond opcode encoding, the assembler handles labels, jumps, variables, and register management. The following flow abstracts the core passes (simplified):

Branches may encode to 32 or 64 bits depending on jump distance. Distances depend on sizes of intervening instructions, but those sizes depend on whether intervening branches are 32 or 64 bits. To break the cycle, compute lower and upper bounds: assume unresolved ops are 32-bit for a shortest path, and 64-bit for a longest path. Whenever both bounds agree on 32 or 64 bits, lock that size. Iterate over unresolved branches until all sizes stabilize, then substitute concrete label distances.

A simpler but less efficient fallback is always using the 64-bit form when unsure.

Label features:

Assembly beyond ~20 lines quickly becomes hard to track. Variables solve two problems: naming intent and safe register reuse.

Example:

The variable system has three parts: declaration, use, and freeing.

Use short 3-character types: first char is space (S=scalar, V=vector), middle is size in bytes, last is intended data kind (F/I/U/B). On declaration the allocator reserves the first free register(s) from the allowed pool.

Examples:

Size (middle, updated):

Byte size controls how many consecutive registers are reserved and their alignment. Sizes 1/2/4 still occupy one dword register; 8 uses two consecutive registers, aligned by 2; 16 uses four, aligned by 4; 32 uses eight, aligned by 4.

Data kind (last):

F float, I signed int, U unsigned, B bits (catch-all). Currently informational; future checks could warn on mismatched ops.

Two ways to pin a declaration to specific registers:

Use fixed registers early in kernels to avoid allocator conflicts. Reusing a past variable's register lets you "rename" without a move, reduces peak registers, and avoids extra instructions.

You can declare inline at the point of first use:

Without inline:

With inline:

Since variables auto-free at last use, the allocator can recycle within the same instruction. Example: the register backing localSizeIdx can be reused for vGlobalID on the same line if lifetimes allow.

Use variable names instead of raw registers. The assembler looks up the binding and substitutes the concrete s/v register(s):
v_add_i32 v3, v4, myInt; → v_add_i32 v3, v4, v7.

For multi-register variables, access specific lanes with [index]. Example: adding two 64-bit values:

Prefer automatic freeing for cleaner code and better register pressure.

Automatic:

A variable is freed at its last use. Lifetimes are tracked, and same-instruction recycling is possible.

Manual:

Use free name1, name2 to extend or end lifetimes explicitly.

Manual freeing helps when:

Instructions that support inline literals accept many forms: decimal, hex, octal, binary, scientific, and labels (distance in bytes).

Examples:

C-style #define is supported via textual substitution. Use distinctive names (often braced with underscores) to avoid accidental matches. Macro parameters are supported.

Constrain the allocator to specific registers with #S_POOL and #V_POOL. Place near the top for clarity.

Most instructions and commands support multiple statements per line, separated by ;. #v_pool, #s_pool, and #define must be on their own lines.

Approximate line counts in parentheses:

A possible approach:

Status: (3) partially works (FillerKernelAttempts.cl: DummyFillerCode()), but sizing and counts are imperfect. (6) not finished; the dynamic dummy's starting bytes were hard to locate reliably.

Naive "first free" allocation wastes space. Think of lifetimes as rectangles: width is register width (1,2,4,8,… regs), height is lifetime in instructions. The goal is to place rectangles to minimize total width (peak registers), respecting alignment (2-wide on even starts; 4-wide on multiples of 4).

Differences from classic rectangle/bin packing: lifetimes are mostly fixed vertically; widths are powers of two; and alignment constraints apply. A simple greedy heuristic works well in practice: place each block into the smallest gap it fits (perfect fits preferred), scored by wasted space. Asm4GCN uses this style of heuristic rather than pure "first fit."

OpenCLwithGCN makes Asm4GCN usable from C#. It replaces Asm4GCN kernels with dummy OpenCL kernels, assembles, then patches the dummy binary with the Asm4GCN binary. OpenCL __kernel and Asm4GCN __asm4GCN kernels can coexist in one cl::program.

Assembly benefits from programmable text (e.g., unrolling). A simple C#-based template engine runs before assembly. Use [[ ... ]] blocks; print values with [[=expr]]. More details: CodeProject Template Engine Article

Example

Expands to:

Use both __kernel and __asm4GCN in the same program. Streams let you compose them. Note: early versions supported only a single __asm4GCN; see Limitations section.

From Example1.cs:

Compose the source:

Compile and keep the default environment:

Create the kernel:

Allocate buffers and fill data:

Set args and enqueue:

A small GUI with syntax highlighting, code completion, and an output panel. Useful for quick kernel tests and teaching. The three panes are: C# host code, GCN assembly code, and compiler output.

The GUI keeps GCN assembly in a separate tab for highlighting. Internally, that text is emitted into a .cs file as:

The output panel shows assembler messages first, then any C# compile errors. Program output goes to a console window.

Rule of thumb: keep assembly small and surgical. 1–50 lines for critical paths is manageable; compilers regain advantage as complexity grows.

Some registers are preloaded when a GCN kernel is launched. These may be driver-dependent.

Register optimization example:

Original lifetimes: A,B created at 10, first used at 20 (C=A+B), C used at 30
Usage = (2 vars * (20-10)) + (1 var * (30-20)) = 30
Move C=A+B to 11 → (2*(11-10)) + (1*(30-11)) = 21 → one fewer live register from 11–20.

Tutorial video(s) are available; some parts may be out of date.