You are saying that that ordering produces no observable side effects. Could you clarify this, please? I see 3 interpretations of what you are saying (perhaps it is just me). a) Are you just talking about specifying the ordering as a control command produces no side-effects by itself? b) Or are you saying that each possible instruction order produces the same outcome, when executed   In case a) the actual execution order would have an effect on the results. Then you want to have 'instructions' that can be reordered easily with some commands.   In case b) the execution order would have no effect on the results. This would 'violate' the as-if-rule. And what difference would it make? If the result is anyway the same?   Case c) It would have an effect on currently UB code, which would get a specific meaning depending on the ordering.     -----Ursprüngliche Nachricht----- Von:Kamalesh Lakkampally via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 03.12.2025 15:45 Betreff:Re: [std-proposals] Core-Language Extension for Fetch-Only Instruction Semantics An:std-proposals_at_[hidden]; CC:Kamalesh Lakkampally <info_at_[hidden]>; Hello All, Thank you for the questions and for helping me frame the idea more clearly. Let me provide a conceptual explanation in terms of the abstract machine rather than hardware instruction details. What are “fetch-only” instructions conceptually? They are operations that participate in control-flow selection but do not participate in execution. In the abstract machine sense: * they do not compute values, * they do not produce observable side effects, * they do not modify the program state except by influencing which operation becomes the next in the abstract program order. What behavior do they model? They model a redirection of evaluation that is determined by metadata instead of by a call/return sequence in the execution path. The metadata includes: * the next operation (or region) to evaluate * a small execution-context identifier * a small thread-context identifier     This allows describing a dynamic sequence such as:               T3 → T4 → T1 → T2    without passing control back through a central dispatcher or scheduler each time, so , we can avoid/save some clock cycles of processor, which looks efficient.  Why is this useful? In many event-driven systems (HDL simulators, hardware schedulers, FPGA/ASIC execution engines), the execution order of tiny tasks is recomputed frequently. In C++ today, that produces a pattern like:   dispatcher → T1 → dispatcher → T2 → dispatcher → T3 → ... which incurs repeated call/return redirections. The idea is to express the intended high-level evaluation order directly, instead of routing through a dispatcher. Relation to existing abstractions As you noted, C++ already has constructs that: * store computation temporarily (lambdas), * resume at later points (coroutines), * or allow the compiler wide freedom (as-if rule).   This proposal attempts something similar in spirit: a way to express a sequence of evaluations whose only purpose is to determine “what evaluates next”, without performing computation in between.   Why not rely solely on compiler freedom? You are correct that: * an optimizer could theoretically detect these patterns, * or a compiler could choose to enforce them.   The goal here is to allow programmers to express the intent explicitly when needed, especially in domains where the sequence of evaluation changes thousands of times per second and is driven by dynamic queues. Abstract machine angle You are absolutely right that C++ does not talk about “instructions”. If explored further, this would need to be expressed as: * a new kind of control-flow operation * that affects only sequencing * and produces no observable effects * potentially with a dedicated memory region for metadata that must remain grouping-stable and immune to unintended reordering   I fully agree that a careful alignment with the abstract machine is essential.  Please give feedback/suggestions/comments.   This proposal is still under active development. I plan to expand several sections with more details , and I welcome feedback and collaboration to help shape the next revision.     On Wed, Dec 3, 2025 at 7:20 PM Ville Voutilainen via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: On Wed, 3 Dec 2025 at 15:27, Peter Bindels via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: >> 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. > > C++ doesn't have instructions. Adding a category of instructions does not make sense since it doesn't have any to begin with. Yet C++ has operations, including atomic operations and SIMD operations that map directly to hw instructions. So, presumably, C++ could have fetch-only operations that map directly to fetch-only instructions and regions thereof. >> B. Abstract Machine Model >> Extend program order to include fetch-stage–only redirections. >> Clarify that these operations do not constitute observable side effects. > > How would the abstract machine deal with CPU implementation level detail specifics? It's the *abstract* machine - not tied to details of how you might implement something. In a fashion similar-ish to how the abstract machine specifies how atomic operations work. >> 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. > > How would that region exist? What is it for? This reads like wishful thinking or, honestly, keyword vomit. It would exist for grouping operations that are all (guaranteed to be) fetch-only operations. What it's for is for efficient immune-to-reordering grouping of such operations. >> These changes enable fetch-only instructions as a safe and efficient core-language construct. > > To do what?! At the end of section III of the description: "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." So, to avoid those problems within fetch-only regions. -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals