Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!wuarchive!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!shelby!msi.umn.edu!cs.umn.edu!ux.acs!vx.acs.umn.edu!dhoyt
From: dhoyt@vx.acs.umn.edu (DAVID HOYT)
Newsgroups: comp.lang.c++
Subject: Re: Add-with-carry operator (and a soap box).
Message-ID: <3230@ux.acs.umn.edu>
Date: 7 Feb 91 16:48:55 GMT
References: <1991Feb3.202530.14874@julius.cs.uiuc.edu> <3189@ux.acs.umn.edu> <1991Feb6.210332.12826@julius.cs.uiuc.edu>
Sender: news@ux.acs.umn.edu
Reply-To: dhoyt@vx.acs.umn.edu
Organization: University of Minnesota, Academic Computing Services
Lines: 66
News-Software: VAX/VMS VNEWS 1.3-4

In article <1991Feb6.210332.12826@julius.cs.uiuc.edu>, zweig@cs.uiuc.edu (Johnny Zweig) writes...
>While I appreciate that it's doable (and I appreciate David's comment that
>this problem was solved "a looooonnnnnngggg time ago") I _still_ don't think
>this addresses my basic point:

  Sorry,  that came off a bit more snotty than I really meant.  Really,
what I should have said was that you wouldn't find in in any recently
published book.

> 
>	WHY SHOULD I HAVE TO WRITE CODE THAT PERFORMS OPERATIONS THAT ARE
>	UNNECESSARY ON EVERY MICROPROCESSOR PRODUCED WITHIN THE LAST 10
>	YEARS?
  My response was a bit of a knee jerk, I must admit.  My feeling, which
is mine, is that this is really an optimization problem for a specific
implementation.  (Nice to have an optimiser that would cover that one, aye?)
But the problem is even worse than a simple optimization problem.  To put
features into a language that maps to an efficient use of some particular
machine feature is very dangerous.  How many bugs have been found, and are
still left to be found, in code written by programmers assumed that

    *pp++ = *qp++;

was an atomic operation? 

>                                                                      But
>given the closeness of the virtual machine model C++ has with that of most
>major microprocessor vendors (in terms of 8-,16-,32-bit words, indirect
>addressing, and that sort of thing) it has always bugged me (pun intended)
>that there is not a machine-independent way of talking about carry bits (and,
>for that matter, sign and overflow bits) within the language.

Soapbox time.

  Shreek!  As someone who works with Crays (64 bit words, 24, 32, 48, or 64
bits which are significant in integer operations) if you ever give me
code that assumes that you have a 32 bit processor, indirect addressing,
sizeof( struct { char a[4]; } ) == 4 or anything else like that, I'll really
scream.  32 bit processors are reaching advanced middle age.  In ten years
the sparc 2, mips 3000, et al. will be considered as quaint as the 8088
is now.

  I understand what you are saying, but in real terms I must say that
addition-with-carry bignum math isn't very important.  In any optimization
effort, one should always design the code first using algorithms of the
proper complexity (O(n log n) rather than O(n^2)), then measure the actual
application, if the performance is not acceptable, then identify the areas
that consume the greatest amount of resources, then an only then look for
ways to tweak the code to run faster.  Hand coding of assembler is one of
the tools at your disposal, but it is seldom needed.  In real world terms,
the original design is far more important than how many instruction cycles
that it will take to execute any small segment of code.

  All of this is the realm of software engineering, not in the design of a
new language.  Take a gander at Bliss some time.  It has all of these great
optimization features of the language, pretty much the same kind of features
that you are asking for in C++.  Now look at the $10-$15 billion dollar
company called Digital which is in danger of missing the boat completely
because it is taking them five or more years to convert VMS from Bliss to C
(or whatever their converting it into).

   In the long run, I am much more interested in adding things like private
and public as modifiers to extern and static than adding what seems to be
strictly an optimization issue for particular implementations of C++.

david | dhoyt@vx.acs.umn.edu            An opinion?  I work for a bureaucracy!