Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

> On 1/10/2023 9:50 PM, Tim Rentsch wrote:
>
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>
>>> On 12/24/2022 12:50 AM, Tim Rentsch wrote:
>>>
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>
>>>>> Anton Ertl wrote:
>>>>>
>>>>>> Michael S <already5chosen@yahoo.com> writes:
>>>>>>
>>>>>>> On Tuesday, December 20, 2022 at 1:15:29 PM UTC+2, Anton Ertl wrote:
>>>>>>>
>>>>>>>> Let's see. I took the classical idiom,
>>>>>>>
>>>>>>> I am not at all sure that what you call "classical idiom" is
>>>>>>> indeed classical. How many compilers recognize this idiom?
>>>>>>
>>>>>> That's not the point. I assume that people used that idiom
>>>>>> before any compiler recognized it and compiled it to a rot,
>>>>>> because it's the most obvious way to synthesize it out of shifts.
>>>>>> Or do you consider any of the other ways more obvious?
>>>>>>
>>>>>> And then compiler maintainers taught the compilers that idiom,
>>>>>> because that's what people wrote.
>>>>>
>>>>> I was going to forgive the compiiler people defining (x << (64-n))
>>>>> as UB when it can detect that n is zero, but then I saw the
>>>>> argument (was it yours?) that there only exists two different ways
>>>>> for hardware to handle this:
>>>>>
>>>>> x >> 64 is either masked by 63 into a NOP, resulting in x, or it
>>>>> will return 0, no other options are possible.
>>>>>
>>>>> When combined with the right shift into the classic
>>>>> ((x>>n)|(x<<(64-n))) idiom, there is no real excuse for claiming
>>>>> UB since all hardware will in fact return x for n == 64, even
>>>>> though the left shift by 64 is technically UB.
>>>>>
>>>>> I.e. I really do want the same compiler guys to be smart enough to
>>>>> recognize that when a given construct will always return the same
>>>>> result on all exisiting platforms, then that is also what the
>>>>> compiler should generate.
>>>>>
>>>>> Just go ahead and recognize such idioms _before_ tainting
>>>>> everything with UB. [...]
>>>>
>>>> There are some misunderstandings here that I think are worth
>>>> clearing up.
>>>>
>>>> The C standard doesn't get to dictate how hardware should behave.
>>>> In fact it is very much the opposite, the C standard tries to
>>>> accommodate as wide a range of hardware and hardware behaviors as
>>>> it reasonably can.
>>>>
>>>> At the same time, the C language tries to be faithful to whatever
>>>> hardware it runs on. C does not try to abstract away the various
>>>> inconvenient machine behaviors to make the language nicer. In
>>>> this respect C is a "low level" language, at least for most
>>>> operations.
>>>>
>>>> These two aspects taken together put the C standard in a bit of a
>>>> bind. What happens when a particular operation does X on some
>>>> machines, does Y on some other machines, and on still other
>>>> machines causes a program fault? In such cases the C standard
>>>> defines the semantics of said operation to be "undefined
>>>> behavior", which allows the implementation (and therefore the
>>>> compiler) to do anything at all.
>>>
>>> While I agree with your statement of the situation, in this case,
>>> ISTM is an ideal situation for "implementation defined behavior".
>>> Note that I am certainly not a language lawyer not a standards
>>> writer. But if, as you describe above there are a modest number
>>> of reasonable possibilities, and I think each one could be pretty
>>> easily described, ISTM that "punting" and saying the compiler can
>>> do anything at all, without any explanation is much less
>>> "optimal". But again, I will admit that I may not understand all
>>> the implications. :-(
>
> Two preliminaries.
>
> 1. In deference to Mitch's comments, I have changed the title of
> the subthread, and marked it OT.
>
> 2. Thank you for your patience in trying to explain this to me.

I appreciate your thank you. My apologies for taking so long to
follow up here.

>> Two comments.
>>
>> We know what some machines do, but may not know what all machines
>> do. The presence of a machine check on one machine suggests
>> there may be disastrous consequence on some other machine that we
>> don't know about. The C standards committee can't be expected to
>> know what happens on every machine in existence, or what may
>> happen on some future machine. Given the absence of complete
>> information, we have to make the best guess based on what we know
>> now. Under the stated circumstances, it seems prudent to allow a
>> wide latitude, and undefined behavior is the only option that
>> fills that bill.
>
> Again, I may be misunderstanding, but ISTM that nothing about ID
> requires the standards committee to be omniscient. There is no
> requirement for the standard to list all the possible
> implementations. The only requirement is that the compiler implementer
> document what it does. If a new machine does something that the
> standards group didn't anticipate, as long as that "something" is
> documented, the ID should be OK.

They need to know that what might happen will be "in the
ballpark". C code is supposed to map roughly directly
onto machine instructions; it isn't a high level language.

>> Even if we assume that the stated behaviors cover the space of
>> all potential C implementations, there is still a problem with
>> the possibility of a machine check. Although what happens in
>> that case may be describable in terms of the machine hardware, it
>> is not describable in terms of the C abstract machine.
>
> Interesting. I hadn't thought of that. But in this case (rotate
> instructions), it should be possible for any otherwise compliant
> implementation to generate code (perhaps at some efficiency cost) to
> accomplish what is required. So no need to accommodate machine
> checks. Contrast this with, for example, dereferencing a pointer that
> may be out of range and cause a machine check. That would be
> undefined, and I am fine with that.

There is no question that something could be done. That
doesn't mean it should be done. The problem with making
out-of-bounds rotate instructions be implementation-defined
behavior is they can't be counted on to do anything useful.
Also, despite what you think, it isn't always easy to guard
against an out-of-bounds rotate generating a trap representation,
which makes the result fall into the realm of undefined
behavior.

>> In that
>> context, basically the best we can do is what we used to call
>> PFDGB, aka "program fall down go boom". The C standardization
>> effort made a decision that implementation-defined behavior
>> cannot include such a possibility. And there is a clear reason
>> for that decision, namely, that otherwise implementation-defined
>> behavior would pretty much be meaningless -- any occurrence of
>> ID behavior might allow anything to happen. In order for the
>> term "implementation-defined behavior" to mean something useful,
>> it has to exclude arbitrarily far-ranging behaviors.
>
> Agreed. But again, in the case of rotate, I don't think that is
> necessary.

I suspect that's because you aren't thinking about the range of
possible hardware platforms that C is meant to support. Even putting
that aside, though, there is no point in making out-of-bounds rotate
instructions be implmentation-defined if the result isn't useful. If
someone writes (for 'foo' being 64 bits)

foo << (64-n)

most likely what they want, if n == 0, is either all bits zero or the
original value of foo. If the rotate operation is ID, we don't know
that we will get either of those results. There isn't any value to
making the rotate be ID, because the result will always be specific
to a particular implementation, and implementations can always choose
to define what happens in those cases, even if rotate has undefined
behavior.

On Thursday, July 20, 2023 at 8:08:11 PM UTC+1, Tim Rentsch wrote:
> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
>

> > Yes, and thank you for the explanation. But I don't see how that
> > applies to rotate.
>
> My hope is my comments here have helped you with that.

also may be useful to look up sdcc. check sizeof int.
hint: not 64.

l.