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]> wrote:

> On Wed, 3 Dec 2025 at 15:27, Peter Bindels via Std-Proposals
> <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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>