[Info-vax] Rust as a HS language, was: Re: Quiet?

[Johnny Billquist]

On 2022-04-08 14:45, Dan Cross wrote:
> In article <624f803d$0$698$14726298 at news.sunsite.dk>,
> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>> On 4/7/2022 12:27 PM, Dan Cross wrote:
>>> In article <t2n2u6$3jv$1 at gioia.aioe.org>,
>>> chris  <chris-nospam at tridac.net> wrote:
>>>> The basic idea of a language as close as possible to the bare
>>>> metal, yet with enough capability for serious high level work,
>>>> with layered design, is as close to an ideal language as
>>>> anyone could wish for. Tricky language indeed ?, rofl...
>>>
>>> The "C is close to the hardware" thing hasn't been true a long
>>> time now.
>>>
>>> https://queue.acm.org/detail.cfm?id=3212479
>>
>> That is a rather unusual definition of close to HW.
>>
>> A way more common definition is that the language can
>> actually directly access HW.
>>
>> Work with memory mapped devices etc.. And C typical
>> does that great.
> 
> Does it, though?  How well-defined are the semantics around, say
> `volatile`?

volatile is simple enough. Every reference have to stay, and be kept in 
the same order, and order also kept in relation to other volatile 
variables, and the value cannot be "cached" or placed in a register, or 
whatever. Memory barriers all around.

There are other parts that are much more devious in C these days.

>> C pointers can for good or worse point anywhere.
> 
> Actually, they can't.  For example, merely incrementing a
> pointer that already points one-past the end of an array is UB.
> (C11, sec 6.5.6, par 8).  The mere existence of a pointer that
> is improperly aligned for the type is UB (C11, sec 6.3.2.3,
> par 7).

Yeah. That one is beautiful. (not)

>> Totally platform specific code,
>> but it does it on Linux, Windows, VMS etc..
>> Additionally close to HW may imply that not too
>> much is happening under the hood.
> 
> I think that part of Chisnall's point is that the hardware is
> actually doing a _lot_ of work under the hood to make C programs
> fast.  Register renaming, speculative and out-of-order execution
> etc.  None of that is visible to C.

I think that point is pretty pointless, though.
These kind of tricks are not visible to anyone, not even when you write 
in assembler. And it's not about making C programs fast, but making any 
code fast.

But C compilers are doing a lot of things under the hood to make C 
programs fast, and a lot of it is things people might not expect.

   Johnny