Testing Chinese LLMs in UEFI Game Development: A Deep Dive into Technical Evolution and Code Generation Capabilities

In recent years, large language models have become increasingly capable at code generation, with their application scenarios expanding from conventional web development toward low-level systems programming. UEFI (Unified Extensible Firmware Interface) development serves as a rigorous benchmark for evaluating how deeply models understand code generation because it operates outside standard OS environments, lacks standard library support, and involves complex debugging workflows.

This article uses the development of a Pac-Man game in the UEFI Shell environment as a case study to analyze how current mainstream Chinese LLMs perform on complex low-level tasks, focusing on their technical capabilities, engineering maturity, and notable areas of progress.

The Challenges of Complex Tasks in UEFI Environments

At the firmware level, the UEFI Shell provides an execution environment that sits between hardware initialization and OS loading. Developing a game with complete graphics rendering and interactive logic in such a bare-metal or semi-bare-metal environment presents several challenges:

1. No standard runtime library: Conventional C/C++ standard libraries cannot be used directly. All memory management and basic I/O must rely on the low-level interfaces provided by UEFI Boot Services.
2. Limited graphics rendering: Graphics output under UEFI depends on the GOP (Graphics Output Protocol). Developers must directly manipulate framebuffers and manually implement pixel drawing and character rendering.
3. Difficult closed-loop debugging: The code cannot be run directly in a standard desktop IDE. It requires a carefully constructed compilation toolchain and emulator environment.

When such a task is assigned to an AI model, it effectively tests three core capabilities: depth of understanding of the UEFI protocol stack, safe manipulation of low-level C pointers and memory, and the ability to bootstrap a complete engineering environment from scratch.

Technical Highlights: Autonomous Engineering Environment Construction

The most impressive technical highlight in this test was not merely the generation of lines of code, but the model’s demonstration of “full-stack engineering bootstrapping.”

Typically, when using AI-assisted programming, developers need to pre-configure compilers, linkers, and test simulation environments. However, in this task, after receiving the development instructions, the model did not passively wait for the environment to be provided. Instead, it proactively constructed a Win32 simulation testing framework. This behavior marks a shift from being a “code snippet generator” to functioning as an “autonomous agent.”

The technical implementation path was as follows:

1. Environment detection and abstraction: The model identified the debugging pain points of UEFI development and proactively designed a Windows-based simulation layer. Using conditional compilation macros, it mapped UEFI-specific interface calls to Win32 API calls.
2. Test framework setup: The model wrote its own Makefile or build scripts to ensure the code could run and be verified quickly on a Windows host without requiring actual UEFI firmware.
3. Logic and presentation decoupling: Architecturally, the model decoupled the core game logic (such as maze data structures and character state machines) from the rendering layer (UEFI GOP or Win32 GDI). This clean separation was the foundation that made the simulation environment feasible.

A simplified code structure illustrates this approach:

#ifdef UEFI_ENV
  // Rendering implementation for the UEFI environment
  VOID DrawPixel(EFI_GRAPHICS_OUTPUT_PROTOCOL *Gop, UINTN X, UINTN Y, EFI_GRAPHICS_OUTPUT_BLT_PIXEL Color) {
      // Direct framebuffer manipulation
  }
#else
  // Rendering implementation for the Win32 simulation environment
  VOID DrawPixel(HWND Hwnd, UINTN X, UINTN Y, COLORREF Color) {
      HDC hdc = GetDC(Hwnd);
      SetPixel(hdc, X, Y, Color);
      ReleaseDC(Hwnd, hdc);
  }
#endif

This ability to proactively address environmental limitations significantly reduces the cognitive burden on developers and makes it possible to start coding without any pre-existing codebase.

Core Game Logic Generation and Bug Fixing in Practice

Once the environment was ready, the model generated a basic Pac-Man framework in a single pass that ran successfully. The initial result featured maze movement for the yellow protagonist, chasing logic for four ghosts, English character UI display, and responsive controls.

However, deeper testing revealed a critical logic flaw: the power pellet mechanic was not working.

The core balance of Pac-Man lies in the “risk-reward transition.” After eating a power pellet, ghosts should enter a “flee mode,” and the player should be able to eat them. The failure of this mechanic indicated that the model had made errors in the detailed implementation of state machine transitions.

To address this issue, we evaluated the model’s bug-fixing capabilities. After receiving the fix instructions, the model quickly identified the root cause: when handling the power pellet consumption event, it had only updated the local scoring logic without synchronizing the global “ghost state” variable to a “frightened” state.

The fix involved the following technical points:

1. State machine extension: Adding a state enum to the ghost structure to distinguish between normal and frightened states.

typedef enum {
    GHOST_STATE_NORMAL,
    GHOST_STATE_FRIGHTENED,
    GHOST_STATE_EATEN
} GHOST_STATE;

1. Timer management: Introducing countdown logic for the power pellet’s active duration, after which ghosts automatically revert to normal state.

2. Collision detection rewrite: Adding conditional branches to the player-ghost collision check based on the ghost’s current state. If the ghost is frightened, the consumption logic is executed and the ghost resets to its spawn point. If the ghost is normal, the player loses a life.

The model not only completed these logic patches quickly but also re-validated the entire implementation through its self-built Win32 simulation environment, ultimately confirming that the power pellet mechanic now worked correctly.

Evolution Trends and Reflections on LLMs in Low-Level Programming

Based on this practical exercise, we can identify several notable evolution trends in Chinese LLMs for code generation:

First, there is a shift from “single-point code generation” to “holistic engineering construction.” Models are no longer limited to outputting a specific function. They can now consider compilation environments, test validation, and code architecture as part of a coherent whole, demonstrating strong systems-level thinking.

Second, regarding low-level technology stacks, models have reached a practical level of proficiency with low-level interfaces such as the UEFI GOP protocol and Win32 API. They can correctly invoke these interfaces and handle complex pointer and memory operations.

Third, in the bug-fixing phase, models demonstrate good instruction following and contextual reasoning. They can accurately locate state machine logic flaws based on runtime feedback and provide valid patches.

That said, it is important to acknowledge that LLMs still exhibit probabilistic omissions when generating complex systems in a single pass — the initially missing power pellet mechanic is a case in point. In real-world engineering, developers still need to serve as “architecture reviewers” and “test validators.” Through continuous interaction and guided instructions, combined with the high productivity of LLMs, developers and AI can work together to tackle the challenges of low-level systems development.

As large model technology continues to iterate, combined with cloud computing platforms and container services, AI-driven firmware development and system-level toolchain construction will likely embrace a more efficient and intelligent engineering paradigm. Developers should actively embrace this shift and master the core skills of collaborative programming with AI to meet the increasingly complex challenges of software engineering.