From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,54889de51045a215
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-10-01 07:06:17 PST
Path: archiver1.google.com!postnews1.google.com!not-for-mail
From: gautier_niouzes@hotmail.com (Gautier)
Newsgroups: comp.lang.ada
Subject: Re: += in ada
Date: 1 Oct 2003 07:06:17 -0700
Organization: http://groups.google.com
Message-ID: <17cd177c.0310010606.52da88f3@posting.google.com>
References: <3F7316F7.219F@mail.ru>
NNTP-Posting-Host: 213.173.163.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1065017177 26744 127.0.0.1 (1 Oct 2003 14:06:17
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Wed, 1 Oct 2003 14:06:17 +0000 (UTC)
Xref: archiver1.google.com comp.lang.ada:70
Date: 2003-10-01T07:06:17-07:00
List-Id: <comp.lang.ada>

# > If the compiler can really do all that, then fine. But how many really
# > can? Can gnat do that, for example? Or is this just one of those
# > "maybe someday in the distant future," "pie in the sky" things?
# 
# If it's not done for integers as second(after constant precalc),
# it's really strange.GNAT may not have it because of C.
# 
# Let's translate a:=a+b  to
# 
# mov eax,b
# add a,eax
# //optional checks:
# jno @@noexcept
# sub a,eax
#  ---raise exception
# @@noexcept:

Dmytry, Russ: you are just speculating. GNAT (at least) *does*
simplify a:= a+b into an intrinsic "Inc(a,b)", even with a complicated
variable access instead of "a". This since (at least) the
GNAT 3.10p of 1997 !... Here is a reply (to me, who was also wrong!)
from Samuel Tardieu on the same topic a few years ago:

"
Where did you get the impression that the optimizer would miss this? 
 For example, using GNAT, the following expression generates: (ix86 code) 
                           
 t__pXb: movl t__jXb,%edx                             |
         decl %edx                                    |
         movl t__iXb,%eax                             |
         decl %eax                                    |
         leal (%eax,%eax,4),%eax                      |
         sall $3,%eax                                 |
         leal (%eax,%edx,4),%edx                      |
         movl t__gXb,%ecx                             |
         decl %ecx                                    | Address computation
         movl t__fXb,%eax                             |
         decl %eax                                    |
         leal (%eax,%eax,4),%eax                      |
         sall $3,%eax                                 |
         movl t__eXb(%eax,%ecx,4),%eax                |
         addl t__dXb,%eax                             |
         imull $400,%eax,%eax                         |
         leal -400(%edx,%eax),%eax                    |
         imull $4000,t__cXb,%edx                      |
         movl t__bXb-4000(%eax,%edx),%eax             |
         decl %eax                                    |
         incl t__aXb(,%eax,4)            <--- Increment done here!
         ret
                           
 The code used to generate this was: (-O3 -fomit-frame-pointer -gnatp) 
                           
 package T is
   pragma Elaborate_Body;
 end T;
                           
 package body T is
   pragma Warnings (Off); -- Uninitialized variables
                           
   type Two_Ints is array (Integer range <>, Integer range <>) of Integer; 
                           
   type Rec is record
     H : Two_Ints (1 .. 10, 1 .. 10);
   end record;
                           
   type Two_Recs is array (Integer range <>, Integer range <>) of Rec; 
                           
   A : array (1 .. 10) of Integer;
   B : Two_Recs (1 .. 10, 1 .. 10);
   C : Integer;
   D : Integer;
   E : Two_Ints (1 .. 10, 1 .. 10);
   F : Integer;
   G : Integer;
   I : Integer;
   J : Integer;
                           
   procedure P is
     begin
       a(b(c,d+e(f,g)).h(i,j)) :=  a(b(c,d+e(f,g)).h(i,j)) + 1;
     end P;
                           
 end T;
"

The issue is then not an optimization problem, but an
readbility & verifiability one. An Inc(a,b) guaranteed
with pragma Intrinsic by the next Standard would be just fine.
________________________________________________________
Gautier  --  http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!