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

[Dan Cross]

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`?

>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).

>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.

	- Dan C.