On Friday, May 28, 2021 at 11:07:47 PM UTC+3, Terje Mathisen wrote:
> Thomas Koenig wrote:
> > Terje Mathisen <terje.m...@tmsw.no> schrieb:
> >
> >> I see you already figured this out, but I'm still posting to illustrate
> >> that it is hard to do long chain carry propagation without having the
> >> moral equivalent of ADC.
> >
> > I just browsed around a bit, and I found that, on x86 at least, you
> > can use _addcarryx_u64.
> Right, this was the intrinsic I used for both of my 128 and 256-bit
> examples.

But why?
Both of your examples should work fine with plain old _addcarry_u64 ()
Or am I missing something?

> >
> > clang gets this right: https://gcc.godbolt.org/z/b9dTn8aWj
> > whereas gcc currently does not, as you can see in
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173 .
> >
> clang is very swiftly leaving gcc well behind for all new development.
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

In article <2021May29.184428@mips.complang.tuwien.ac.at>,
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> It looks to me like this C++ ABI is based on the regular ABI (C and
> Fortran features), and defines various C++ things in terms of that,
> and that's why it can transcend individual architectures.

That's correct. The Itanium required some systematic thinking about
calling conventions and ABIs, which is why the name stuck to the new
convention.

I had to change a lot of stuff in an extensible printf implementation to
support Itanium, but that also fixed problems I had on MIPS. Upgrading it
for other architectures since then since then has been comparatively
simple.

John

MitchAlsup wrote:
> On Friday, May 28, 2021 at 3:07:47 PM UTC-5, Terje Mathisen wrote:
>> Thomas Koenig wrote:
>>> Terje Mathisen <terje.m...@tmsw.no> schrieb:
>>>
>>>> I see you already figured this out, but I'm still posting to illustrate
>>>> that it is hard to do long chain carry propagation without having the
>>>> moral equivalent of ADC.
>>>
>>> I just browsed around a bit, and I found that, on x86 at least, you
>>> can use _addcarryx_u64.
>> Right, this was the intrinsic I used for both of my 128 and 256-bit
>> examples.
>>>
>>> clang gets this right: https://gcc.godbolt.org/z/b9dTn8aWj
>>> whereas gcc currently does not, as you can see in
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173 .
>>>
>> clang is very swiftly leaving gcc well behind for all new development.
> <
> Is that because GCC has grown into an impossible monster,
> ....that because GCC licensing requirements
> or that more people have jumped onto clang
> ....that clang is easier to develop ??

Maybe "all of the above?"

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Michael S wrote:
> On Friday, May 28, 2021 at 11:07:47 PM UTC+3, Terje Mathisen wrote:
>> Thomas Koenig wrote:
>>> Terje Mathisen <terje.m...@tmsw.no> schrieb:
>>>
>>>> I see you already figured this out, but I'm still posting to illustrate
>>>> that it is hard to do long chain carry propagation without having the
>>>> moral equivalent of ADC.
>>>
>>> I just browsed around a bit, and I found that, on x86 at least, you
>>> can use _addcarryx_u64.
>> Right, this was the intrinsic I used for both of my 128 and 256-bit
>> examples.
>
> But why?
> Both of your examples should work fine with plain old _addcarry_u64 ()
> Or am I missing something?

Not really:

This is just me that consider these two instrinsics to effectively be
the same, and I suspect that some (most?) compielrs that support them
will in fact generate effectively the same code for both.

The main differentiator is probably that on a very old CPU, using the
'x' version would fail because the new carry/overflow instruction are
unsupported.

IMHO, it will be extremely rare to see production code using the new
instructions to generate two carry chains simultaneously, since they
effectively (modulo the JRCXZ trick I posted a couple of days ago)
cannot be used in loops, only in short unrolled code blocks.

When you only need one chain of limited length, then plain old
ADD/ADC/ADC/ADC... works perfectly well. Using only the new carry-based
instruction makes it easier to create relatively normal loops since you
can combine ADCX with LOOP.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Saturday, May 29, 2021 at 9:17:52 PM UTC+3, Terje Mathisen wrote:
> Michael S wrote:
> > On Friday, May 28, 2021 at 11:07:47 PM UTC+3, Terje Mathisen wrote:
> >> Thomas Koenig wrote:
> >>> Terje Mathisen <terje.m...@tmsw.no> schrieb:
> >>>
> >>>> I see you already figured this out, but I'm still posting to illustrate
> >>>> that it is hard to do long chain carry propagation without having the
> >>>> moral equivalent of ADC.
> >>>
> >>> I just browsed around a bit, and I found that, on x86 at least, you
> >>> can use _addcarryx_u64.
> >> Right, this was the intrinsic I used for both of my 128 and 256-bit
> >> examples.
> >
> > But why?
> > Both of your examples should work fine with plain old _addcarry_u64 ()
> > Or am I missing something?
> Not really:
>
> This is just me that consider these two instrinsics to effectively be
> the same, and I suspect that some (most?) compielrs that support them
> will in fact generate effectively the same code for both.
>
> The main differentiator is probably that on a very old CPU,

