MMIX Development Proposals


Documentation, Sources, Binaries, Links, Examples, Contributions

Table of Content

Content

Proposals for the further Development of the MMIX Architecture

Here you find a collection of proposals for changes or extensions in the MMIX Architecture. It is planed to review these proposals periodically and define new versions of the MMIX architecture. The MMIXware will then be updated, as soon as possible, so that you may always find the latest version of the MMIX CPU sitting ready on the shelf.

The proposals are grouped in several subclasses.

Compatibility of mmix-sim and mmix-pipe

The usage counter rU

This proposal was made a bug report and in the meantime is fixed in the current sources.

The behavior of the usage counter rU is specified in mmix-doc, §40, page 32. This specification is implemented in mmix-pipe. In mmix-sim, however, the usage counter is just incremented by 1 for each instruction. There is no obstacle to implementing rU in mmix-sim as specified in mmix-doc.

Operating System

Power On Specification

Situation:

MMIXware does not specify the CPU behavior at power-up.

Proposal:

At power-up or after a hard reset. the MMIX CPU sets all its registers to 0, except

  • The Global Threshold Register rG is set to 255.
  • The serial Number has a predefined value.

The CPU then starts executing instructions at the address #8000 0000 0000 0000 which maps to the physical address 0.

Applies To:

Simulators that do not simulate booting a machine are not affected by this proposal.

Signals and Trips

Situation:

Programming an OS requires callbacks an application might want to attach to a dynamic event. These callbacks are difficult to implement from the operating system side, since, both sides are asymmetric, and therefore also the call and return instructions TRAP and RESUME are highly asymmetric.

Proposal:

Add to the implemented arithmetic exceptions some user defined exceptions that can be set by the Operating System to indicate signals.

Details of the proposal.

LDVTS Load Virtual Translation Status Instruction

Situation:

The LDVTS Instruction is used to change the Translation Look Aside Buffers of the CPU.

Proposal:

The LDVTS Load Virtual Translation Status Instruction should be modified to enable an operating system to compute a translation from virtual to physical addresses in a fast and convenient way.

Details of this proposal.

Restoring rK after a TRAP

Situation:

A forced or dynamic Trap will set rK to zero. Before the corresponding RESUME, the operating system needs to provide a new value for rK in $255.  To do so, the operating system needs to maintain a current value of rK in memory, and load it to $255. Especially for short or ignored dynamic TRAPS, this is not convenient.

Proposal:

TRAP and RESUME would be more symmetric and convenient to use if the TRAP would save rK to a register rKK and RESUME 1 would restore rK from there. A single RESUME 1 would be sufficient to undo the effect of a dynamic or forced TRAP.

Dispatching TRAPs

Situation:

All dynamic TRAPs are dispatched to rT, all forced TRAPs to rTT. Only for TRIPs there is a dispatching to variable offsets depending on the event that causes the TRIP

Proposal:

Dispatch dynamic TRAPS to offsets of rT determined by the least significant bit in rQ&rK and dispatch forced TRAPs at various offsets to rTT (or rT) depending on the kind of TRAP.

Details of the Proposal

Setting rS and rO

Situation:

The registers rS and rO can be set only by a UNSAVE Instruction.

Proposal:

While it is reasonable, that an operating system, especially if executing TRAPs on the application stack, wants some assurance that the application will not modify the stack in an unexpected way, the operating system itself could use more flexibility by allowing it to set rS and rO directly with a PUT instruction.

Page-Fault Problem

Situation:

If a growing stack causes storing values from the register stack to memory and this in turn leads to a page fault, the operating system which is supposed to handle this case, has no local registers at its disposal, which makes handling the pagefault quite complicated.

Proposals:

Various proposals have been made to counter this situation.

Details of the Proposals

Virtualization

Situation:

MMIX was not designed with support for virtualization in mind. For example it is not possible to run an operating system using "virtual" negative addresses as a user process. Further, any application can get direct information about the underlying hardware (e.g. serial number rN) without giving a virtual machine monitor the chance to intervene.

Proposal:

Extend the MMIX paging rules allowing application programs to run under certain conditions in virtual negative addresses and make all GET and PUT instructions, that reveal information about the underlying hardware to trap using the built-in mechanism to simulate instructions in software.

Details of the proposal.

Other

Local and Global Register Use

Situation:

Currently, a Program is not allowed to increase rL. And rL must always be less than rG.

Proposal:

Allow the explicit setting of rL with an PUT Instruction to increase rL even past rG. If rL is greater or equal to rG, local registers will shadow global registers, as common in other scoped languages.

Details of the proposal

GETA and low order address bits

Situation:

Currently, Branches, Jumps, GO, PUSHGO, PUSHJ, or POP ignore the low order bits of the target address. MMIX is specifically designed that way so that the low order two bit of rJ can be used as parameters to a subroutine. The GETA instruction, however, does not ignore these bits. GETA just adds the distance between the current instruction and the target instruction to the current instruction pointer. So using GETA might not return the exact address but an address that is off by up to 3 byte. This can be a problem with byte or wyde aligned data. These bits can even kept accumulating using repeatedly GETA and GO (see the details below).

Proposal:

GETA should effectively mask the low order bits of the current location before adding

Details of the proposal

Shared Memory

Author:

Nils Assmussen

Situation:

To share memory between processes, either both processes share the same page table or they use different pagetables that map the same physical pages into the virtual address space. In the first case both processes use the same address space number n in rV and share all of their memory. In the later case, adding or removing pages from memory requires consistent updates of both pagetables. Both situations are not desirable and the problems compound if many processes want to share memory.

Proposal:

Make the address space number 0 a special, global address space, that is compatible with all other address space numbers n. Several different pagetables using different address space numbers can then reference a common subtree with address space number 0.

Please help to keep this site up to date! If you want to point out important material or projects that are not listed here, if you find errors or want to suggest improvements, please send email to email