Hello everyone,

  All of the messages I sent were written by me personally. I did not use
an LLM to generate the content. I typed everything myself, in plain
English, doing my best to explain the concept in detail with headlines and
with paragraph style.

Thank you for the detailed questions and discussions. Let me clarify the
concept more precisely in terms of the C++ abstract machine, because
several responses show that my original message was unclear.
*1. What are “fetch-only operations” conceptually?*

They are *sequencing operations*, not computations.
A fetch-only operation does *not*:

   -

   load from memory
   -

   store to memory
   -

   execute user code
   -

   allocate resources
   -

   produce side effects

Instead, it carries *a piece of metadata describing what should execute
next(i.e where control goes) *, and the evaluation order is adjusted
accordingly.
*2. What problem does this solve?*

In event-driven execution models (e.g., hardware simulators or fine-grained
task schedulers), programs often end up in patterns like:

dispatcher();
→ T1();
→ dispatcher();
→ T2();
→ dispatcher();
→ T3();
...

  The *intent* is simply:

   T1 → T2 → T3 → …


 * but the actual control flow repeatedly returns through the dispatcher,
causing excessive sequencing overhead. --> *I would be very interested
in hearing what existing C++ techniques the committee considers suitable to
express this kind of dynamic sequencing without repeatedly returning
through a dispatcher.


*3. Before / After example (as requested)*

*Today:*

  void scheduler() {
    while (!q.empty()) {
        auto t = q.pop_front();
        t(); // call and return repeatedly
    }
}


  Abstract machine control-flow:

     scheduler → T1 → scheduler → T2 → scheduler → T3 → …


  With fetch-only sequencing operations:

    fetch_schedule(q); // purely sequencing metadata
execute_scheduled(); // walks metadata in-order


Abstract machine control-flow:

    T1 → T2 → T3 → …

he program expresses the *intended evaluation sequence* explicitly, rather
than bouncing through a central dispatcher.
*4. This is NOT hardware prefetch (clarifying misunderstanding)*

There is *no*:

   -

   cache hinting
   -

   memory prefetch
   -

   cache-control
   -

   MOVNTI/MOVNTDQA behavior

The similarity to CPU PREFETCH was entirely unintentional and misleading
wording on my part.
*5. Why not rely on compiler as-if freedom?*

An optimizer *could* theoretically flatten the dispatcher pattern, but in
practice:

   -

   the task list is dynamic
   -

   the order changes frequently
   -

   the compiler cannot predict it

This proposal explores whether C++ can provide a *mechanism to represent
dynamic sequencing explicitly*, separate from computation.
*6. About early-stage status*

This is an early R0 exploratory draft.
I will refine the abstract-machine model and provide a clearer formalism in
subsequent revisions.
I appreciate everyone’s guidance in helping me align this more closely with
C++’s evaluation rules.

Thank you again for the constructive feedback — I welcome further questions
and suggestions.







*Best Regards,Kamalesh Lakkampally,*
*Founder & CEO*
www.chipnadi.com



On Wed, Dec 3, 2025 at 10:18 PM Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> So it is just hints for prefetching? Just for improved performance?
>
>
>
> I thought the general wisdom about prefetching instructions is that their
> effect changes so much between processor architectures that it makes not
> much sense to put them into universal code, as in most cases the hardware
> is already better in optimization than any optimizer, and the programmer
> themselves only can beat the optimizer by hand-optimizing those is pure
> inline assembly for one specific architecture?
>
>
>
> But probably there is more to it?
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>