Both my main home desktop and my main work desktop. Both Ivy Bridge.
By single-threaded non-vector performance they, esp. the work desktop, are still less than twice slower than the latest greatest Zen3.

And there exist much newer CPUs that do not support ADX. Like Haswell.
Or Tremont that was launched last year.

> using the
> 'x' version would fail because the new carry/overflow instruction are
> unsupported.
>
> IMHO, it will be extremely rare to see production code using the new
> instructions to generate two carry chains simultaneously, since they
> effectively (modulo the JRCXZ trick I posted a couple of days ago)
> cannot be used in loops, only in short unrolled code blocks.
>
> When you only need one chain of limited length, then plain old
> ADD/ADC/ADC/ADC... works perfectly well. Using only the new carry-based
> instruction makes it easier to create relatively normal loops since you
> can combine ADCX with LOOP.
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On Saturday, May 29, 2021 at 11:48:56 AM UTC-5, Anton Ertl wrote:
> Thomas Koenig <tko...@netcologne.de> writes:
> >The ABI especially for C++
> >was taken from the Itanium ABI, which you can find at
> >https://itanium-cxx-abi.github.io/cxx-abi/ , so people refer to the
> >whole thing as the "Itanium ABI" although that is not 100% correct.
> Thanks. I am not into C++, so I have never heard about "Itanium ABI"
> before. A quick skim did not reveal anything about struct returns.
> It looks to me like this C++ ABI is based on the regular ABI (C and
> Fortran features), and defines various C++ things in terms of that,
> and that's why it can transcend individual architectures.
<
There is a large section that deals with the integration of TRY-THROW-CATCH
exception handling with longjump all integrated together. This whole mess
is stitched together with a personality module that knows how to access
ELF given an IP and annotate where on the stack the return IP is currently
stored. Along with this is some means of finding the "new" data and their
respective destructors. So the stack can be walked back remotely.
<
That section is as big as the C+FORTRAN ABI is big.
<
Which leads me to ask:: Has anyone structured the epilogues of C++
routines such that the calls to the destructors is an actual call in the
epilogue, so that one does not have to make walking the stack backwards
an interpreted affair, but the stack walker can simply call the same set
of destructors--vastly simplifying the problem space?? Ivan ??
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On 5/29/2021 12:16 PM, MitchAlsup wrote:
> On Saturday, May 29, 2021 at 11:48:56 AM UTC-5, Anton Ertl wrote:
>> Thomas Koenig <tko...@netcologne.de> writes:
>>> The ABI especially for C++
>>> was taken from the Itanium ABI, which you can find at
>>> https://itanium-cxx-abi.github.io/cxx-abi/ , so people refer to the
>>> whole thing as the "Itanium ABI" although that is not 100% correct.
>> Thanks. I am not into C++, so I have never heard about "Itanium ABI"
>> before. A quick skim did not reveal anything about struct returns.
>> It looks to me like this C++ ABI is based on the regular ABI (C and
>> Fortran features), and defines various C++ things in terms of that,
>> and that's why it can transcend individual architectures.
> <
> There is a large section that deals with the integration of TRY-THROW-CATCH
> exception handling with longjump all integrated together. This whole mess
> is stitched together with a personality module that knows how to access
> ELF given an IP and annotate where on the stack the return IP is currently
> stored. Along with this is some means of finding the "new" data and their
> respective destructors. So the stack can be walked back remotely.
> <
> That section is as big as the C+FORTRAN ABI is big.
> <
> Which leads me to ask:: Has anyone structured the epilogues of C++
> routines such that the calls to the destructors is an actual call in the
> epilogue, so that one does not have to make walking the stack backwards
> an interpreted affair, but the stack walker can simply call the same set
> of destructors--vastly simplifying the problem space?? Ivan ??

Funny you should mention my name. Mill kernel is in C++ (or will be - in
process), so throw/catch can't use interp. NYF

