II. Introduction

This paper proposes a core-language extension introducing fetch-only instructions—metadata-carrying constructs handled entirely within the instruction-fetch stage, using a dedicated path that never enters the normal execution pipeline.

The design targets workloads with highly dynamic, micro-task–driven execution patterns, such as SystemVerilog simulation, where pipeline redirection penalties dominate performance.

III. Scenario Description

In event-driven engines such as HDL simulators, the execution order of micro-tasks changes dynamically based on events.

Example Queue State 1:
  Arr[0] = T1
  Arr[1] = T2
  Arr[2] = T3
Execution order: T1 → T2 → T3

Queue State 2 (after events):
  Arr[0] = T3
  Arr[1] = T4
  Arr[2] = T1
  Arr[3] = T2
Execution order: T3 → T4 → T1 → T2

These reorderings may occur very frequently. Existing hardware and language mechanisms must execute branches, indirect jumps, or scheduler calls—each causing pipeline flushes, mispredictions, and stalls.

IV. Limitations of Existing C++ Features

Modern C++ provides threads, executors, coroutines, futures, task tables, and function-pointer invocation. All share a limitation: control-flow changes occur in the execution pipeline.

Impacts:
- Indirect calls cause branch mispredictions.
- Dynamic reordering causes repeated pipeline flushes.
- Coroutines incur state-machine execution overhead.
- std::thread/std::async rely on OS scheduling, unsuitable for micro-task switching.
- Executors/work-stealing operate in software and still rely on pipeline-based jumps.

For workloads with thousands of per-cycle task transitions, these penalties accumulate into a dominant bottleneck.

V. Proposed Solution: Fetch-Only Instructions

We propose a C++ core-language abstraction mapping to architectural fetch-only instructions.

Characteristics:
- Processed entirely in the fetch stage.
- Never decoded or executed.
- Carry: instruction_address, thread_context, execution_context.
- Redirect the fetch PC without pipeline involvement.
- Avoid many branch misprediction and call/jump penalties.

Provisional C++ syntax:
  fad q[i] = address_of(task);
  fcd q[i] = thread_context;
  fed q[i] = exec_context;

The fetch subsystem uses these metadata entries to follow the dynamic queue order with minimal redirection cost.

For example, updating q[] enables hardware to execute:
  T3 → T4 → T1 → T2
without pipeline flushes.

VI. Required Changes in C++ and OS

A. C++ Core Language 
Introduce new semantic category of instructions (fetch-only) with defined behavior:
- Visible to the abstract machine as fetch-control constructs.
- No execution-stage participation.
- No side effects beyond fetch redirection.

B. Abstract Machine Model 
Extend program order to include fetch-stage–only redirections. 
Clarify that these operations do not constitute observable side effects.

C. Fetch-Only Memory Region (OS-Level Support) 
A new region in the virtual address space, analogous to:
- Stack (for call frames)
- Heap (for dynamic objects)

Fetch-Only Region properties:
- Holds fetch-only metadata (instructions addresses + 8-bit thread/execution context).
- MMU-enforced write validation.
- Stricter rules than normal memory.
- Prevents unauthorized metadata forging.

D. MMU / Validation 
MMU enforces:
- Whether context bits may be updated.
- Whether address updates are permitted.
- Masking/rejecting invalid writes.

E. Optional Function Prologue Context Check 
Functions may embed an 8-bit comparison to ensure valid entry conditions.

These changes enable fetch-only instructions as a safe and efficient core-language construct.

I would greatly appreciate feedback, criticism, and suggestions from the community.

I am also open to collaboration.

This is an early-stage concept, and I welcome any guidance on improving the design, refining the semantics, or adapting the idea to better align with the C++ abstract machine and WG21 process.

Thank you for your time, and I look forward to your comments.