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

[Johnny Billquist]

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

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.

>> There are other parts that are much more devious in C these days.
> 
> Can't argue with that. :-)

:-)

   Johnny