On Saturday, May 29, 2021 at 2:16:19 PM UTC-5, MitchAlsup wrote:
> On Saturday, May 29, 2021 at 11:48:56 AM UTC-5, Anton Ertl wrote:
> > Thomas Koenig <tko...@netcologne.de> writes:
> > >The ABI especially for C++
> > >was taken from the Itanium ABI, which you can find at
> > >https://itanium-cxx-abi.github.io/cxx-abi/ , so people refer to the
> > >whole thing as the "Itanium ABI" although that is not 100% correct.
> > Thanks. I am not into C++, so I have never heard about "Itanium ABI"
> > before. A quick skim did not reveal anything about struct returns.
> > It looks to me like this C++ ABI is based on the regular ABI (C and
> > Fortran features), and defines various C++ things in terms of that,
> > and that's why it can transcend individual architectures.
> <
> There is a large section that deals with the integration of TRY-THROW-CATCH
> exception handling with longjump all integrated together. This whole mess
> is stitched together with a personality module that knows how to access
> ELF given an IP and annotate where on the stack the return IP is currently
> stored. Along with this is some means of finding the "new" data and their
> respective destructors. So the stack can be walked back remotely.
> <
> That section is as big as the C+FORTRAN ABI is big.
> <
> Which leads me to ask:: Has anyone structured the epilogues of C++
> routines such that the calls to the destructors is an actual call in the
> epilogue, so that one does not have to make walking the stack backwards
> an interpreted affair, but the stack walker can simply call the same set
> of destructors--vastly simplifying the problem space?? Ivan ??
<
Perhaps my wording was insufficient::
<
I have been led to believe that the epilogue of a C++ routine needing
destructors is something like::
<
exit:
for( type = 0; type < types; type ++ )
for(i = 0; i < number; i++)
destructor[type]( pointer[i] );
LDM Rpreserved,[SP,offset]
add SP,SP,sizeof_stack_frame
return
<
Whereas if the epilogue was structured::
exit:
call subroutine_destructors( pointer_to_compiler_data_on_stack );
LDM Rpreserved,[SP,offset]
add SP,SP,sizeof_stack_frame
return
<
then the stack back walker could simple call "subroutine_destructors()" rather
than perform the double for loop in an interpreter.
<
> <
> > - anton
> > --
> > 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> > Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

> Perhaps my wording was insufficient::
> <
> I have been led to believe that the epilogue of a C++ routine needing
> destructors is something like::
> <
> exit:
> for( type = 0; type < types; type ++ )
> for(i = 0; i < number; i++)
> destructor[type]( pointer[i] );
> LDM Rpreserved,[SP,offset]
> add SP,SP,sizeof_stack_frame
> return
> <
> Whereas if the epilogue was structured::
> exit:
> call subroutine_destructors( pointer_to_compiler_data_on_stack );
> LDM Rpreserved,[SP,offset]
> add SP,SP,sizeof_stack_frame
> return
> <
> then the stack back walker could simple call "subroutine_destructors()" rather
> than perform the double for loop in an interpreter.

I suspect this design choice was made under the hypothesis that
non-local exits are rare: this design allows the "normal exit" case to
be implemented more efficiently (basically by inlining your
`subroutine_destructors` function) at the cost of a slower stack-walk.

Also, maybe the "slow interpreted stack walk" is not quite as slow as it
looks because its code is a small loop that might more easily fit into
the I$ than your `subroutine_destructors` functions which would end up
scattered all over the code segment and occupying more space?

I'm really asking the question: I don't know the answer at all.
It just reminded me of a similar situation for GCs where it's usually
more efficient to have each object come with a pointer to a small
data-structure describing which fields hold data in which format (and
then have a small loop "interpret" that data-structure to find the
pointers) than to have each object come with a pointer to a chunk of
code that "marks" or "copies" objects of that type.
Of course, the tradeoff depends on the complexity of the data-structure
that needs to be interpreted, but usually (for GCs) you can arrange for
it to be sufficiently simple that it ends up being a very
efficient/tight loop.

Stefan

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>The ABI especially for C++
>>was taken from the Itanium ABI, which you can find at
>>https://itanium-cxx-abi.github.io/cxx-abi/ , so people refer to the
>>whole thing as the "Itanium ABI" although that is not 100% correct.
>
> Thanks. I am not into C++, so I have never heard about "Itanium ABI"
> before. A quick skim did not reveal anything about struct returns.

For that, you want to look for the different "Architecture Processor
Supplement"s to the "System V Application Binary Interface".

Offhand, I can find it for AMD64 and for MIPS.

> It looks to me like this C++ ABI is based on the regular ABI (C and
> Fortran features), and defines various C++ things in terms of that,
> and that's why it can transcend individual architectures.

That is correct.

John Levine <johnl@taugh.com> writes:
>It does make the assertion that he rewrote everything in fixed point to
>make it faster seem a bit naive.

I have now found the data from Bentley's book:

PDP-KL10 HP1000 # step
Pascal C
5.73 4.39 1 Original
5.56 4.27 2 Common Subexpression Elimination
2.95 2.78 3 Eliminate sqrt()
2.59 2.63 4 Eliminate visited[]
1.71 1.72 5 Inline DistSqrd()
1 1 6 Compute Y-Distance later
0.91 0.86 7 Integers instead of Floats
0.84 0.84 8 Direct reordering instead of using index array
0.83 - 9 Sentinel

Step 7 is the one relevant to this discussion. So he saw a speedup,
but it was not very big.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Monday, May 10, 2021 at 10:49:11 AM UTC-6, Ivan Godard wrote:

> Do you have any saturating multiplies? Why or why not?

