On Wed, Dec 3, 2025 at 9:44 AM Kamalesh Lakkampally via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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.

So just to be clear on the concept, if you have something like this:

```
if(*ptr == 0)
{
  //code A
}
else
{
  //code B
}
```

The expression `*ptr == 0` is conceptually a "fetch-only operation"
(assume that `ptr` is a C++ pointer to an integer, not a smart
pointer). It accesses memory, gets a value, does a comparison, and
decides which branch to take, but it never writes to any storage. It
has no side-effects.

If that's the concept, I'm interested to see how exactly you would use
this in a C++ program. A "before" and "after" example with some clear
idea of when you would use it and how much it would affect code
generation.

Also, my above example presumed that `ptr` was a language pointer to
an integer, so that user-defined code wouldn't be executed. Would your
proposal prohibit user-defined operations in fetch-only expressions,
or would users be able to write functions that are fetch-only?