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

[Dan Cross]

In article <t2pn8f$r5q$1 at news.misty.com>,
Johnny Billquist  <bqt at softjar.se> wrote:
>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.

The last time this came up where I was involved, the murky stuff
revolved around precise semantics of generated loads and stores.
What you wrote above is true, but suppose I'm doing multiple
stores into aligned buffers; can the compiler lower into stores
into a larger datum, or must they be kept distinct?  That is,
suppose I'm writing a bunch of uint16_t's from an aligned source
into an aligned destination; can the compiler turn that into
corresponding loads/stores of uint32_t?  Can it write to the
same byte twice?  And how do I work with volatile byte buffers
without memcpy?

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

Can't argue with that. :-)

	- Dan C.