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

[Johnny Billquist]

On 2022-04-08 15:33, Arne Vajhøj wrote:
> 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:
>>> 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.

Sadly, it seems that people that profess to believe in C are not getting 
what Dan is saying. While I actually like C, and do a lot of work in it, 
Dan is absolutely right in that C have sortof silently failed lately. 
With most people not realizing it.

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

Actually, you might get surprised about what C compilers might do with 
this in some circumstances. If the size of the destination (c) is 
smaller than a and/or b, and the compiler knows that the result is going 
to be too large to fit, then you are again in UB. Which means the 
compiler is allowed to do anything, including do nothing at all (even 
though it might just be simple integer operations).
So that "c = a + b;" might actually end up being optimized away totally.
Which probably would surprise quite a number of people who wrote such a 
line.

Or, as I had to explain to a colleague of mine at one point.
If you have two unsigned values multiplied, and the resulting value is 
stored in a signed destination, any check for a value less than zero can 
be optimzied away, because obviously the value can never be less than 
zero. Disregarding the fact that the actual hardware, if giving such a 
multiplication, might wrap, and end up with a value that is actually 
less than zero.
The colleague had the test in his code, and it never triggered, but 
printing the value out for sure showed that it was less than zero.

The compiler was technically allowed to do that optimization, since it's 
UB. The writer of the code wanted to know if the value had wrapped. 
Sorry, C does not actually allow you to find that out.

Took some examining of the resulting machine code before I realized what 
the "problem" was.

Close to the hardware? Bah. You'll have to do silly stuff these days to 
just get what the hardware actually is doing, since C compilers so 
aggressively "abuse" UB.

   Johnny