Not realizing that anyone would find them useful, I had not
included them even in my everything but the kitchen sink
original Concertina architecture.

But if they are useful, although in _some_ places opcode
space is at a premium, I have plenty of space for additional
operate instructions.

John Savard

On Friday, June 4, 2021 at 4:51:26 PM UTC-5, Quadibloc wrote:
> On Monday, May 10, 2021 at 10:49:11 AM UTC-6, Ivan Godard wrote:
>
> > Do you have any saturating multiplies? Why or why not?
>
> Not realizing that anyone would find them useful, I had not
> included them even in my everything but the kitchen sink
> original Concertina architecture.
>
> But if they are useful, although in _some_ places opcode
> space is at a premium, I have plenty of space for additional
> operate instructions.
<
You could borrow the My 66000 trick and use a SAT instruction to
add saturation to several of the following instructions, avoiding the
OpCode space premium.
>
> John Savard

On Friday, June 4, 2021 at 5:18:25 PM UTC-6, MitchAlsup wrote:

> You could borrow the My 66000 trick and use a SAT instruction to
> add saturation to several of the following instructions, avoiding the
> OpCode space premium.

At the moment, I don't inclulde any kind of prefixed instruction, since
that would mean that it would no longer be the case that, once the block
header is decoded, the computer now knows where every instruction in
the block starts, and can just decode it and (except for stuff like
dependencies) run with it.

This is why I've gone to such lengths to have determination of instruction
length require _zero_ gate delays per individual instruction. There are a
few gate delays for the block as a whole, then that's it, no matter how many
instructions there are in the block.

However, I have a header format allowing accelerated emulation of instruction
sets where instruction lengths are multiples of 16 bits. Like the 360 or the 680x0.
So this architecture is capable of just *borrowing the entire My 66000 ISA*.

I may end up, once I figure out a worthwhile way of translating addresses, adding
a bit to that header format to enable or disable address conversion - addresses in
jump instructions, at the moment, have to be changed to actual addresses in memory
allowing for each block having 32 overhead bits. True emulation would allow running
programs in the target ISA intact, without modification, but I want to avoid having to
indicate a starting point for the multiplication by 8/7.

John Savard

Ivan Godard <ivan@millcomputing.com> writes:

