On Sat, May 9, 2020 at 11:12 Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 2020-05-09 17:49, connor horman via Std-Proposals wrote:
> >
> > On Sat, May 9, 2020 at 10:39 Andrey Semashev via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
>
> > wrote:
> >
> > On 2020-05-09 17:18, connor horman via Std-Proposals wrote:
> > >
> > > On Sat, May 9, 2020 at 10:14 Andrey Semashev via Std-Proposals
> > > <std-proposals_at_[hidden]
> > <mailto:std-proposals_at_[hidden]>
> > <mailto:std-proposals_at_[hidden]
> > <mailto:std-proposals_at_[hidden]>>>
> > > wrote:
> > >
> > > There is sigwait for this kind of use cases. Or any other
> kind of
> > > blocking - sleep, select, condition_variable::wait, etc.
> > >
> > > Busy waiting as a means of blocking the thread for extended
> > periods of
> > > time is not something that should be encouraged, IMHO.
> > >
> > > Ah yes, that works quite well in embedded/freestanding (or os dev,
> > > especially) where I don't have:
> > > a) posix
> > > b) <thread>
> > > c) <mutex>
> > > d) Stuff along those lines.
> >
> > I don't think using pure C/C++ for kernel (or bare metal embedded)
> > development is practical. Primarily because these languages require
> > certain runtime support and don't implement certain low-level
> > primitives, like halting the CPU or switching the current execution
> > context or setting up MMU for memory paging and memory mapped IO or
> > many
> > other hardware-specific things. That includes setting up hardware
> > interrupt handlers. These primitives are normally written in
> assembler.
> >
> > I do agree (my interrupts are set by a linker script because they have
> > to be a specific address which overlaps a text segment. However, things
> > like looping forever are a high-level concept that should shouldn't need
> > assembly for.
>
> In this case, your infinite loop is just a way to implement halting the
> CPU. Most CPUs have specific instructions for that to reduce power
> consumption. It is not unreasonable to implement it in assembler, even
> if your CPU doesn't have such instructions.

Not necessarily. The semantics differ between CPUs. As mentioned, I have
STP on 6502 and 65816, but that prevents recieving NMIs as well as just
simply progressing.

>
>
> Theoretically, C/C++ could have a standard library function halt() that
> would implement this, but thing is you would likely not have it in a
> bare metal environment - as you said, you don't have a standard library.

If that is what it appears I said, I appolgise. I do have a standard
library, but its freestanding. Just above bare minimum, whatever can
reasonably exist.
Threading does not because there is no reasonable way to implement threads,
nor mutual exclusion locks (et al.) because those would just be atomic
spinlocks.


> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>