EricP <ThatWouldBeTelling@thevillage.com> writes:

> Tim Rentsch wrote:
>
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>
>> [some secondary discussion removed]
>>
>>> Tim Rentsch wrote:
>>>
>>>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>>>
>>>>> Stephen Fuld wrote:
>>>>>
>>>>>> On 1/11/2023 2:50 PM, MitchAlsup wrote:
>>>>>>
>>>>>>> Invariably, HW considers the rounding mode a part of the
>>>>>>> calculation and not part the variables.
>>>>>>
>>>>>> I tend to agree, [...]
>>>>>
>>>>> What Anton described is already how the compiler works -
>>>>> it uses a set of object attributes, usually inherited from the
>>>>> data type, to select a specific operator function from the set
>>>>> of functions named '+'. That function in turn maps to
>>>>> one or more instructions that implement it.
>>>>>
>>>>> This is broadly speaking how bottom-up overload resolution
>>>>> works.
>>>>>
>>>>> All is proposing is adding another attribute, round mode,
>>>>> to the data type and by implication to the object,
>>>>> and adding more operator functions named '+', '-', '*', etc
>>>>> to the operator selection tables, which map to the different
>>>>> RM instructions or to a software emulation routine.
>>>>>
>>>>> Note you have similar issues on an Alpha which supports
>>>>> both 32 and 64 bit for both VAX and IEEE - how to tell the
>>>>> compiler to use VAX fp32 '+' or IEEE fp32 '+'.
>>>>> Plus VAX FP instructions have 2 round modes, IEEE have 4.
>>>>
>>>> Using types to differentiate different formats (eg float vs
>>>> double, or VAX vs IEEE) makes sense because conceptually the
>>>> operations being performed are the same: adding two floats means
>>>> the same thing as adding two doubles, or a double and float, in
>>>> the sense that the same mathematical operation is being
>>>> referenced in the different cases, just with different kinds of
>>>> operands.
>>>
>>> Data type is defined as a data bit pattern description PLUS
>>> a set of functions that operate upon it. If the data bit pattern
>>> definition changes OR if the set of functions changes OR the
>>> function behavior changes, then it is a different data type.
>>>
>>>> Using types to differentiate different rounding modes (eg round
>>>> to nearest vs round towards zero) does not make sense, because
>>>> the operations being performed are different - conceptually
>>>> different as well as being (potentially) different in what
>>>> hardware is used.
>>>
>>> Not at all. The compiler uses operand attributes, inherited from
>>> the type definition, to select an interpretation for the ambiguous
>>> function name '+'. Adding round mode attributes to the match
>>> criteria just means more choices can be selected from.
>>>
>>>> The mathematical operations being referenced
>>>> are simply not the same. It doesn't make sense to say "this
>>>> variable wants to be rounded to nearest rather than rounded
>>>> towards zero", any more than it makes sense to say "this variable
>>>> wants to be subtracted rather than added".
>>>
>>> The function '+' is different, therefore it IS a different data
>>> type. Data type includes its set of function behaviors.
>>
>> [...]
>>
>>>> The idea of using types to differentiate different rounding
>>>> modes is (and please excuse my language here) pretty wacky.
>>>
>>> It's using types to differentiate different functional
>>> behavior, which is exactly what different rounding modes do,
>>> and no different than * mapping to different signed or unsigned
>>> multiply instructions for signed or unsigned integer types.
>>
>> What your comments offer is more like a philisophic viewpoint
>> than an objective argument. I think its basic assumptions have
>> some issues, but let's ignore that for now. The key problem here
>> is that is this point of view is not a good fit for hardware
>> architecture models, nor for the IEEE floating-point spec, and
>> especially not for the C programming language.
>
> I see my suggestion as a pragmatic approach for getting a compiled
> language to generate the code a programmer wants.
>
> Compilers have used data types and overload resolution to direct
> instruction selection for, what, 50 years? C's fixed
> type-to-instructions mappings are expanded by C++ to include user
> defined data types, but the mechanism is basically the same.
>
> All compilers have various ways of modifying the attributes of the
> various language entities such that it modifies the generate code.
> Each compiler just does it in different ways, and the various
> popular C compilers are no different.
>
> The difference between my suggestion of using data types and
> overload resolution vs your suggestion of using different lexicons
> to invoke the same behavior comes down to ones subjective
> weighting and preferences for the pros and cons of each approach.

Okay.

> For data types a pro is it allows a single change to an attribute
> to propagate throughout a whole system by just recompiling.
> Another pro is that syntax for applying attributes to entities can
> be standardized so the syntax doesn't change for each
> implementation.
>
> A con is that one cannot tell just by looking at an operator what
> it does - this is inherent in overloading - so one must keep the
> variables' data type in mind when reading code. However I have
> never found remembering variable data types to be a burdened
> (except when I went crazy using overloading, and learned not to do
> that).
>
> For lexicons a pro is that one can see at a glance what "*.rne"
> means. The con is that if you want to change that function one
> has to edit all the code - possibly millions of lines for a large
> system. Also con is that since these features are platform
> dependent, this approach implies a different lexicon and therefore
> different syntax for each implementation (unless you want to wait
> for some committee to bless ones changes).
>
> From a technical point of view both can accomplish the objective
> of getting the compiler to spit out a particular instruction bit
> pattern.

Yes, compilers can be made to provide either approach (or even,
god forbid, a mixture).

> The difference comes down to how one wants to manage code changes
> to make use of these features, with possibly a large code base
> affected.

I would say something more like, the difference comes down to how
easy or hard it is to write, modify, read, and understand
programs (of varying sizes) under the two approaches. If you
agree with that then I think we both understand each other.