Date: Fri, 14 Nov 2025 16:12:48 +0100
On 14/11/2025 15:38, Frederick Virchanza Gotham via Std-Proposals wrote:
> Microcontrollers have a single address space for non-volatile and
> volatile memory.
Some microcontrollers have a single address space, others have multiple
independent address spaces (i.e., different assembly instructions for
accessing flash and ram). However, I am not aware of any
microcontrollers that have multiple address spaces that have fully
conforming C++ support - devices like the AVR are supported by gcc, but
are already missing some C++ features (such as exceptions). Still,
people use C++ for such tools, and generalisations such as "single
address space" should not be used lightly.
>
> 0x0 - 0x2000 might be the non-volatile Flash
> 0x2000 - 0x8000 might be the volatile SRAM
>
> At runtime, the flash can be toggled writable or read-only.
>
Flash is almost never directly writeable at run-time. Special
procedures, well outside the scope of the C++ standards, are used to
erase and write flash memory. There are certain other types of
non-volatile memory that can be written directly, but not flash.
> Similarly on desktop PC's, a page of memory can be toggled from
> writable to read-only.
>
> If we store a 'const' object in a section of memory that later gets
> set read-only, we need to be sure that it is really a const object --
> i.e. it can't contain mutable members.
>
Compilers already know this. An object cannot be placed in flash - that
is, in a read-only section of the program's binary image - unless it has
a fixed address, allocated by the linker and with static storage
duration, a const qualification, and with a constant initialisation. If
an object is declared like that, it is naturally immutable - any
attempts to change it (such as by taking a pointer and casting away
const) are UB. Toolchains targeting embedded systems with flash handle
this in exactly the same way as toolchains targeting "big" systems and
generating executable files - immutable statically allocated const
objects are included in read-only sections of the executable's image,
rather than in read-write sections of memory.
const objects that do not have static storage duration and program
lifetimes, cannot be placed in flash because their address and contents
are not fixed when the program image is created (i.e., at compile/link
time).
There may be some benefit in being able to determine if an object could
change, or in being able to mark an object as "locked" in some sense.
But it certainly has nothing to do with flash or other non-volatile
storage on microcontrollers.
David
> So I've implemented "std::contains_mutable". Here's my compiler patch
> for GNU g++:
>
> https://github.com/healytpk/gcc-thomas-healy/commit/tag_contains_mutable
>
> And here it is tested up on GodBolt:
>
> https://godbolt.org/z/KosvqTETo
>
> Looking over the recent papers on reflection . . . I think this would
> be done in reflection as follows:
>
> https://godbolt.org/z/4ezv58zxx
> Microcontrollers have a single address space for non-volatile and
> volatile memory.
Some microcontrollers have a single address space, others have multiple
independent address spaces (i.e., different assembly instructions for
accessing flash and ram). However, I am not aware of any
microcontrollers that have multiple address spaces that have fully
conforming C++ support - devices like the AVR are supported by gcc, but
are already missing some C++ features (such as exceptions). Still,
people use C++ for such tools, and generalisations such as "single
address space" should not be used lightly.
>
> 0x0 - 0x2000 might be the non-volatile Flash
> 0x2000 - 0x8000 might be the volatile SRAM
>
> At runtime, the flash can be toggled writable or read-only.
>
Flash is almost never directly writeable at run-time. Special
procedures, well outside the scope of the C++ standards, are used to
erase and write flash memory. There are certain other types of
non-volatile memory that can be written directly, but not flash.
> Similarly on desktop PC's, a page of memory can be toggled from
> writable to read-only.
>
> If we store a 'const' object in a section of memory that later gets
> set read-only, we need to be sure that it is really a const object --
> i.e. it can't contain mutable members.
>
Compilers already know this. An object cannot be placed in flash - that
is, in a read-only section of the program's binary image - unless it has
a fixed address, allocated by the linker and with static storage
duration, a const qualification, and with a constant initialisation. If
an object is declared like that, it is naturally immutable - any
attempts to change it (such as by taking a pointer and casting away
const) are UB. Toolchains targeting embedded systems with flash handle
this in exactly the same way as toolchains targeting "big" systems and
generating executable files - immutable statically allocated const
objects are included in read-only sections of the executable's image,
rather than in read-write sections of memory.
const objects that do not have static storage duration and program
lifetimes, cannot be placed in flash because their address and contents
are not fixed when the program image is created (i.e., at compile/link
time).
There may be some benefit in being able to determine if an object could
change, or in being able to mark an object as "locked" in some sense.
But it certainly has nothing to do with flash or other non-volatile
storage on microcontrollers.
David
> So I've implemented "std::contains_mutable". Here's my compiler patch
> for GNU g++:
>
> https://github.com/healytpk/gcc-thomas-healy/commit/tag_contains_mutable
>
> And here it is tested up on GodBolt:
>
> https://godbolt.org/z/KosvqTETo
>
> Looking over the recent papers on reflection . . . I think this would
> be done in reflection as follows:
>
> https://godbolt.org/z/4ezv58zxx
Received on 2025-11-14 15:12:56
