Add Coroutine Support: YIELD and RESUME

Topic Overview

Cooperative Coroutines

Coroutines suspend mid-function and resume later with local state intact. Unlike threads, they yield explicitly. Lua's \`coroutine.yield\`, Python generators, and \`asyncio\` all build on this save-restore pattern.

YIELD and RESUME

A coroutine object stores its own \`pc\`, operand stack, and frames:

• \`OP_YIELD\`: snapshot current VM state into the coroutine, return to caller
• \`OP_RESUME\`: restore snapshot, continue at saved \`pc\`
• \`OP_COROUTINE\`: allocate a coroutine with an entry address

The producer-consumer pattern is the classic demo: a coroutine generates values, yielding each one; the driver resumes it to pull the next.

For example, a coroutine yielding 1, 2, 3 prints those values across three resume calls without threads or preemption.

States to track: \`CREATED\`, \`RUNNING\`, \`SUSPENDED\`, \`DEAD\`.

Design Notes

Only one coroutine runs at a time in this model, so you avoid locks entirely. That cooperative guarantee is why Lua coroutines and Python generators can mutate VM state without the synchronization threads demand.

For This Exercise

This exercise asks you to add coroutine objects with independent execution state. You will implement \`YIELD\`, \`RESUME\`, and a producer coroutine that the main program drives in a loop.

You will use the same mental model here when reading production interpreter source later in the track. Sketch one concrete input on paper, predict the outcome, then confirm with code. That discipline catches logic errors early and makes debugging far faster when you extend the implementation in follow-on tasks.

Your Task

Add coroutines (generators) to the VM. A coroutine is an independent execution context with its own pc, operand stack and locals. YIELD pops a value, hands it to whoever resumed the coroutine, and suspends it. The next resume continues right after the YIELD, with all its state intact. RETURN finishes it for good. Define coroutine bodies, create instances with arguments, and drive them.

Input

cCopy
Loading…

Body instructions: PUSH n POP ADD SUB MUL NEG DUP SWAP EQ LT GT JMP L JZ L LOAD i STORE i YIELD RETURN (8 locals per instance, starting at 0).

Rules

• States: created → running → suspended (after YIELD) → running → … → dead (after RETURN or an error).
• resume:
  • runs the instance until YIELD (CO yielded V) or RETURN (CO returned V);
  • a dead instance prints resume CO: cannot resume a dead coroutine for each requested resume;
  • each resume has a budget of 10000 instructions: CO: error, no YIELD within 10000 steps.
• Errors kill the instance: CO: error at PC (OP): stack underflow, CO: error at PC: stack overflow (64 values), and CO: error, ran off the end of BODY.
• Instances are independent: two instances of the same body keep separate state.
• status lists instances in creation order: CO: STATE, resumed N time(s), pc P.
• Setup errors:
  • BODY: unsupported instruction X
  • BODY: bad operand for OP
  • BODY: JMP needs a label / BODY: JZ needs a label
  • BODY: undefined label X (the body becomes empty)
  • create CO: no body named B
  • create CO: name in use
  • resume CO: no such coroutine
• create prints created CO from BODY with N argument(s).

Output

cCopy
Loading…

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Keep everything a coroutine needs to continue (pc, stack, stack pointer, locals, state) inside its own struct. A resume just runs the loop on that struct.
2. Advance the pc past a YIELD before suspending, so the next resume does not yield again at the same place.

Hidden tests cover a generator that finishes after several resumes, a body that never yields (the step budget), an underflow inside a coroutine, resuming more times than values exist, and setup errors.