Project Machine Extensible: The Architecture, or so I think

Working with computers can be tough for some people, so can be making computers work, but what if you have to make your own computer and make it work? Sounds fantastics! not as fantastic in practice.

I have a preliminary design for this machine, which aims to optimize the small 8-bit ALU and its essential functions. It utilizes prebuilt components that can be interconnected and configured to perform computations.

The Architecture

This is the conceptual framework for the machine I intend to construct, which I refer to as the MX architecture. The design largely stems from a reverse engineering process of numerous earlier processors, with significant influences from the MOS6502, Zilog Z80, Intel 8080, and Motorola 68000. By analyzing and understanding these historical processors, I've been able to integrate and adapt their most effective features into the MX architecture, aiming to create a versatile and efficient computing system i. e. it should work as intended.

The design revolves around the Scalar Execution Unit (SEU), which encompasses several key components. Central to the SEU is the Arithmetic Logic Unit (ALU), which interfaces with the register bus (highlighted in blue) via register taps to retrieve the appropriate operands. The Load Store Unit (LSU) plays a crucial role by handling the loading of data into registers and the storing of register contents into memory.

Given that this is a Harvard architecture computer, the design includes two Bus Interface Units (BIUs)—one dedicated to instructions and the other to data. Additionally, the Instruction Set Architecture Micro-Code ROM (ISA ROM) is a "pivotal element", containing the necessary commands and instructions in the form of ROM signals that guide operations at any given moment.

While the architecture bears similarities to a RISC system, it is intentionally designed with lower specifications to optimize efficiency and functionality. #lowspec

The Machine Cycle

The machine cycle of the MX architecture is composed of three distinct phases:

1. Fetch (F): During this phase, the system retrieves the next instruction to be executed from memory. This is the initial step in the cycle.
2. Decode & Execute (DE): In this combined phase, the fetched instruction is first decoded to determine what actions need to be performed in the ISA ROM then executed. This phase essentially interprets and carries out the instruction.
3. Data Operation (DO): This phase is dedicated to data handling tasks. Depending on the instruction, it might involve loading data into registers or storing data from registers into memory.

In an ideal scenario, a simple instruction would follow a cycle of Fetch -> Decode & Execute. For load/store operations, the cycle would extend to Fetch -> Decode & Execute -> Data Operation. This extension allows for the additional steps needed to handle data transfer between memory and registers.

The instruction pointer is incremented at the conclusion of the Fetch phase, ensuring it always points to the next instruction to be fetched in case there is no jump, thereby maintaining the correct sequence of operations. This structured cycle ensures an organized and efficient processing flow within the MX architecture.