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

[Dan Cross]

In article <t2uc6n$hsu$1 at news.misty.com>,
Johnny Billquist  <bqt at softjar.se> wrote:
>On 2022-04-09 21:35, Dan Cross wrote:
>> In article <t2pn8f$r5q$1 at news.misty.com>,
>> Johnny Billquist  <bqt at softjar.se> wrote:
>>> 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?
>
>No. You cannot combine two stores into one. That could mean something 
>different when dealing with hardware, and would break the semantics 
>guaranteed by volatile..

The problem, sadly, is that those semantics _aren't_ guaranteed
for volatile.

>And no, one write can also not be changed into two writes. Same reason.
>
>The actual read/write itself might have meaning, so the compiler cannot 
>do anything beyond exactly the operations on the variable specified in 
>the code.
>
>This might be accessing hardware registers, where the read/write in 
>itself triggers action. Combining two accesses into one might mean 
>something else to the hardware. If the compiler were allowed to do that, 
>you would not be able to interact with the hardware correctly.
>
>memcpy have a high risk of breaking this, since memcpy is a function 
>that are unaware of the volatile property. Properties like volatile 
>don't implicitly carry across function calls. Same with const.
>In C, such properties only exists on a variable when explicitly declared 
>in the code.
>So don't use memcpy, or any other function that isn't explicitly aware 
>of the volatile status of a variable.

I'm afraid this is off.  :-(  Please see my other response.

	- Dan C.