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

YIELD instruction

Opcode P/U Category Description
YIELD user YIELD yield

The YIELD instruction is in a category of its own, because it doesn’t fit within any of the other 13 categories of nonprivileged instructions.

YIELD Yield

Syntax
yield
No registers used
1 opcode only
No flags changed

YIELD sets a bit from the control decoder that is ORed with the expiration signal from the multitasking timer. This initiates the process of taking the CPU from the currently running program and giving it to the superuser. Under typical system use, this means that a program that executes YIELD will soon be suspended so that another program can run.

When cooperative multitasking is used, user programs have exclusive use of the CPU from the time they start or resume running until they execute a YIELD. This is very simple, but has the drawback that a user that doesn’t yield will hang the rest of the system.

When preemptive multitasking is used, which presumably would be the normal use case for Dauug|36, a user is allowed to execute a specific number of instructions (likely close to 65535) before the CPU is given to another user. YIELD tells the CPU not to wait for this number of instructions to execute, but instead switch programs as soon as possible.

YIELD does not take immediate effect. If a program is relinquishing the CPU because it needs the operating system to do something, or to wait on a semaphore, etc., the instruction after YIELD is not the time to move forward as if the request is complete. There will be some delay.

As of 16 June 2023, user programs are suspended immediately prior to the third instruction after a YIELD, assuming the multitasking timer does not expire first. So in a user program containing this code:

yield
x = 0
x = 1
x = 2

x will be 1 if the operating system inspects it while the user program is suspended. This latency may change as the design evolves, in part because the relationship between the system clock and multitasking timer have yet to be adequately thought out.*

The architecture captures almost no information when a YIELD happens. The kernel knows which user program was running, but it cannot tell whether the multitasking timer expired or a YIELD was executed, how much time may be unused, or where the instruction pointer is. When YIELD is used to convey a request to an RTOS kernel, the kernel may need to assume for safety that the yielding program consumed its full timeslice.

*As of 16 June 2023, the netlist includes a one-bit buffer as “a horrible, dangerous kludge around a setup/hold violation” that “increases latency by 1 CPU cycle.”


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