The Dauug House Wright State University logo
Dauug|36 minicomputer documentation

Privileged instructions

Privileged instructions are instructions that Dauug|36 uses to provide for and govern separation between user programs. This requires capabilities that must not be granted to user programs, or separation (sometimes informally called security) cannot be guaranteed. Every instruction described in this section can create havoc if misused. A program that contains one or more privileged instructions is called a privileged program.

It is difficult to categorize privileged instructions, due to overlap in both purpose and which components participate. Here is a system of four categories:

Because there are only about 25 privileged instructions, all instructions (instead of representative samples) are listed below for each category. Further information appears in the pages that are grouped under this one.

Unrestricted memory instructions

Of the ten memory instructions, five are simply privileged versions of nonprivileged instructions. That is, their privileged version (left column) bypasses the page table, but otherwise does what their nonprivileged counterpart (middle column) does.

Opcode Acts like Description
ADDRDM ADDLD add and read data memory*
RDM LD read data memory
RWDM LDSTO read and write data memory
WDM STO write data memory
WDM2 STO2 write data memory twice

*Minor differences exist due to page table side effects.

The five remaining memory instructions read and write the code memory and the page table. These have no nonprivileged counterparts.

Opcode Description
RCM1 read code memory 1
RCM2 read code memory 2
RPT read page table
WCM write code memory
WPT write page table

(Due to timing constraints and high net contention, reading an instruction from code memory requires an uninterrupted two-instruction sequence.)

Identity-modifying instructions

The Dauug|36 concept of user identity is expressed as an 8-bit register that holds the current user. By “user,” we mean a resource user of the CPU; that is, a running program. This 8-bit user contributes eight bits to addresses for these SRAMs:

The identity-modifying instructions manipulate these eight contributed bits, either by changing them at their source (the 8-bit register), or ANDing them out downstream to indicate eight zero bits—user 0 is the superuser—to the register file, return address stack, or page table.

In this list of the identity-modifying instructions, the word “user” refers to a nonprivileged user (not all eight user register bits are zero):

Opcode Description
NPCALL single instruction combining NPRIV and CALL
NPRIV use the user’s registers, page table, and call stack
PCALL single instruction combining PRIV and CALL
PEEK read register belonging to user
POKE write register belonging to user
PRIV use the superuser’s registers, page table, and call stack
SETUP use the superuser’s registers, but the user’s page table and call stack
USER set user identity to an 8-bit value

Aside. The Dauug|36 notion that user 0 is the superuser (is privileged) is an architectural fiction for electrical convenience. Privilege in this architecture is actually asserted by executing a privileged program.

Program initialization instructions

Here are four instructions that don’t fit the category of either memory instructions or identity-modifying instructions. All but XANY are necessary to initialize programs, and XANY shortens the amount of code needed to pre-clear 512 user registers by more than 500 instructions.

Opcode Description
CALI initialize call stack so all RETURN addresses will be valid
JANY branch to a register-specified location
TIMER set the number of instructions between multitasking interrupts
XANY execute a register-specified instruction

Pseudo-instructions

Neither HALT nor HIJACK are used for production assembly language programming, but they nonetheless both have opcodes and documentation.

Opcode Description
HALT for simulation only, pauses execution
HIJACK context switch template for all instructions

Marc W. Abel
Computer Science and Engineering
College of Engineering and Computer Science
marc.abel@wright.edu
Without secure hardware, there is no secure software.
937-775-3016