History of IBM i : Part 4 – The Technology Independent Machine Interface (TIMI)

The Technology Independent Machine Interface (TIMI) is a foundational component of the IBM i operating system architecture, originally introduced with the IBM AS/400 in 1988. It serves as an abstraction layer that decouples application software from the underlying hardware, enabling remarkable hardware independence and backward compatibility. TIMI allows programs compiled decades ago to run unmodified on modern processors, making it a key enabler for the longevity and stability of IBM i systems. In essence, TIMI acts as a virtual instruction set or intermediate bytecode that bridges high-level programming languages and native machine code, ensuring applications remain portable across hardware generations without recompilation.

How TIMI Works

TIMI operates through a multi-step process involving compilation, storage, translation, and execution:

1. Compilation Phase: When a developer compiles source code (e.g., in RPG, COBOL, C, or other supported languages) on an IBM i system, the compiler generates TIMI bytecode instead of direct native machine instructions. This bytecode is a hardware-independent representation that focuses on operations involving objects (such as files, programs, libraries, and user profiles) rather than raw memory addresses. This aligns with IBM i’s object-oriented design, where all system resources are treated as encapsulated objects with attributes and access controls. The TIMI instructions are stored persistently within the program object, alongside any previously generated native code.
2. Storage and Persistence: Program objects in IBM i contain both the TIMI bytecode and, if applicable, cached native machine code from prior executions. This dual storage ensures “observability,” allowing the system to re-translate the bytecode as needed—for debugging, optimization, or hardware changes. Program objects can be easily transferred between systems (e.g., via save files or SAVF commands), and the TIMI layer handles adaptation to the target hardware.
3. Translation Phase: Upon loading or running the program, the System Licensed Internal Code (SLIC) translates the TIMI bytecode into optimized native machine code tailored to the current processor architecture. This is an ahead-of-time (AOT) translation, meaning it occurs once when the program is first loaded, not at runtime for each instruction. The translated code is then cached in memory for future use, minimizing overhead. If the hardware changes (e.g., during a system upgrade), the TIMI bytecode remains intact, and SLIC simply re-translates it for the new processor without requiring any user intervention.
4. Execution Phase: Once translated, the program executes at full native speed, with SLIC intervening only for operating system-level functions like I/O operations, security checks, or resource management. The performance impact of this process is negligible—typically 1–3% in multi-logical partition (LPAR) environments—thanks to hardware acceleration and caching.

TIMI supports two main instruction formats: the Original Machine Interface (OMI), which maintains compatibility with older systems like the System/38, and the New Machine Interface (NMI), a lower-level format resembling W-code for more efficient translation on modern processors. During major transitions (e.g., from CISC to RISC architectures), the system can automatically convert between these formats.

Relationship to SLIC

TIMI is inextricably linked to the System Licensed Internal Code (SLIC), which serves as the underlying kernel-like layer in IBM i. SLIC handles the actual translation of TIMI bytecode into native code and manages core system functions such as storage, memory allocation, I/O, and security enforcement. There is typically one SLIC instance per physical server, which supports all LPARs by translating TIMI for programs in each partition independently.

Together, TIMI and SLIC create a protective barrier that isolates applications from hardware specifics, allowing IBM to evolve the processor architecture (e.g., from IMPI to POWER10) while keeping the user experience consistent. SLIC also enforces TIMI’s object-based model, preventing direct memory access and enhancing system security by restricting user programs from OS-reserved areas.

Benefits of TIMI

TIMI provides several critical advantages that have contributed to IBM i’s reputation for reliability and cost-efficiency:

• Hardware Independence and Portability: Applications are not locked into specific processors, reducing vendor lock-in and enabling seamless migrations to new hardware.
• Backward Compatibility and Longevity: Programs from the 1980s (e.g., on AS/400) can run unmodified on today’s POWER10 systems, preserving software investments and avoiding costly rewrites.
• Automatic Optimizations: New processor features (e.g., improved vector processing or AI acceleration) are automatically applied during translation, boosting performance without code changes.
• Security Enhancements: By abstracting hardware and enforcing object-based access, TIMI reduces vulnerabilities like malware or unauthorized memory access.
• Cost Savings: Eliminates the need for recompilation, retesting, or retraining during upgrades, making hardware transitions nondisruptive.
• Scalability: Supports multi-LPAR environments and cloud deployments (e.g., IBM Power Virtual Server) without architectural overhauls.

Historical Context in IBM AS/400 and IBM i

TIMI was born out of the need to address hardware dependencies in earlier midrange systems like the System/38 and System/36. Developed as part of the AS/400’s “Silverlake” project in the mid-1980s, it drew from the System/38’s Machine Interface (MI) concepts to create a more advanced, technology-agnostic layer. A pivotal moment came in 1995, when IBM transitioned the AS/400 from 48-bit CISC IMPI processors to 64-bit PowerPC RISC processors.

Thanks to TIMI, millions of existing applications ran unchanged, avoiding a massive industry disruption. This pattern continued through subsequent evolutions: to POWER4 (2001), POWER5 (2004), POWER6 (2007), POWER7 (2010), POWER8 (2014), POWER9 (2017), and POWER10 (2020). As the AS/400 rebranded to iSeries, System i, and finally IBM i on Power Systems, TIMI remained the “secret sauce” for effortless upgrades, supporting applications over 30 years old on cutting-edge hardware as of 2025.

Technical Details and Implementation

From a technical standpoint, TIMI’s implementation involves:

• Instruction Sets: TIMI uses object-oriented instructions that reference named objects, not memory pointers, which enhances security and reliability.
• Translation Overhead: Performed by SLIC using hardware acceleration, with translation triggered only on initial load or hardware changes.
• Compatibility Modes: OMI for legacy System/38 compatibility and NMI for optimized modern execution, with automatic conversion tools during migrations.
• Integration with IBM i Features: TIMI complements the single-level store (unified memory and disk addressing) and integrated Db2 database, contributing to the platform’s overall efficiency.

In summary, TIMI’s design philosophy—abstracting hardware while preserving performance and compatibility—has made IBM i one of the most resilient enterprise platforms, adapting seamlessly to technological advancements without sacrificing legacy investments.

History of IBM i : Part 5 – SLIC (System Licensed Internal Code) in IBM Power Systems