C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Core-Language Extension for Fetch-Only Instruction Semantics

From: David Brown <david.brown_at_[hidden]>
Date: Wed, 3 Dec 2025 16:37:08 +0100
On 03/12/2025 14:50, Ville Voutilainen via Std-Proposals 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.
>

No, as far as I am aware, these are all operations on the abstract
machine. The intention with them is that, on suitable hardware and with
suitable optimising compilers, they can map closely to specific hardware
operations. But they are defined on the abstract machine, just like all
other C++ operations.

So on one processor, a 32-bit atomic fetch-and-add might be a single
instruction. On a different processor, it might be a loop using
load-reserved and store-conditional instructions. Or maybe it calls a
library function which uses an OS spinlock, or it uses explicit
interrupt blocking and bus locking. There are as many possibilities as
there are processors.

Similarly, the SIMD library will often map to SIMD assembly instructions
on some machines. But it will map to multiple instructions on different
machines.


As Jason said, I think it would be useful to see some examples of code
without this language extension, and code with the same (or similar)
effect using the proposed extensions, and a brief explanation of the
differences in code generation expected. That would make the proposal
clearer (to me, anyway).

Received on 2025-12-03 15:37:20