Could you explain, what fetch-only instructions are? They only fetch their arguments? They don't store results (or only later)? They enforce some ordering? What is stored in the metadata? The association of fetch and execution?   There are existing precedences in the language of constructs storing data and executing it later. One can define a capturing lambda. One can create co-routines. Such a concept is not totally foreign in the C++ syntax.   The compilers in C++ with the abstract machine and as-if rule have great freedom for compiling code into a totally different way than was written.   a) One approach would be to create a compliant compiler, which does not use those freedoms, b) another would be to create an optimizer doing those optimizations automatically (without the user having to program in a certain way), c) and a 3rd way would be to introduce language constructs to allow the user to specify those constraints.   You chose the 3rd way. That means, one has to carefully adapt the definition of the abstract machine to allow it to have a notion of what you want to achieve and then to provide C++ constructs to control those.   It is a worthwhile goal to better support modern C++ in a performant way on FPGAs and ASICs. IMHO.     -----Ursprüngliche Nachricht----- Von:Kamalesh Lakkampally via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 03.12.2025 12:58 Betreff:[std-proposals] Core-Language Extension for Fetch-Only Instruction Semantics An:std-proposals_at_[hidden]; CC:Kamalesh Lakkampally <founder_at_[hidden]>; Hello all,  My name is Kamalesh Lakkampally, founder of an EDA startup,  I am submitting  draft proposal (PnnnnR0) for consideration by the Evolution Working Group (EWG).  The goal is to support workloads where the execution order of micro-tasks changes dynamically and unpredictably every cycle, such as event-driven HDL/SystemVerilog simulation. In such environments, conventional C++ mechanisms (threads, coroutines, futures, indirect calls, executors) incur significant pipeline redirection penalties. Fetch-only instructions aim to address this problem in a structured, language-visible way.  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.   Best Regards, Kamalesh Lakkampally, Founder & CEO www.chipnadi.com <http://www.chipnadi.com>   -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals