From: contr23@NOSC-TECR ("CONTR23")
Subject: Compiler Optimization Question
Date: Fri, 4-Apr-86 14:07:00 EST [thread overview]
Date: Fri Apr 4 14:07:00 1986
Message-ID: <8604042049.AA12638@ucbvax.berkeley.edu> (raw)
Recently I decided to examine what the DEC Ada compiler does to expressions
that can be evaluated at compile time in a loop. The compiler defaults
to optimize and DEC provides a compiler switch that generates machine
code for the listing. Below you will find four programs that vary in only
two ways :
1.) In the loop an expression is either a direct assignment of
a constant that is out of range or the expression performs an
addition operation that makes the assignment out of range.
2.) The first two program versions contain exception handlers and
the later two do not.
Examination of the first program(ADA_OPT_AWAY_VERSION_ONE) shows that the
expression at line 13 has been replaced by exception error that the compiler
has inserted(this was determined by looking at the machine code generated
by the compiler). The output generated by the program at run-time is listed
below:
STILL IN THE LOOP
NUMERIC_ERROR
The second program(ADA_OPT_AWAY_VERSION_TWO) shows that line 13 has been
represented in the code. Upon execution of the code the run-time system
traps the error. The output generated by the program at run-time
is listed below:
STILL IN THE LOOP
NUMERIC_ERROR
I used the above experiments to determine how the compiler would handle the two
loop expressions. Going just one step further, I decided to remove the
exception handler in program three(ADA_OPT_AWAY_VERSION_THREE). The code was
similar to that in the first program less the exception handler. The results
at run-time are shown below:
Output from execution of ADA_OPT_AWAY_VERSION_THREE
----------------------
STILL IN THE LOOP
%ADA-F-NUMERIC_ERROR, NUMERIC_ERROR
-ADA-I-EXCRAIPRI, Exception raised prior to PC = 0000092D
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC
0001082F 0001082F
ADA_OPT_AWAY_VE ADA_OPT_AWAY_VERSION_THREE 13 00000040 0000092D
ADA$ELAB_ADA_OP ADA$ELAB_ADA_OPT_AWAY_VERSION_T 00000009 00000809
00000989 00000989
0000CA33 0000CA33
ADA$ELAB_ADA_OP ADA$ELAB_ADA_OPT_AWAY_VERSION_T 0000001B 0000081B
00000964 00000964
The OS system trapped the error and VMS aborted the process.
Performing the same modification to program four(ADA_OPT_AWAY_VERSION_FOUR),
the results at run-time were quite interesting:
STILL IN THE LOOP
STILL IN THE LOOP
STILL IN THE LOOP
STILL IN THE LOOP
STILL IN THE LOOP
STILL IN THE LOOP
STILL IN THE LOOP
STILL IN THE LOOP
STILL IN THE LOOP
STILL IN THE LOOP
For some unknown reason, the code excuted without error. Examination of the
machine code, shows that the assignment was optimized away by the compiler.
I would be interested in getting some feedback from people on the net
concerning the examples listed below.
----------------------------
Jim Baldo
CONTR23@NOSC-TECR
----------------------------
ADA_OPT_AWAY_VERSION_ONE 3-Apr-1986 09:28:56 VAX Ada V1.2-15 Page 1
01 3-Apr-1986 09:22:55 ADA_OPT_AWAY_VERSION_ONE.ADA;1 (1)
1 with TEXT_IO;
2
3 procedure ADA_OPT_AWAY_VERSION_ONE is
4
5 subtype INTEGER_THIRTYTWO_BITS is INTEGER; -- DEC Standard for Integer
6 type SOME_RANGE is new INTEGER range 1..10;
7
8 OPT_AWAY_VAR : INTEGER_THIRTYTWO_BITS := 0;
9
10 begin -- ADA_OPT_AWAY_VERSION_ONE
11 for LOOP_RANGE in SOME_RANGE loop
12 TEXT_IO.PUT_LINE("STILL IN THE LOOP"); -- should print at least one
13 OPT_AWAY_VAR := 2_147_483_648; -- (2**31) cause overflow
14 end loop;
15 exception
16 when NUMERIC_ERROR =>
17 TEXT_IO.PUT_LINE("NUMERIC_ERROR");
18 end ADA_OPT_AWAY_VERSION_ONE;
ADA_OPT_AWAY_VERSION_TWO 3-Apr-1986 12:47:24 VAX Ada V1.2-15 Page 1
01 3-Apr-1986 09:23:51 ADA_OPT_AWAY_VERSION_TWO.ADA;1 (1)
1 with TEXT_IO;
2
3 procedure ADA_OPT_AWAY_VERSION_TWO is
4
5 subtype INTEGER_THIRTYTWO_BITS is INTEGER; -- DEC Standard for Integer
6 type SOME_RANGE is new INTEGER range 1..10;
7
8 OPT_AWAY_VAR : INTEGER_THIRTYTWO_BITS := 0;
9
10 begin -- ADA_OPT_AWAY_VERSION_TWO
11 for LOOP_RANGE in SOME_RANGE loop
12 TEXT_IO.PUT_LINE("STILL IN THE LOOP"); -- should print at least one
13 OPT_AWAY_VAR := 2_147_483_647 + 1; -- (2**31) cause overflow
14 end loop;
15 exception
16 when NUMERIC_ERROR =>
17 TEXT_IO.PUT_LINE("NUMERIC_ERROR");
18 end ADA_OPT_AWAY_VERSION_TWO;
ADA_OPT_AWAY_VERSION_THREE 3-Apr-1986 12:47:47 VAX Ada V1.2-15 Page 1
01 3-Apr-1986 09:24:51 ADA_OPT_AWAY_VERSION_THREE.ADA;1 (1)
1 with TEXT_IO;
2
3 procedure ADA_OPT_AWAY_VERSION_THREE is
4
5 subtype INTEGER_THIRTYTWO_BITS is INTEGER; -- DEC Standard for Integer
6 type SOME_RANGE is new INTEGER range 1..10;
7
8 OPT_AWAY_VAR : INTEGER_THIRTYTWO_BITS := 0;
9
10 begin -- ADA_OPT_AWAY_VERSION_THREE
11 for LOOP_RANGE in SOME_RANGE loop
12 TEXT_IO.PUT_LINE("STILL IN THE LOOP"); -- should print at least one
13 OPT_AWAY_VAR := 2_147_483_648; -- (2**31) cause overflow
14 end loop;
15 end ADA_OPT_AWAY_VERSION_THREE;
ADA_OPT_AWAY_VERSION_FOUR 3-Apr-1986 12:48:02 VAX Ada V1.2-15 Page 1
01 3-Apr-1986 09:26:00 ADA_OPT_AWAY_VERSION_FOUR.ADA;1 (1)
1 with TEXT_IO;
2
3 procedure ADA_OPT_AWAY_VERSION_FOUR is
4
5 subtype INTEGER_THIRTYTWO_BITS is INTEGER; -- DEC Standard for Integer
6 type SOME_RANGE is new INTEGER range 1..10;
7
8 OPT_AWAY_VAR : INTEGER_THIRTYTWO_BITS := 0;
9
10 begin -- ADA_OPT_AWAY_VERSION_FOUR
11 for LOOP_RANGE in SOME_RANGE loop
12 TEXT_IO.PUT_LINE("STILL IN THE LOOP"); -- should print at least one
13 OPT_AWAY_VAR := 2_147_483_647 + 1; -- (2**31) cause overflow
14 end loop;
15 end ADA_OPT_AWAY_VERSION_FOUR;
------
reply other threads:[~1986-04-04 19:07 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox