Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!ubc-cs!uw-beaver!milton!dali.cs.montana.edu!uakari.primate.wisc.edu!crdgw1!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Add-with-carry operator
Message-ID: <70676@microsoft.UUCP>
Date: 14 Feb 91 18:45:26 GMT
References: <1991Feb3.202530.14874@julius.cs.uiuc.edu> <3189@ux.acs.umn.edu> <1991Feb6.210332.12826@julius.cs.uiuc.edu>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 45

In article <1991Feb6.210332.12826@julius.cs.uiuc.edu> zweig@cs.uiuc.edu writes:

|	WHY SHOULD I HAVE TO WRITE CODE THAT PERFORMS OPERATIONS THAT ARE
|	UNNECESSARY ON EVERY MICROPROCESSOR PRODUCED WITHIN THE LAST 10
|	YEARS?
|
|I know the trick of holding the carry bits somewhere else (my code does 16-bit
|2's complement adds in 32-bit words and uses the high order bits to hang on to
|the carry bits).  I see Peter's solution, though it involves comparisons that
|will also add to my instruction-count.  My officemate reminded me that G++ can
|do an inline asm() in a library which expands to add-with-carry (though since
|the language makes no guarantees about keeping the carry bit in your context,
|it isn't clear that even this will always produce correct code).

Please read my example again.  I wrote my example on a machine with
only 16 bit arithmetic.  Therefore, to support 32-bit longs, my
compiler has to be smart enough to generate code that uses the carry
identically the same as if one were writing in assembly.  Further,
since people often perform mixed size arithmetic, the compiler is
smart enough to optimize-out instructions where it knows it would
be adding zero.  So code gets generated to make the best use of
the carry bit possible, and does so without adding more low level 
hacks to the language.

Now you'll probably say: "But, I have a 32-bit machine, not a 16-bit
machine."  Fine.  Many compiler developers are beginning to recognize
that ideas that work well on 16-bit machines also have application
to 32-bit machines.  Therefore these compiler vendors are beginning
to offer built-in compiler support for "software" "long long" 64-bit types.
Once you have a compiler that supports 64-bit "long longs" you
will get code generation using the carry bits the same as if you 
did it by hand.

In summary, given that one has an optimizing compiler with built-in "software"
arithmetic support for words 2X the native word size of the underlying
machine, one can easily write code that automatically makes correct/optimal
use of the carry bit.  It is not necessary to add another hack to the
language.  Rather, compiler vendors should be providing optimized code
generation support to 2X the word size of their underlying machine.
Given such support, programmers can write classes that extrapolate to
NX the word size of the underlying machine, and proper use of the
carry bit will be used though-out.

Instead of adding more hacks, vendors should be worrying about what is
necessary for better automatic code optimization.