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

[Arne Vajhøj]

On 4/8/2022 8:45 AM, 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`?
> 
>> 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..

You really should have read to the end.

There is a lot of compiler specific behavior in
such code.

But that doesn't matter. This sort of code is not
portable anyway.

You can write Linux drivers, Windows drivers and VMS
drivers in C. And people do so.

The code is very different on the platforms.

And the differences between GCC, MSVC++ and VMSC C
are not the main differences.

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

It is not visible to any language. And because it may be
different between different implementation of the same
ISA, then it has to be invisible.

But I was talking about something different. That the
C code and the generated instructions sort of "match".

If you in C write:

c = a + b;

then you expect that it does an addition of
two pieces of data (integer or FP of some size
determined by declaration) and not anything else.

In languages with operator overload and extension methods
that code may download a bitcoin mining program and
run it for 10 minutes.

Arne