> On 5/26/2021 10:52 PM, Terje Mathisen wrote:
>
>> Ivan Godard wrote:
>>
>>> On 5/26/2021 10:04 AM, MitchAlsup wrote:
>>>
>>>> On Wednesday, May 26, 2021 at 10:53:02 AM UTC-5, Stephen Fuld wrote:
>>>>
>>>>> On 5/21/2021 3:59 PM, MitchAlsup wrote:
>>>>>
>>>>>> On Friday, May 21, 2021 at 5:00:17 PM UTC-5, Stephen Fuld wrote:
>>>>>>
>>>>>>> On 5/21/2021 12:40 PM, EricP wrote:
>>>>>>>
>>>>>>>> Stephen Fuld wrote:
>>>>>>>>
>>>>>>>>> On 5/20/2021 9:34 AM, MitchAlsup wrote:
>>>>>>>>>
>>>>>>>>>> On Thursday, May 20, 2021 at 10:08:32 AM UTC-5, Stephen Fuld
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 5/19/2021 11:40 PM, Niklas Holsti wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 2021-05-20 3:40, Stephen Fuld wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5/19/2021 8:47 AM, EricP wrote:
>>>>>>>>>>>
>>>>>>>>>>> Fair enough. This sort of gets back to the question of
>>>>>>>>>>> whether to add a
>>>>>>>>>>> feature like this as an attribute of the variable
>>>>>>>>>>> (e.g. range) or of
>>>>>>>>>>> the
>>>>>>>>>>> operation (e.g. bignum). I think there are arguments for each.
>>>>>>>>>>>
>>>>>>>>>>> BTW, I am unsure of what the requirement is here. Suppose
>>>>>>>>>>> you have a
>>>>>>>>>>> variable with a range of 10-90. Do you want saturation at
>>>>>>>>>>> 90? That is
>>>>>>>>>>
>>>>>>>>>> If the value to be written is outside of the range [10..90]
>>>>>>>>>> you raise an
>>>>>>>>>> exception. The raised exception decides what to do.
>>>>>>>>>
>>>>>>>>> Certainly true for the non-saturating case, and is what Ada
>>>>>>>>> does. My
>>>>>>>>> question is if you define saturating variables, what to do if you
>>>>>>>>> somehow define the variable with a range *and* saturating.
>>>>>>>>
>>>>>>>> Any variables that are smaller than the machine register size are
>>>>>>>> promoted to that size by either sign or zero extension.
>>>>>>>>
>>>>>>>> Expressions are executed using signed or unsigned checked or
>>>>>>>> saturating
>>>>>>>> operations at that machine size. This detects intermediate signed or
>>>>>>>> unsigned overflows of the machine size results.
>>>>>>>>
>>>>>>>> I have instructions for trap on unsigned carry or signed overflow.
>>>>>>>> I have an ADGO Add Generate Overflow and ADGC Add Generate Carry
>>>>>>>> to set a 1 in the output register for overflow or carry.
>>>>>>>> Then a LIC Load Immediate Conditional loads saturation limit values.
>>>>>>>> One could have arithmetic instructions that saturate.
>>>>>>>>
>>>>>>>> The result is copied back to the variable. If there are
>>>>>>>> constraints on
>>>>>>>> the variable different from the limits on the physical register
>>>>>>>> then those are range checked and either saturated or trapped.
>>>>>>>> A CMPGT and CMPLT with a LIC loads upper or lower saturation value.
>>>>>>>>
>>>>>>>> Note that setting limits on variable to be in the range 10..90 does
>>>>>>>> not mean that expression intermediate results are within that range.
>>>>>>>> It means an expression EITHER produces the arithmetically
>>>>>>>> correct result
>>>>>>>> in that range, or it saturates or traps.
>>>>>>>
>>>>>>> That is certainly one way to do it. All the different ways have
>>>>>>> drawbacks. Mitch pointed out some of the ones for you choice in his
>>>>>>> followup.
>>>>>>>
>>>>>>> I don't know enough to have strong feelings as to the best choice. As
>>>>>>> Thomas Koening said earlier in this thread, it takes a lot of
>>>>>>> thought.
>>>>>>
>>>>>> This brings to mind that the whole concept of arithmetic exceptions is
>>>>>> fundamentally flawed.
>>>>>> It is not the arithmetic that should be checked for out-of-range
>>>>>> values
>>>>>> it is the depositing of values into containers that should be checked.
>>>>>
>>>>> While I generally agree, there is apparently some use for checking
>>>>> intermediate results in calculations. Then the question becomes what is
>>>>> the best way, language syntax wise (i.e. not a question of ISA,
>>>>> as there
>>>>> are several ways to do that depending upon ISA) to indicate that.
>>>>>
>>>>> Note that I am going to consider this in terms a generalized range
>>>>> restriction a` la Ada Range attributes, as resolving this for that case
>>>>> automatically includes the cases of overflow of byte sized variables in
>>>>> 64 bit registers, etc.
>>>>>
>>>>> Perhaps the easiest way to indicate this is the break the calculation
>>>>> into individual steps, storing the intermediate results, thus
>>>>> triggering
>>>>> the range checks.
>>>>>
>>>>> Lets use a simple example.
>>>>>
>>>>> X = A + B - C where A+B might be out of range, but after C is
>>>>> subtracted
>>>>> X is within range.
>>>>>
>>>>> You could code this as
>>>>>
>>>>> X = A + B
>>>>> X = X - C
>>>>
>>>> In general, I am a great fan of shorter assignment statements (as above)
>>>> and while there are more assignments, there may be fewer instructions
>>>> created, and the programmer himself can see the common sub-expressions.
>>>>
>>>>> Of course, the compiler would have to recognize that X had a range and
>>>>> actually do the check, even if it doesn't actually do the first store.
>>>>>
>>>>> Another alternative is the use a "function" to indicate that the check
>>>>> should be done. This is a generalization of the cast mechanism in C.
>>>>>
>>>>> i.e. something like
>>>>>
>>>>> X = Rangechk (A + B) - C ; Rangechk tests the bounds of X
>>>>>
>>>>>
>>>>> Another alternative is back to the discussion of whether the
>>>>> checking of
>>>>> intermediate values should be a property of the variable (like Range
>>>>> itself) or the calculation. If it is a property of the variable you
>>>>> could have syntax to indicate that, i.e. add RangeIVC (for intermediate
>>>>> value checked), which would indicate to check the intermediate values
>>>>> for any expression that assigns a value to the variable with that
>>>>> attribute.
>>>>>
>>>>> I don't have a strong feeling about what is the best solution,
>>>>> and there
>>>>> may be better ones than what I have suggested.
>>>>
>>>> May I suggest a whip instead of a language addition !! That is the code
>>>> review process should not allow x = a + b - c; into production code if
>>>> there is any reason to believe it can behave maliciously !! or unbox
>>>> the nasal demons of destruction !
>>>> There are codes which depend on the HW not caring that something
>>>> has lost precision on one end (integral) or the other (FP). For example
>>>> Knuth's TwoSum::
>>>> {double, double} TwoSum( double a, double b )
>>>> { // Knuth
>>>> x = a + b ;
>>>> q = x - a ;
>>>> r = x - q ;
>>>> s = b - q ;
>>>> t = a - r ;
>>>> y = s + t ;
>>>> return { x, y };
>>>> }
>>>> This subroutine performs addition and puts all of the bits of a+b that
>>>> fit into x, and all of the bits that do not fit into y,
>>>> branchlessly. The
>>>> numerical analyst went to great trouble to align all the arithmetic
>>>> so that precisely this would be the result.
>>>> An "optimizing" might come to the conclusion that q == b and ruin
>>>> the whole sequence !!
>>>> On the other hand I designed My 66000 so that one can write this as::
>>>> {double, double} TwoSum( double a, double b )
>>>> {
>>>> return {double, double} = a + b;
>>>> }
>>>
>>> Does your actual compiler currently accept this as source? If not,
>>> what do you actually have to write to get the requisite machine
>>> code from your implemented compiler?
>>
>> The traditional C way, as exemplified by lots of compiler
>> intrinsics, is to use a pointer to any additional return values:
>>
>> double AugmentedAddition(double a, double b, double *lopart)
>> {
>> // Knuth
>> x = a + b ;
>> q = x - a ;
>> r = x - q ;
>> s = b - q ;
>> t = a - r ;
>> *lopart = s + t ;
>> return x;
>> }
>>
>> I.e. Intel's add_carryx_u64() returns both the full adder result and
>> the outgoing carry.
>
> Which is regrettable when without restrict and inlining, and doubtful
> even then.

Thomas Koenig <tkoenig@netcologne.de> writes:

> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>
>> A common source of
>> errors is implicit type conversions in C, for instance.
>
> The integral promotions from signed to unsigned of the
> same size are the worst.
>
> int a = -3;
> unsigned int b = 2;
> if (a > b)
> printf ("You expected this to happen, right?\n");

The C standard uses the term "integer promotions" rather than
"integral promotions", but in any case what is going on here
falls under the heading of "usual arithmetic conversions",
not "integer promotions". (Integer promotions are things
like turning a 'short' into an 'int'.)

On Thursday, June 17, 2021 at 12:38:33 PM UTC-5, Tim Rentsch wrote:
> Thomas Koenig <tko...@netcologne.de> writes:
>
> > Marcus <m.de...@this.bitsnbites.eu> schrieb:
> >
> >> A common source of
> >> errors is implicit type conversions in C, for instance.
> >
> > The integral promotions from signed to unsigned of the
> > same size are the worst.
> >
> > int a = -3;
> > unsigned int b = 2;
> > if (a > b)
> > printf ("You expected this to happen, right?\n");
>
> The C standard uses the term "integer promotions" rather than
> "integral promotions", but in any case what is going on here
> falls under the heading of "usual arithmetic conversions",
> not "integer promotions". (Integer promotions are things
> like turning a 'short' into an 'int'.)
<
What causes the supersize is that programmers are not taught
unsigned has a lower surprise factor than integer.
<
But consider::
<
int64_t a = -3;
uint64_t b = 0xfffffffffffffffd;
if( a == b )
printf ("You expected this to happen, right?\n");

On 17/06/2021 20:22, MitchAlsup wrote:
> On Thursday, June 17, 2021 at 12:38:33 PM UTC-5, Tim Rentsch wrote:
>> Thomas Koenig <tko...@netcologne.de> writes:
>>
>>> Marcus <m.de...@this.bitsnbites.eu> schrieb:
>>>
>>>> A common source of
>>>> errors is implicit type conversions in C, for instance.
>>>
>>> The integral promotions from signed to unsigned of the
>>> same size are the worst.
>>>
>>> int a = -3;
>>> unsigned int b = 2;
>>> if (a > b)
>>> printf ("You expected this to happen, right?\n");
>>
>> The C standard uses the term "integer promotions" rather than
>> "integral promotions", but in any case what is going on here
>> falls under the heading of "usual arithmetic conversions",
>> not "integer promotions". (Integer promotions are things
>> like turning a 'short' into an 'int'.)
> <
> What causes the supersize is that programmers are not taught
> unsigned has a lower surprise factor than integer.

unsigned types in C don't have "lower surprise factor" than signed
types. They have slightly /different/ surprise factors. If you want to
program in C, you should learn how the signed and unsigned integer types
work, alone and together, and code accordingly.

There is a lot of value in using good static warning tools - enabling
"-Wsign-compare -Wsign-conversion" in gcc will give you warnings on
these things if you don't use explicit casts. You choose your own
balance between reduced risk of errors at the cost of additional effort
(such as casts) when you need to mixed signedness and know it is safe.

One problem with a lot of C teaching is that it usually fails to teach
about tools that can make programming easier and safer. Another is that
if they teach the details of integer types at all, they do so with
invalid and unhelpful generalisations like "unsigned types are better
because overflow is defined and they are therefore safe".

> <
> But consider::
> <
> int64_t a = -3;
> uint64_t b = 0xfffffffffffffffd;
> if( a == b )
> printf ("You expected this to happen, right?\n");
>

On 6/17/2021 12:24 PM, David Brown wrote:
> On 17/06/2021 20:22, MitchAlsup wrote:
>> On Thursday, June 17, 2021 at 12:38:33 PM UTC-5, Tim Rentsch wrote:
>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>
>>>> Marcus <m.de...@this.bitsnbites.eu> schrieb:
>>>>
>>>>> A common source of
>>>>> errors is implicit type conversions in C, for instance.
>>>>
>>>> The integral promotions from signed to unsigned of the
>>>> same size are the worst.
>>>>
>>>> int a = -3;
>>>> unsigned int b = 2;
>>>> if (a > b)
>>>> printf ("You expected this to happen, right?\n");
>>>
>>> The C standard uses the term "integer promotions" rather than
>>> "integral promotions", but in any case what is going on here
>>> falls under the heading of "usual arithmetic conversions",
>>> not "integer promotions". (Integer promotions are things
>>> like turning a 'short' into an 'int'.)
>> <
>> What causes the supersize is that programmers are not taught
>> unsigned has a lower surprise factor than integer.
>
> unsigned types in C don't have "lower surprise factor" than signed
> types. They have slightly /different/ surprise factors. If you want to
> program in C, you should learn how the signed and unsigned integer types
> work, alone and together, and code accordingly.
>
> There is a lot of value in using good static warning tools - enabling
> "-Wsign-compare -Wsign-conversion" in gcc will give you warnings on
> these things if you don't use explicit casts. You choose your own
> balance between reduced risk of errors at the cost of additional effort
> (such as casts) when you need to mixed signedness and know it is safe.
>
> One problem with a lot of C teaching is that it usually fails to teach
> about tools that can make programming easier and safer. Another is that
> if they teach the details of integer types at all, they do so with
> invalid and unhelpful generalisations like "unsigned types are better
> because overflow is defined and they are therefore safe".
>
>> <
>> But consider::
>> <
>> int64_t a = -3;
>> uint64_t b = 0xfffffffffffffffd;
>> if( a == b )
>> printf ("You expected this to happen, right?\n");
>>
>

The warnings are necessary, but still annoying:
for (int i = 0; i < arr.size(); i++)

for example.

On Thursday, June 17, 2021 at 1:45:44 PM UTC-6, Ivan Godard wrote:

> The warnings are necessary, but still annoying:
> for (int i = 0; i < arr.size(); i++)

> for example.

....because arr.size(), derived as it is from addresses, naturally
has unsigned type. But this is surprising to programmers coming
from languages that don't bother to provide the unsigned
integer type.

John Savard

On Thursday, June 17, 2021 at 2:24:05 PM UTC-5, David Brown wrote:
> On 17/06/2021 20:22, MitchAlsup wrote:
> > On Thursday, June 17, 2021 at 12:38:33 PM UTC-5, Tim Rentsch wrote:
> >> Thomas Koenig <tko...@netcologne.de> writes:
> >>
> >>> Marcus <m.de...@this.bitsnbites.eu> schrieb:
> >>>
> >>>> A common source of
> >>>> errors is implicit type conversions in C, for instance.
> >>>
> >>> The integral promotions from signed to unsigned of the
> >>> same size are the worst.
> >>>
> >>> int a = -3;
> >>> unsigned int b = 2;
> >>> if (a > b)
> >>> printf ("You expected this to happen, right?\n");
> >>
> >> The C standard uses the term "integer promotions" rather than
> >> "integral promotions", but in any case what is going on here
> >> falls under the heading of "usual arithmetic conversions",
> >> not "integer promotions". (Integer promotions are things
> >> like turning a 'short' into an 'int'.)
> > <
> > What causes the supersize is that programmers are not taught
> > unsigned has a lower surprise factor than integer.
<
> unsigned types in C don't have "lower surprise factor" than signed
> types. They have slightly /different/ surprise factors. If you want to
> program in C, you should learn how the signed and unsigned integer types
> work, alone and together, and code accordingly.
<
While they do have different surprise factors, the unsigned variety is lower
because when signed an unsigned are mixed, the unsigned takes precedent.
<
And as I have stated many times: the only time I EVER use a signed type
is when at some point it has to contain a negative value. Then, again, if
it always contains a negative value (never positive) I STILL use unsigned
and subtract rather than add.
<
About the only time I use a signed integer type is when interfacing with a
library routine which has parameters or result defined as signed.
>
> There is a lot of value in using good static warning tools - enabling
> "-Wsign-compare -Wsign-conversion" in gcc will give you warnings on
> these things if you don't use explicit casts. You choose your own
> balance between reduced risk of errors at the cost of additional effort
> (such as casts) when you need to mixed signedness and know it is safe.
>
> One problem with a lot of C teaching is that it usually fails to teach
> about tools that can make programming easier and safer. Another is that
> if they teach the details of integer types at all, they do so with
> invalid and unhelpful generalisations like "unsigned types are better
> because overflow is defined and they are therefore safe".
> > <
> > But consider::
> > <
> > int64_t a = -3;
> > uint64_t b = 0xfffffffffffffffd;
> > if( a == b )
> > printf ("You expected this to happen, right?\n");
> >

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Thursday, June 17, 2021 at 12:38:33 PM UTC-5, Tim Rentsch wrote:
>> Thomas Koenig <tko...@netcologne.de> writes:
>>
>> > Marcus <m.de...@this.bitsnbites.eu> schrieb:
>> >
>> >> A common source of
>> >> errors is implicit type conversions in C, for instance.
>> >
>> > The integral promotions from signed to unsigned of the
>> > same size are the worst.
>> >
>> > int a = -3;
>> > unsigned int b = 2;
>> > if (a > b)
>> > printf ("You expected this to happen, right?\n");
>>
>> The C standard uses the term "integer promotions" rather than
>> "integral promotions", but in any case what is going on here
>> falls under the heading of "usual arithmetic conversions",
>> not "integer promotions". (Integer promotions are things
>> like turning a 'short' into an 'int'.)
><
> What causes the supersize is that programmers are not taught
> unsigned has a lower surprise factor than integer.
><
> But consider::
><
> int64_t a = -3;
> uint64_t b = 0xfffffffffffffffd;
> if( a == b )
> printf ("You expected this to happen, right?\n");

One of the blocks towards implementing unsigned integers in Fortran
was the discussion what to do when signed and unsigned integers
come together.

In Fortran, this being Formula Translation, it would probably make
sense to mandate comparision by value, so that

integer :: a
unsigned integer :: b

a = -3
b = 2_u ! How to specify an unsigned constant?

if (a> b) write (*,'(A)') "This should never happen"

would get the expected result. I think Sun Fortran had this.

Drawback? Not sufficiently C-like (with flashbacks to
http://james-iry.blogspot.com/2009/05/brief-incomplete-and-mostly-wrong.html
) and one more instruction.

I considered writing up a proposal for Fortran standard,
but that would very probably go down in flames - there are
too many corner cases to get right, and too many details
that reasonable people can object to on reasonable grounds
whatever you chose.

Ivan Godard <ivan@millcomputing.com> schrieb:

> The warnings are necessary, but still annoying:
> for (int i = 0; i < arr.size(); i++)

Why chose arr.size() as unsigned?

As long as the types are long enough that overflow is not
an issue (as should be the case with 64-bit types), signed
has far nicer properties.

On 18/06/2021 00:24, Quadibloc wrote:
> On Thursday, June 17, 2021 at 1:45:44 PM UTC-6, Ivan Godard wrote:
>
>> The warnings are necessary, but still annoying:
>> for (int i = 0; i < arr.size(); i++)
>

(I note that we are now in C++, rather than C.)

>> for example.
>
> ...because arr.size(), derived as it is from addresses, naturally
> has unsigned type. But this is surprising to programmers coming
> from languages that don't bother to provide the unsigned
> integer type.
>

Indeed, the return type of arr.size() is size_t - not only is it
unsigned, but it is often bigger than "int". On 64-bit systems, size_t
is typically going to be either "unsigned long" or "unsigned long long".
Thus the correct code is:

for (size_t i = 0; i < arr.size(); i++)

C++ has "auto", which can often be handy for avoiding having to specify
exact types. (Like many features, it can be useful but can also be abused.)

Unfortunately, if you write:

for (auto i = 0; i < arr.size(); i++)

then "i" gets the type of "0", which is of course "int".

You could do:

for (auto i = 0ull; i < arr.size(); i++)

or (expected for C++23) :

for (auto i = 0z; i < arr.size(); i++)

There is no good way in C++ to get a type based on the limits of a "for"
expression. This is possible, but rather ugly:

for (decltype(arr.size()) i = 0; i < arr.size(); i++)

But for such common cases, C++11 added a neat and convenient syntax:

for (auto& a : arr)

That is, presumably, what C++ programmers are taught now.

On 18/06/2021 08:30, Thomas Koenig wrote:
> Ivan Godard <ivan@millcomputing.com> schrieb:
>
>> The warnings are necessary, but still annoying:
>> for (int i = 0; i < arr.size(); i++)
>
> Why chose arr.size() as unsigned?
>
> As long as the types are long enough that overflow is not
> an issue (as should be the case with 64-bit types), signed
> has far nicer properties.
>

arr.size() is of type size_t - it is an unsigned type. If C++ (since
this is C++ syntax, not common C syntax) had been invented now, in the
world of 64-bit machines, then perhaps size_t would have been signed.
But its roots go back to systems where you had 16-bit addresses and
memories that span the entire address space - an unsigned type for the
size of objects was not only logical but necessary.

I disagree somewhat on saying "signed has far nicer properties", just as
I disagree with people who say "unsigned" are "safer" or better defined.
The way they are defined in C and C++, they have somewhat /different/
properties, each of which can be useful in some circumstances.