On 2022-04-11 13:14:39 +0000, Simon Clubley said:

> On 2022-04-10, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>> On 2022-04-10 02:29:53 +0000, Stephen Hoffman said:
>>
>>> My usual pointer to just what volatile provides, and doesn't provide:
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1152r0.html
>>
>> For those that believe there is but one write with volatile, there's
>> one write per byte yes, but there can be multiple and arbitrary-ordered
>> writes involved within that operation.
>>
>
> Any compiler doing anything as brain-dead as that would instantly be
> dropped and if it was an open-source compiler, would instantly be
> forked, XFree86 style, and the brain-dead additions removed.

That's unclear, as there can be differences between the C abstract
machine and the physical machine—such as around unaligned memory
access. q.v. Alpha.

If you can only do one write to a range of bytes per volatile, and if
the memory address is unaligned, then you can have to do that in
separate writes with older Alpha.

The older Alpha hardware didn't have the instructions necessary for
that memory access.

The compiler would preferentially align the memory address, but that's
not necessarily always possible with machine registers.

In C, the ways of volatile are subtle and quick to anger.

As much as I can and do use C and will continue to use C on OpenVMS and
elsewhere, I'm also looking forward to access to UBSan and some new
tooling, and to Clang, to make existing and new C code better.

And I'll continue to look into options and alternatives, including
Swift. Maybe zig. Albeit that not on OpenVMS.

--
Pure Personal Opinion | HoffmanLabs LLC

In article <t31i38$1t7$1@dont-email.me>,
Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>In C, the ways of volatile are subtle and quick to anger.
>
>As much as I can and do use C and will continue to use C on OpenVMS and
>elsewhere, I'm also looking forward to access to UBSan and some new
>tooling, and to Clang, to make existing and new C code better.
>
>And I'll continue to look into options and alternatives, including
>Swift. Maybe zig. Albeit that not on OpenVMS.

This, along with many other reasons, is what finally convinced
me to start looking at real alternatives to C for kernel-level
programming. I maintain that Rust sits at a local maxima right
now with respect to the combination of efficiency, expressive
power, and safety for that application domain. It's not perfect
though, and if a better alternative comes along, I'll gladly
give it a fair shake.

- Dan C.

On 2022-04-11, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2022-04-11 13:14:39 +0000, Simon Clubley said:
>
>> On 2022-04-10, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>> On 2022-04-10 02:29:53 +0000, Stephen Hoffman said:
>>>
>>>> My usual pointer to just what volatile provides, and doesn't provide:
>>>>
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1152r0.html
>>>
>>> For those that believe there is but one write with volatile, there's
>>> one write per byte yes, but there can be multiple and arbitrary-ordered
>>> writes involved within that operation.
>>>
>>
>> Any compiler doing anything as brain-dead as that would instantly be
>> dropped and if it was an open-source compiler, would instantly be
>> forked, XFree86 style, and the brain-dead additions removed.
>
> That's unclear, as there can be differences between the C abstract
> machine and the physical machine?such as around unaligned memory
> access. q.v. Alpha.
>

Ok. I'll modify my statement to call the compiler brain-dead if the
hardware can support addresses being accessed in the correct way, but
the compiler chooses to follow the above rules instead.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 4/11/2022 9:14 AM, Simon Clubley wrote:
> On 2022-04-10, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>> On 2022-04-10 02:29:53 +0000, Stephen Hoffman said:
>>> My usual pointer to just what volatile provides, and doesn't provide:
>>>
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1152r0.html
>>
>> For those that believe there is but one write with volatile, there's
>> one write per byte yes, but there can be multiple and arbitrary-ordered
>> writes involved within that operation.
>
> Any compiler doing anything as brain-dead as that would instantly be
> dropped and if it was an open-source compiler, would instantly be
> forked, XFree86 style, and the brain-dead additions removed.

If we look at the language standard, then ISO C has a lot of
undefined and implementation specific behavior. There are lot
of C code but not that much which is guaranteed to work by ISO C
standard.

"C deemed not brain-dead by Simon" is a very unofficial standard
that is not so relevant.

The practical impact may not be so big though.

I suspect that your use case may be typical for such code:

# Reasoning: the most common use of volatile I have in my code is
# for reading and writing to device registers.

