As in so far that these are floating point instructions and not integer arithmetic instructions with extended precision?
Or did I miss something?

________________________________
From: Jens Maurer <jens.maurer_at_[hidden]>
Sent: Friday, April 25, 2025 12:14:23 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>; Hans Åberg <haberg_1_at_[hidden]>
Cc: Tiago Freire <tmiguelf_at_[hidden]>
Subject: Re: [std-proposals] Integer overflow arithmetic with exceptions



On 24/04/2025 22.43, Tiago Freire via Std-Proposals wrote:
> A fused multiply add has been considered as well as a fused multiply double add (adds 2 numbers to the multiplication result instead of just one).
> While they make sense from a computer science perspective, hardware support for those operations is lacking.

Fused multiply-add has been around on x86 for 10 years.
https://en.wikipedia.org/wiki/FMA_instruction_set

And it's available on ARM:
https://stackoverflow.com/questions/43173322/how-to-turn-on-fused-multiply-add-in-gcc-for-arm-processor

In which way do you believe hardware support is lacking?

Jens


> Thus, I opted to exclude them from the proposal in order to avoid it be shot down for adding too much unsound fluff. I feel it needs a better justification, such as a form of optimization that would otherwise be too cumbersome to achieve without compiler support.
> I'm open to add them, but you need to make your case.
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Hans Åberg <haberg_1_at_[hidden]>
> *Sent:* Thursday, April 24, 2025 11:18:34 AM
> *To:* Tiago Freire <tmiguelf_at_[hidden]>
> *Cc:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Subject:* Re: Integer overflow arithmetic with exceptions
>
> I have made such a type “natural”, multiprecision unsigned, where one can check the difference. Typically, multiprecision integers are implemented as unsigned with a separate sign, and on top of that, types for rational numbers and bignum floating-point. (Haskell has always had bignum “integer” and “rational” types.)
>
> My type “natural” has an extra word at the bottom, in effect becoming a std::vector that is always nonempty. (Unlike your example, where it is at the top.)
>
> For arithmetic that does not overflow, it gives a speedup of a couple of times relative only using std::vector. It is also pleasing that it is never empty, with at least one word.
>
> One could gain several times additional speedup if one can avoid conditionals altogether in arithmetic that does not overflow, instead using CPU traps that can switch to bignum computations at need.
>
> Then one must check for each argument if it is already in bignum format. So it does not suffice with checking for overflows.
>
> One way would be to mark the low word with, say, unsigned -1, and set a trap for that; that is, if adding x+y, there should be a trap not only when it overflows, but if one of x or y is -1. Is that possible in CPUs?
>
> Also, in your proposal, you might add the carry to the multiplication function, as it is how it is used when implementing bignums, and it is good to avoid an extra function call on this low level. That is:
> template<class A>
> std::tuple<A, bool> mul(A a0, A a1, A carry = 0)
>
>> On 5 Apr 2025, at 16:42, Tiago Freire <tmiguelf_at_[hidden]> wrote:
>>
>> Hi Hans,
>> I think I'm starting to understand what you mean.
>> My proposal does not introduce Big Number abstraction, although it is part of the motivation.
>> One of the challenges to be able to create such type of abstractions is the lack of support in the language for arithmetic operations that preserve information when basic types would overflow. And although they have been staple in CPU design since as far as I’ve ever known CPUs, there is almost no way to access them in C++ other than “write your own assembly”, and there is no portal way to do it.
>> The application of such arithmetic types goes beyond big number representations.
>
>
>