You just need to know that the compiler you use will
do what you expect. You do not care if some compiler
somewhere else does not, because such code would
need to be rewritten anyway if ported read as
reimplemented for that platform.

C is more portable than assembler, but it is not that easy
to write 100% portable code in C. But then like above: if
100% portability is a requirement, then C is most likely not
the right choice of language!

Arne

In article <6254bb5f$0$705$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/11/2022 9:14 AM, Simon Clubley wrote:
>> On 2022-04-10, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>>> On 2022-04-10 02:29:53 +0000, Stephen Hoffman said:
>>>> My usual pointer to just what volatile provides, and doesn't provide:
>>>>
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1152r0.html
>>>
>>> For those that believe there is but one write with volatile, there's
>>> one write per byte yes, but there can be multiple and arbitrary-ordered
>>> writes involved within that operation.
>>
>> Any compiler doing anything as brain-dead as that would instantly be
>> dropped and if it was an open-source compiler, would instantly be
>> forked, XFree86 style, and the brain-dead additions removed.
>
>If we look at the language standard, then ISO C has a lot of
>undefined and implementation specific behavior. There are lot
>of C code but not that much which is guaranteed to work by ISO C
>standard.

This thread started off with assertions that one of the big
problems with Rust is that it doesn't have an official standard.
Now we find that the standard has behavior that is surprising,
even to seasoned hands! Indeed, this was one of the impetuses
for the creation of Rust.

>"C deemed not brain-dead by Simon" is a very unofficial standard
>that is not so relevant.
>
>The practical impact may not be so big though.
>
>I suspect that your use case may be typical for such code:
>
># Reasoning: the most common use of volatile I have in my code is
># for reading and writing to device registers.
>
>You just need to know that the compiler you use will
>do what you expect.

An issue here is that the compiler may change, even over the
lifetime of a single project. Linux started with some version
of GCC; now it will compile with much more recent versions
(that are sufficiently different that they're different
compilers for all intents and purposes) and clang, which wasn't
even a twinkle in Lattner's eye when Torvalds started.

>You do not care if some compiler
>somewhere else does not, because such code would
>need to be rewritten anyway if ported read as
>reimplemented for that platform.

Or the compiler version changes or you port to a new hardware
platform or....

>C is more portable than assembler, but it is not that easy
>to write 100% portable code in C. But then like above: if
>100% portability is a requirement, then C is most likely not
>the right choice of language!

Even portability to what one might call oneself over time!

- Dan C.

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2022-04-03, plugh <jchimene@gmail.com> wrote:
>>
>> Perhaps this will stimulate a discussion
>>
>> https://highassurance.rs
>
> There are 3 things that switch me off from considering Rust as a HA language.
> These 3 things are more important than any specific advantages that Rust
> might have over other programming languages.
>
> 1) The syntax. It's horrible and imposes a higher cognitive load than
> it needs to when you are looking at something new or revisiting old code.
> That means you are more likely to miss something or work a lot harder
> than you need to in order to understand the code.
>
> One of the official Ada RMs/Style Guides/etc had it right when it pointed
> out that you write the code once but read it many times. The Rust people
> have forgotten this.
>
> 2) No official ISO or similar language standard I can rely on 5/10/20 years
> from now when I need to work on my safety or general production critical
> code at that point.
>
> Even though many of the Rust people appear not to understand this, the
> lack of those guarantees is a _massive_ problem in the real world.
>
> 3) Unlike mainstream programming languages, the Rust community always
> seems to be lurching from one social drama to the next.
>
> That in itself is an instant switchoff because the community is one
> major social crisis away from falling apart (at least until it's then
> rebuilt and a new direction emerges).
>
> You can't rely on a programming language when something like that is
> a real possibility. You wouldn't see social crisis stuff on the C/C++/Ada
> language standards groups for example.
>
> Simon.
>

This has become another incarnation of The Thread That Would Not Die.

On 2022-04-12, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <6254bb5f$0$705$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>C is more portable than assembler, but it is not that easy
>>to write 100% portable code in C. But then like above: if
>>100% portability is a requirement, then C is most likely not
>>the right choice of language!
>
> Even portability to what one might call oneself over time!
>

:-)

I really, really, wish DEC had followed through on Pillar.

If it took off, we would have had an alternative to C by now.

As I've mentioned before, I use C because it is the most viable
choice in the places I use it, not because it is the best choice.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.