Crosspost: Help wanted from comp.compilers

Crosspost: Help wanted from comp.compilers

[John R. Strohm]

Microsoft has this NEW IDEA.  They're going to build a Program Database to
store all kinds of intermediate data about the programs being compiled,
linked, etc., and their tools will all work from that database.

Sounds sort of like the database at the center of a Stoneman APSE to me.
That idea dates back to, what, the late 1970s?

------------------------------------------------------------------------

Subject: RE: Microsoft - Compiler Opportunities
Date: Mon, 30 Jun 2003 15:11:48 -0700

Software Design Engineer - New Product

Microsoft has recently started an exciting compiler and tools project
which will produce all its future code generators, JIT compilers,
optimizers, and program analysis tools. The tools suite will include
tools ranging from profilers to sophisticated defect analysis tools.
Producing optimized, robust software requires advanced, integrated
tools that are built from a common infrastructure that is capable of
analyzing and processing program related information at different
stages in the development process. This information, whether it is
source code, intermediate representation, metadata, profile
information, browser data, binaries, etc has historically been
scattered about in a typical build environment. We're looking to build
a common Program Database where all of this data can be stored and
retrieved efficiently and uniformly thru an API by various interested
parties. These would include compilers, dynamic & static analysis
tools, debuggers, source browsers, QA tools, and so on. We are looking
for a person with a background in programming environments/databases/
compilers/tools to help design and implement this central Program
Database. You would be working with a team of experienced compiler and
tools writers tasked with producing the core of Microsoft's next
generation programming environment. The PDB and the API's you design
will be used in products throughout Microsoft as well as future 3rd
party tool vendors. The ideal candidate would have an MS/CS+ and 4+
years of experience building program databases, analysis tools (and
their stores) and a strong passion for programming environments in
general.

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

John R. Strohm wrote:
> Sounds sort of like the database at the center of a Stoneman APSE to me.
> That idea dates back to, what, the late 1970s?

The idea may date back, but as I recall, the implementations were
horrible, leading to frequent unnecessary "recompile the world"
scenarios. I am guessing that Microsoft will do a much better job.

Re: Crosspost: Help wanted from comp.compilers

[Larry Kilgallen]

In article <1058275843.720814@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> John R. Strohm wrote:
>> Sounds sort of like the database at the center of a Stoneman APSE to me.
>> That idea dates back to, what, the late 1970s?
> 
> The idea may date back, but as I recall, the implementations were
> horrible, leading to frequent unnecessary "recompile the world"
> scenarios. I am guessing that Microsoft will do a much better job.

Have they licensed the DEC patent on "smart recompilation" ?

Re: Crosspost: Help wanted from comp.compilers

[John R. Strohm]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1058275843.720814@master.nyc.kbcfp.com...
> John R. Strohm wrote:
> > Sounds sort of like the database at the center of a Stoneman APSE to me.
> > That idea dates back to, what, the late 1970s?
>
> The idea may date back, but as I recall, the implementations were
> horrible, leading to frequent unnecessary "recompile the world"
> scenarios. I am guessing that Microsoft will do a much better job.

Hyman, as I recall, you admitted not so long ago that you had no real
experience with Ada, which strongly implies that you have no real experience
with any real Ada toolset.

This being the case, your recollection that "the implementations were
horrible" would have to your recollection of something someone told you.
Given your known, and frequently-stated, antipathy towards Ada, I would tend
to believe that your recollection might be faulty, and/or you may be
remembering something told to you by someone who might have had an agenda
that, to put it charitably, would not predispose him towards intellectual
honesty in a matter relating to Ada.

As it happens, I used the Telesoft MC680x0 and Tartan 320C30/C40 Ada
toolsets.  Neither were overly prone to unnecessary recompilation, *IF* you
understood the recompilation rules and the rationale behind them.

Now, it was EASY to build systems that had horrendous recompilation
problems.  Usually, in order to build such a system, you had to screw up
some fairly basic software engineering things.  For example, if you build a
system-wide "types" package, then every time you touch that package, you get
to recompile the world.  If you build a system-wide "magic numbers" package,
same problem.  Observe that the exact same problems arise in C/C++.  The
answer is, of course, DON'T DO THAT.

Re: Crosspost: Help wanted from comp.compilers

[Christopher Browne]

Hyman Rosen <hyrosen@mail.com> writes:
> John R. Strohm wrote:
>> Sounds sort of like the database at the center of a Stoneman APSE to me.
>> That idea dates back to, what, the late 1970s?

> The idea may date back, but as I recall, the implementations were
> horrible, leading to frequent unnecessary "recompile the world"
> scenarios. I am guessing that Microsoft will do a much better job.

What with the stunning jobs they have done on everything else, why on
earth would you guess that?
-- 
select 'cbbrowne' || '@' || 'cbbrowne.com';
http://www3.sympatico.ca/cbbrowne/linuxxian.html
"Ah,  the 20th century, when the  flight from reason crash-landed into
the slaughterhouse."  --- James Ostrowski

Re: Crosspost: Help wanted from comp.compilers

[Robert I. Eachus]

John R. Strohm wrote:

> Now, it was EASY to build systems that had horrendous recompilation
> problems.  Usually, in order to build such a system, you had to screw up
> some fairly basic software engineering things.  For example, if you build a
> system-wide "types" package, then every time you touch that package, you get
> to recompile the world.  If you build a system-wide "magic numbers" package,
> same problem.  Observe that the exact same problems arise in C/C++.  The
> answer is, of course, DON'T DO THAT.

This resulted in one of the few "official" MITRE inputs to the Ada 9X 
requirements process, and the one that meant we felt it was important to 
submit as a MITRE position not just representing the group making the 
recomendations.  Every time MITRE got called in by the government to 
resolve Ada compiler problems that were ususally described as 
"recompiles with this compiler are much too slow," it turned out that 
the real solution was to fix some software engineering issues. (John 
Strohm gave a good selection of some of them.  Another favorite was 
rapidly changing interfaces during the coding phase.  In one case, I 
found a package specification that had changed 17 times in one month. 
During that time, the package body had been changed twice!)

Of course, given the usual contracting environment, the sooner MITRE got 
called in to resolve the problem, the more money (and schedule time 
which was often more valuable) the government saved.  So even if someone 
did figure out an elegant way to recompile the world quickly, we (on 
behalf of the US government) did not want it.

Oh and of course, not all government programs are written in Ada.  For 
programs in C, this problem usually showed up as a configuration 
management problem when trying to link all the code together.  On at 
least one project where I was on the "Red Team" to resolve that, the 
recommendation was to cancel the project.  (They had fallen into the 
trap of having more than one version of the truth by having different 
software repositories for different software groups on a large project. 
  When they finally tried to do an "all up" system build, it turned out 
that there were over 1000 files with multiple versions.  After studying 
a significant sample of the differences, we estimated the time to merge 
the differences with some chance of getting a working version at over 
two years!)

-- 

                                                Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Crosspost: Help wanted from comp.compilers

[Jeffrey Carter]

John R. Strohm wrote:
> 
> Now, it was EASY to build systems that had horrendous recompilation
> problems.  Usually, in order to build such a system, you had to screw up
> some fairly basic software engineering things.  For example, if you build a
> system-wide "types" package, then every time you touch that package, you get
> to recompile the world.  If you build a system-wide "magic numbers" package,
> same problem.  Observe that the exact same problems arise in C/C++.  The
> answer is, of course, DON'T DO THAT.

These are fairly benign problems. I know of at least one current DoD 
project that has a system-wide "variables" package. This software is 
flying in a state-of-the-art military aircraft. Not only do most 
upgrades involve modifying this package, and hence recompiling the 
entire system, but the system is 100% coupled with 0% cohesion. 
Understanding the system from scratch is at least as expensive as 
redesigning and rewriting the entire system; that's the choice they will 
face if the couple of developers, who have been there from the beginning 
and have the entire system in their heads, ever quit or are killed going 
out to lunch together.

-- 
Jeff Carter
"I spun around, and there I was, face to face with a
six-year-old kid. Well, I just threw my guns down and
walked away. Little bastard shot me in the ass."
Blazing Saddles

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

John R. Strohm wrote:
 > your recollection might be faulty

Here's some evidence. I have no idea about its quality.
Given the unfortunate lack of a worldwide web in the 80s,
it's not clear where to search for more data. Looking at
some of the links below, I think a big problem was that
many of the systems forced all dependents of a file to be
recompiled when the file was recompiled, regardless of
whether the source had changed. I believe this was one
reason that GNAT decided to go with a source-based model
for its library.

<http://www.ics.uci.edu/~softtest/adamakegen.html>
     "In our development of large Ada systems, we have found
      several problems with use the partial recompilation tool
      supplied by Verdix/SunAda. They are:

         * The dependencies are often incorrect,
           leading to corruption of the Ada libraries.
         * It does not support libraries that form a loop."

<http://www.seas.gwu.edu/~adagroup/sigada-website/barnes-html/chap1.html>
     "A common consequence of the flat structure was that packages
      become large and monolithic. This hindered understanding and
      increased the cost of recompilation."

<http://archive.adaic.com/docs/flyers/95fast.html>
     "Say good-bye to the days of multiple-day recompilation of
      Ada 83 software."

<http://compilers.iecc.com/comparch/article/93-09-039>
     "Compiling one of the earlier units again, perhaps because of a
      change to the source, or a desire to change the optimisation level
      or amount of debugging support, causes this method of implementing
      the check to fail. In order to link the application, all the
      'obsolete' compilation units are going to have to be recompiled.
      This step may take a considerable amount of elapsed time - minutes,
      hours, even days in large applications."

<http://ftp1.support.compaq.com/public/Readmes/vms/adavaxeco13030.README>
     " o  Smart recompilation allocates an object the wrong PSECT
          resulting in an ACCVIO at run-time, or non-zero values in the
          ZERO PSECT.

       o  Smart recompilation associated compiler ACCVIO when processing
          use clauses.

       o  Smart recompilation associated compiler ACCVIO in SS_BASE_TYPE
          during hint processing."

<http://sage.inel.gov/uman_sagestmeridianport.htm>
     "In order to debug any package both the spec and body must be
      recompiled with the fD flag. Recompiling the spec then causes
      any packages 'with'ing this one to be recompiled. Depending
      on the need this can cause a massive recompilation."

Re: Crosspost: Help wanted from comp.compilers

[John R. Strohm]

"Jeffrey Carter" <spam@spam.com> wrote in message
news:3F14B061.1040802@spam.com...
> John R. Strohm wrote:
> >
> > Now, it was EASY to build systems that had horrendous recompilation
> > problems.  Usually, in order to build such a system, you had to screw up
> > some fairly basic software engineering things.  For example, if you
build a
> > system-wide "types" package, then every time you touch that package, you
get
> > to recompile the world.  If you build a system-wide "magic numbers"
package,
> > same problem.  Observe that the exact same problems arise in C/C++.  The
> > answer is, of course, DON'T DO THAT.
>
> These are fairly benign problems. I know of at least one current DoD
> project that has a system-wide "variables" package. This software is
> flying in a state-of-the-art military aircraft. Not only do most
> upgrades involve modifying this package, and hence recompiling the
> entire system, but the system is 100% coupled with 0% cohesion.
> Understanding the system from scratch is at least as expensive as
> redesigning and rewriting the entire system; that's the choice they will
> face if the couple of developers, who have been there from the beginning
> and have the entire system in their heads, ever quit or are killed going
> out to lunch together.

I am not at all surprised to hear this.

Sometimes you run into that kind of overcoupling and undercohesion because
of timeline/fairness concerns.  The system designer has to guarantee that
every task DOES get his assigned timeslice, every time, or things can go to
hell in a handcart in a hell of a hurry.  You want a horrible example?
Calculate a dive toss delivery, and see just how small your release time
window really is.  And EVERYTHING has to run, in the right order, to
calculate the delivery and decide when to tell the latches to let go of the
bomb.  And then the actual release message has to get out to the latches on
the rack...

I am curious, though.  Can you say what project it is?

Re: Crosspost: Help wanted from comp.compilers

[Robert I. Eachus]

Hyman Rosen wrote:

> Here's some evidence. I have no idea about its quality.
> Given the unfortunate lack of a worldwide web in the 80s,
> it's not clear where to search for more data. Looking at
> some of the links below, I think a big problem was that
> many of the systems forced all dependents of a file to be
> recompiled when the file was recompiled, regardless of
> whether the source had changed.

If you understood Ada, you would understand that all of the "evidence" 
you supplied confirmes what we have said.  The issue going into the Ada 
9X process was that tools that tried to short-cut the Ada recompilation 
rules were tried--and they were much worse than the problem.

>                                   I believe this was one
> reason that GNAT decided to go with a source-based model
> for its library.

Hoo, boy.  That is good.  Do you really understand how the GNAT "source 
based" model works?  Everytime you compile a unit the specification for 
  every package/unit withed by that unit is recompiled.  Every time you 
modify a subunit the library unit, or a library unit with subunits, the 
library unit and all of its subunits needs to be recompiled.  In other 
words, the GNAT model does lots more recompilation, not less.  The 
benefit is that the overhead of compiling specifications is kept very 
low, so the recompilation from source is faster than saving an 
intermediate state and restoring it.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Crosspost: Help wanted from comp.compilers

[Larry Kilgallen]

In article <3F158832.1040206@attbi.com>, "Robert I. Eachus" <rieachus@attbi.com> writes:
> Hyman Rosen wrote:
> 
>> Here's some evidence. I have no idea about its quality.
>> Given the unfortunate lack of a worldwide web in the 80s,
>> it's not clear where to search for more data. Looking at
>> some of the links below, I think a big problem was that
>> many of the systems forced all dependents of a file to be
>> recompiled when the file was recompiled, regardless of
>> whether the source had changed.
> 
> If you understood Ada, you would understand that all of the "evidence" 
> you supplied confirmes what we have said.  The issue going into the Ada 
> 9X process was that tools that tried to short-cut the Ada recompilation 
> rules were tried--and they were much worse than the problem.

VAX/DEC/Compaq Ada with "smart recompilation" works quite well for me.
Or is there some other sort of approach you can describe.

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

Robert I. Eachus wrote:
> If you understood Ada, you would understand that all of the "evidence" 
> you supplied confirmes what we have said.  The issue going into the Ada 
> 9X process was that tools that tried to short-cut the Ada recompilation 
> rules were tried--and they were much worse than the problem.

If you go back to my original post, you'll see that I wrote
     the implementations were horrible, leading to frequent
     unnecessary "recompile the world" scenarios

How is that different from what you just said? Are you
disagreeing with me that this was the case?

 > Do you really understand how the GNAT "source based" model works?

Yes, in fact I do.

> Everytime...

As some of my evidence pointed out, the compilation systems which
caused problems appeared to use compilation timestamps in their
dependency checking, such that simply compiling a file caused the
system to consider it to be newer than its dependents, and thus led
to their recompilation in a days-long cascade. I don't know why
they did it that way, but it certainly seems clear that they did.
Certainly Ada doesn't require that this happen, which is why I
spoke about horrible implementations, not horrible Ada.

GNAT's way means that a file is recompiled only when the source
modules it depends on change.

Re: Crosspost: Help wanted from comp.compilers

[John R. Strohm]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1058378673.35463@master.nyc.kbcfp.com...
> Robert I. Eachus wrote:
> > If you understood Ada, you would understand that all of the "evidence"
> > you supplied confirmes what we have said.  The issue going into the Ada
> > 9X process was that tools that tried to short-cut the Ada recompilation
> > rules were tried--and they were much worse than the problem.
>
> If you go back to my original post, you'll see that I wrote
>      the implementations were horrible, leading to frequent
>      unnecessary "recompile the world" scenarios
>
> How is that different from what you just said? Are you
> disagreeing with me that this was the case?

No, what he pointed out was that MOST of the problem that MANIFESTED as long
recompile cycles was CAUSED by poor software engineering practices.  Tools
were tried to shortcut the recompile cycles CAUSED by the underlying
software engineering problems, and those tools turned out to be far worse in
practice than it would have been to FIX THE REAL PROBLEM.

>  > Do you really understand how the GNAT "source based" model works?
>
> Yes, in fact I do.
>
> > Everytime...
>
> As some of my evidence pointed out, the compilation systems which
> caused problems appeared to use compilation timestamps in their
> dependency checking, such that simply compiling a file caused the
> system to consider it to be newer than its dependents, and thus led
> to their recompilation in a days-long cascade. I don't know why
> they did it that way, but it certainly seems clear that they did.
> Certainly Ada doesn't require that this happen, which is why I
> spoke about horrible implementations, not horrible Ada.
>
> GNAT's way means that a file is recompiled only when the source
> modules it depends on change.

Same thing.  Exactly.

Consider a package spec, that declares a procedure.  Change the procedure
spec, say, adding another parameter, and recompile.  EVERYONE WHO CALLS THAT
PROCEDURE is now by definition obsolete: their procedure calls are all
broken.  Those calls MUST be fixed, and those units MUST be recompiled.  IF
THOSE BROKEN CALLERS AREN'T FIXED, BEFORE THE SYSTEM IS LINKED, THE BUILD
WILL BE BROKEN.

Read that sentence again.

IF THOSE BROKEN CALLERS AREN'T FIXED, BEFORE THE SYSTEM IS LINKED, THE BUILD
WILL BE BROKEN.

Now, the C/C++ model is to let the programmer link anyway, and HOPE that the
broken build will be caught in lab testing BEFORE it gets loaded into the
rocket, launched into orbit, and proceeds to render a multimillion-dollar
payload so much space junk.  Or maybe it is a lifesupport system, that just
kills a few people by forgetting to pump oxygen into the breathing loop.

This may be acceptable in the C/C++ community, hey, who cares if you kill a
few grunts or waste a few million dollars, but it was not considered
acceptable in the Department of Defense embedded systems community.
Requiring recompilation is, IN THE PRESENCE OF GOOD SOFTWARE ENGINEERING, a
safety check that isn't going to cost THAT much, compared to the potential
cost of NOT recompiling.

By the way, last time I looked, all the various version of 'make' for C/C++
use compilation timestamps to determine whether something needed to be
rebuilt.  So how is Ada "worse" than C/C++ in this regard?

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

John R. Strohm wrote:
> Consider a package spec, that declares a procedure.  Change the procedure

Did you actually read what I and some of the sites I quoted said?

The broken systems triggered cascading recompiles when a spec was
recompiled *whether or not the spec had changed*. There are several
instances mentioned where people wanted to recompile a module for
extra debugging or optimization, and that in itself triggered the
cascade, even though no source file had changed.

Re: Crosspost: Help wanted from comp.compilers

[Marin David Condic]

John: You're blocking. Tell us how you *really* feel. :-)

Here is a pretty valid point: Compilation time just isn't that big a 
deal these days. Recompiling the world on even a fairly large project 
just doesn't take that long. Not when compared to the overall 
development time. And the engineers almost always have something useful 
to do while waiting for the results of a recompile anyway, so what is 
the worry? Are we going to wear out the processor by making it execute a 
few million unnecessary instructions per second? Do we have to pay it by 
the module? Does it get bored, tired and lazy and want to quit unless 
you give it a pay raise? In my experience, not very often. So buy lots 
of really fast processors and let them have at it. They are enthusiastic 
and will work really hard even if you don't give them an "Atta boy!" 
very often.

In my experience, what seems to take a long time on a major recompile is 
when errors have got into the code and the compile is continually 
aborted mid-run so that some geek can go fix something he should have 
got right the first time, but didn't for any variety of reasons. 
(Mismatches between development and production versions of things are a 
typical culprit.) If it were not for having to stop and fix those 
errors, the compile time itself isn't really a slowdown of operations. 
At worst, you submit a batch job to run overnight and its done in the 
morning. Usually, it is nowhere near that bad - you run the compile and 
go clean up documentation while you wait for the results. Human 
multitasking tends to minimize any real issues about waiting for 
compilation. And even then, with processors and disks running as fast as 
they do, I just don't see that much wait time involved.

In some ways, I prefer to shoot everything in the head and *force* a 
recompilation of everything under the sun. That way, I am absolutely 
sure that what got compiled was the latest and greatest of everything 
and there isn't a snowball's chance in hell that I got some old, out of 
date, object file into the build due to some quirk or defect in the 
software that does the recompile. Its cheap insurance. To that end, 
Ada's insistence on consistency checking - even if poor implementations 
are sometimes overly conservative - is a good thing.

MDC



John R. Strohm wrote:

> Requiring recompilation is, IN THE PRESENCE OF GOOD SOFTWARE ENGINEERING, a
> safety check that isn't going to cost THAT much, compared to the potential
> cost of NOT recompiling.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Crosspost: Help wanted from comp.compilers

[Marin David Condic]

To be fair, changing compiler switches or otherwise doing something that 
might change the object code that is generated, is a reasonable excuse 
to insist on invalidating the dependency chain. Can you really be 
absolutely, positively, 100%, double your money back, certain that if 
you recompile a spec with different compiler options, that this will in 
no way, shape or form impact the way other things might rely on it?

Remember that Ada was originally intended for use by people who's 
marketing slogan was "We bet *your* life on it!" I am not surprised if - 
especially in early implementations - Ada compilers got really 
conservatibe with respect to recompilation. If it were me, I'd start 
with the premise of "Recompile The World" and then look for absolute 
proof that recompiling some specific module was not necessary.

MDC

Hyman Rosen wrote:
> 
> The broken systems triggered cascading recompiles when a spec was
> recompiled *whether or not the spec had changed*. There are several
> instances mentioned where people wanted to recompile a module for
> extra debugging or optimization, and that in itself triggered the
> cascade, even though no source file had changed.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

Marin David Condic wrote:
> Can you really be certain that if you recompile a spec with different
 > compiler options, that this will in no way impact the way other things
 > might rely on it?

Me, no. The compiler maker, yes.

Re: Crosspost: Help wanted from comp.compilers

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1058390613.119827@master.nyc.kbcfp.com...
> The broken systems triggered cascading recompiles when a spec was
> recompiled *whether or not the spec had changed*. There are several
> instances mentioned where people wanted to recompile a module for
> extra debugging or optimization, and that in itself triggered the
> cascade, even though no source file had changed.

What's broken about that? Janus/Ada works that way now, and it certainly
doesn't cause day-long recompiles in practice.

Why not? Because there isn't any reason to recompile a spec that's not
changed! Certainly the make tool doesn't do that. And Ada make tools are
usually a lot easier to use than C ones, because they can discover all of
the dependencies automatically. So there isn't any reason to avoid using the
make tool. If you don't use the make tool, and your compilation gets all
botched, that's your problem. Do you know of anyone that runs GNAT manually
(without using gnatmake)?

I suppose there might have been bugs in the make tools in early
implementations, but that's not what you're saying.

                      Randy.

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

Randy Brukardt wrote:
 > What's broken about that?

Apparently, people needed to recompile some modules for debugging
or optimization, and this triggered cascades which made them unhappy.
Since the source files hadn't changed, they weren't being unreasonable
in their expectations. Ada83 didn't require such behavior. GNAT doesn't
exhibit such behavior.

> I suppose there might have been bugs in the make tools in early
> implementations, but that's not what you're saying.

Huh? That's *exactly* what I'm saying! You're the one who seems to be
saying that it wasn't a bug but a feature. Products which contain such
features soon find themselves replaced.

Re: Crosspost: Help wanted from comp.compilers

[John R. Strohm]

You and I are on the same wavelength.

Some days, it was just easier to recompile everything in the universe, than
try to figure out which pieces had to be recompiled and which didn't, and
then find out I'd missed something.

It does depend, however.  At one company, it took about an hour to rebuild,
even if only a few files had actually changed, because of a whole bunch of
gyrations they'd built into their build process.  If you only had a
four-hour lab slot, and you found out you had to fix something and rebuild,
it got old in a hell of a hurry.  And there WASN'T any kind of hot-patching
capability: you HAD to do a complete build, and trade it out.

"Marin David Condic" <nobody@noplace.com> wrote in message
news:3F15DC68.8090907@noplace.com...
> In some ways, I prefer to shoot everything in the head and *force* a
> recompilation of everything under the sun. That way, I am absolutely
> sure that what got compiled was the latest and greatest of everything
> and there isn't a snowball's chance in hell that I got some old, out of
> date, object file into the build due to some quirk or defect in the
> software that does the recompile. Its cheap insurance. To that end,
> Ada's insistence on consistency checking - even if poor implementations
> are sometimes overly conservative - is a good thing.
>
> MDC
>
>
>
> John R. Strohm wrote:
>
> > Requiring recompilation is, IN THE PRESENCE OF GOOD SOFTWARE
ENGINEERING, a
> > safety check that isn't going to cost THAT much, compared to the
potential
> > cost of NOT recompiling.
> >
>
>
> --
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jast.mil/
>
> Send Replies To: m c o n d i c @ a c m . o r g
>
>      "In general the art of government consists in taking as
>      much money as possible from one class of citizens to give
>      to the other."
>
>          --  Voltaire
> ======================================================================
>

Re: Crosspost: Help wanted from comp.compilers

[John R. Strohm]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1058390613.119827@master.nyc.kbcfp.com...
> John R. Strohm wrote:
> > Consider a package spec, that declares a procedure.  Change the
procedure
>
> Did you actually read what I and some of the sites I quoted said?
>
> The broken systems triggered cascading recompiles when a spec was
> recompiled *whether or not the spec had changed*. There are several
> instances mentioned where people wanted to recompile a module for
> extra debugging or optimization, and that in itself triggered the
> cascade, even though no source file had changed.

Hyman, it occasionally appears to me that you insist on thinking with your
preconceptions rather than your brain.

Consider a C example, first.

magic_value.h:
#ifndef _MAGIC_VALUE
#define _MAGIC_VALUE
#define MAGIC 42
#endif

test_array.c:

#include "magic_value.h"
static int bletch[4] = { MAGIC, MAGIC, 0, MAGIC };
void main(void)
{
  /* do something with bletch[] */
}

Now, Hyman, it should be immediately obvious, even to you, that, if we
change the line that defines the magic value in the .h file, we HAVE to
recompile the .c file as well, even though the .c file has not changed one
iota.

Let's go a step further.

magic_value.h:
#ifndef _MAGIC_VALUE
#define _MAGIC_VALUE
#define MAGIC 42
#endif

magic_square.h:
#ifndef _MAGIC_SQUARE
#define _MAGIC_SQUARE
#include "magic_value.h"
#define MAGICSQUARE ((MAGIC)*(MAGIC))
#endif

test_square.c:
#include "magic_square.h"
static int magic_square[MAGICSQUARE];
void main(void)
{
  for (i=0;i<MAGICSQUARE;i++){
    magic_square[MAGICSQUARE] = i;
  }
}

In this example, Hyman, by your argument, we should be able to change MAGIC
in magic_value.h and NOT have to recompile test_square.c, because the source
code for magic_square.h has not changed.

However, the MEANING, the SEMANTICS, of magic_square.h HAVE changed, because
the semantics UNDERLYING magic_square.h, i.e., the magic value MAGIC, have
changed.

The same thing can occur in Ada.  An overt change in one specification may
propagate through a chain of apparently-unchanged descendants, producing
hidden but very real semantic changes in each of them, and eventually
producing a very visible change in the final descendant.

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

John R. Strohm wrote:
> The same thing can occur in Ada.  An overt change in one specification may
> propagate through a chain of apparently-unchanged descendants, producing
> hidden but very real semantic changes in each of them, and eventually
> producing a very visible change in the final descendant.

You're not listening. The complaint was that some Ada systems recompiled
dependents when a file was compiled, even if the source code had not
changed. You keep telling me that changes can ncessitate recompilation.
I know that. Ada knows that. Ada specifies such dependencies on changes
very carefully.

Re: Crosspost: Help wanted from comp.compilers

[tmoran]

>The complaint was that some Ada systems recompiled dependents when a file
>was compiled, even if the source code had not changed.
  Consider:
-- file testgo1.ads
package testgo1 is
  i : integer := integer'last-1;
  j : integer := i+2;
end testgo1;
-- file testgo2.ads
with testgo1;
package testgo2 is
  k : integer := testgo1.j;
  function f return integer;
end testgo2;
-- file testgo2.adb
package body testgo2 is
  function f return integer is
  begin return 3;end f;
end testgo2;
-- file testgo.adb
with testgo2;
procedure testgo is
  x : integer;
begin
  x := testgo2.f;
end testgo;

If compiled with "gnatmake -gnato testgo"
the line in testgo1.ads
  j : integer := i+2;
results in a constraint error.  If compiled "gnatmake testgo" it doesn't.
  The procedure testgo can be recompiled with and without -gnato and
it doesn't change the behavior compiled into testgo1.ads  But 'touch'
testgo1.ads to update it's file modification date while changing nothing
at all in the source code, and the next time you say "gnatmake testgo"
or "gnatmake -gnato testgo", it will recompile testgo1.ads and generate
code that does (-gnato) or does not (no -gnato) raise a constraint error.
  That's an example of a case where a textually unchanged spec file
needs to be recompiled because of a change in compiler options.  Other
compilers might lay out records differently according to compiler
switches telling them to optimize for space/time.  That would
require cascading recompiles where the only change is to compiler
optimization switches, not to any source files.

Re: Crosspost: Help wanted from comp.compilers

[tmoran]

>Apparently, people needed to recompile some modules for debugging
>or optimization, and this triggered cascades which made them unhappy.
>Since the source files hadn't changed, they weren't being unreasonable
>in their expectations. Ada83 didn't require such behavior.
  I'm reminded of days spent at the "help desk" in grad school.  "You say
the program used to work and now doesn't and you didn't change anything.
Why did you run it a second time if you didn't change anything?"  To which
the answer always was "well, I just made this one little change..."
  Remember that Ada has separate specs and bodies.  If you want to change
the optimization or get additional debug output on the body, you can
recompile the body and it doesn't cause cascades.  If you recompile the
spec with a different optimization level then some things (record layouts,
for instance) might change, and you certainly had better recompile
anything that depends on that spec.  If you made no changes to the source
of a spec and you made no changes to the compiler switches, and you are
using the same identical compiler exe, and you didn't clobber the object
file, then why the heck are you recompiling?

> GNAT doesn't exhibit such behavior.
  I just 'touch'ed a spec file, but made no changes.  I then ran gnatmake
with the same options as previously.  Lo and behold, Gnat recompiled the
spec, the body, and the main program that 'with'ed that spec.  So Gnat
most assuredly does recompile when there might be a change.

  BTW, I recall as one of the nicest things about my first Ada compiler,
Janus (long before Gnat), was that it didn't need a "make" or special
library database.  Just like gnatmake, it looked at the files on disk
and recompiled just what was necessary.

Re: Crosspost: Help wanted from comp.compilers

[Lutz Donnerhacke]

* Hyman Rosen wrote:
> John R. Strohm wrote:
>> The same thing can occur in Ada.  An overt change in one specification may
>> propagate through a chain of apparently-unchanged descendants, producing
>> hidden but very real semantic changes in each of them, and eventually
>> producing a very visible change in the final descendant.
> 
> You're not listening. The complaint was that some Ada systems recompiled
> dependents when a file was compiled, even if the source code had not
> changed. You keep telling me that changes can ncessitate recompilation.
> I know that. Ada knows that. Ada specifies such dependencies on changes
> very carefully.

Yep. I prefer checksums over files to determine recompiling issues.
Especially using the Spark tools urged this method to come to an end before
the day is over.

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

tmoran@acm.org wrote:
>   That's an example of a case where a textually unchanged spec file
> needs to be recompiled because of a change in compiler options.

But GNAT doesn't do it, as you yourself point out!

> Other compilers might lay out records differently according to compiler
> switches telling them to optimize for space/time.  That would
> require cascading recompiles where the only change is to compiler
> optimization switches, not to any source files.

But I would expect that this happens when new options are applied to
the withing program unit, not to the withed one. So you only recompile
the things you ask for.

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

tmoran@acm.org wrote:
 > If you recompile the spec with a different optimization level then
 > some things (record layouts, for instance) might change, and you
 > certainly had better recompile anything that depends on that spec.

I don't see how such fundamental differences are going to coexist in
the same program. What if I then recompile one thing that depends on
this spec with different flags?

> If you made no changes to the source
> of a spec and you made no changes to the compiler switches, and you are
> using the same identical compiler exe, and you didn't clobber the object
> file, then why the heck are you recompiling?

Nervous habit?

>   I just 'touch'ed a spec file, but made no changes.  I then ran gnatmake
> with the same options as previously.  Lo and behold, Gnat recompiled the
> spec, the body, and the main program that 'with'ed that spec.  So Gnat
> most assuredly does recompile when there might be a change.

GNAT is using the source file timestamp as a proxy for its having changed.
In my opinion, that's much more reasonable than using the object file timestamp.

Re: Crosspost: Help wanted from comp.compilers

[tmoran]

>Apparently, people needed to recompile some modules for debugging
>or optimization, and this triggered cascades which made them unhappy.
>Since the source files hadn't changed, they weren't being unreasonable
>in their expectations. Ada83 didn't require such behavior.
  I'm reminded of days spent at the "help desk" in grad school.  "You say
the program used to work and now doesn't and you didn't change anything.
Why did you run it a second time if you didn't change anything?"  To which
the answer always was "well, I just made this one little change..."
  Remember that Ada has separate specs and bodies.  If you want to change
the optimization or get additional debug output on the body, you can
recompile the body and it doesn't cause cascades.  If you recompile the
spec with a different optimization level then some things (record layouts,
for instance) might change, and you certainly had better recompile
anything that depends on that spec.  If you made no changes to the source
of a spec and you made no changes to the compiler switches, and you are
using the same identical compiler exe, and you didn't clobber the object
file, then why the heck are you recompiling?

> GNAT doesn't exhibit such behavior.
  I just 'touch'ed a spec file, but made no changes.  I then ran gnatmake
with the same options as previously.  Lo and behold, Gnat recompiled the
spec, the body, and the main program that 'with'ed that spec.  So Gnat
most assuredly does recompile when there might be a change.

  BTW, I recall as one of the nicest things about my first Ada compiler,
Janus (long before Gnat), was that it didn't need a "make" or special
library database.  Just like gnatmake, it looked at the files on disk
and recompiled just what was necessary.

Re: Crosspost: Help wanted from comp.compilers

[Preben Randhol]

Robert I. Eachus wrote:
> Hoo, boy.  That is good.  Do you really understand how the GNAT "source 
> based" model works?  Everytime you compile a unit the specification for 
> every package/unit withed by that unit is recompiled.  

Perhaps I misunderstand you, but if you make the .ali files read-only
the library won't be recompiled when you with a unit in your program. If
it needs to be due to change of compiler or some other reason the
compiler will stop compiling and tell you it is needed. But I guess you
were refering to something else?

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Crosspost: Help wanted from comp.compilers

[Preben Randhol]

Hyman Rosen wrote:
> You're not listening. The complaint was that some Ada systems recompiled
> dependents when a file was compiled, even if the source code had not
> changed. 

Actually you are not listening. He just showed you why it needed to be
recompiled.

-- 
Ada95 is good for you.
http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php

Re: Crosspost: Help wanted from comp.compilers

[Marin David Condic]

Not always the compiler maker either. I know that the DEC compilers had 
a "feature" wherein they could compile a file on two different occasions 
and get different code, despite there being no change in the file. The 
reason was that the optimizer took advantage of the available working 
set to bring in more code for optimization. Depending on the demand for 
memory, it might get more or less memory on two different passes and 
hence could (and did on at least three occasions I witnessed) produce 
different code for an unchanged file. It was rare, but it was a risk. 
For most people, this wouldn't be a problem, but for safety critical 
embedded systems, it was.

Maybe this example doesn't really apply to specifications, since there 
may not be much/any code generation going on and little/no optimization 
- but it illustrates the difficulties the compiler writers may have in 
knowing the consequences of what may happen in the field.

So, yes, I agree, compilers ought not to force recompilation when it is 
unnecessary. But sometimes it is difficult to know when "unnecessary" is 
  a certainty & I can be forgiving of implementations that try to err on 
the side of caution.

MDC

Hyman Rosen wrote:
> Marin David Condic wrote:
> 
>> Can you really be certain that if you recompile a spec with different
> 
>  > compiler options, that this will in no way impact the way other things
>  > might rely on it?
> 
> Me, no. The compiler maker, yes.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Crosspost: Help wanted from comp.compilers

[Frank J. Lhota]

Look, we're going around in circles here. First of all, I think we all agree
that with some of the early Ada 83 compilers, compiling an specification
would force a recompilation of all dependent units, even if the
specification had not changed since it was last compiled. Certainly the
Alsys ActivAda compilers worked that way. IIRC DEC Ada generally did not
unnecessary recompilations.

Clearly unneeded compile time, or any other form of wasted time, is not
desirable. But the leading Ada 95 compilers, GNAT and ObjectAda, do not
exhibit this behaviour. We're fighting yesterday's battles here.

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

Frank J. Lhota wrote:
 > We're fighting yesterday's battles here.

That's because the OP claimed of Microsoft's program database:
     Sounds sort of like the database at the center of a
     Stoneman APSE to me. That idea dates back to, what,
     the late 1970s?

Re: Crosspost: Help wanted from comp.compilers

[Larry Kilgallen]

In article <u2rRa.80496$Ph3.9622@sccrnsc04>, tmoran@acm.org writes:

>   BTW, I recall as one of the nicest things about my first Ada compiler,
> Janus (long before Gnat), was that it didn't need a "make" or special
> library database.  Just like gnatmake, it looked at the files on disk
> and recompiled just what was necessary.

Just looking at files on disk does not give any history as to whether
a given _declaration_ within a file has changed.  One might end up
recompiling a cascading tree of modules because some entirely unused
(yet) declaration was added to a module.

Re: Crosspost: Help wanted from comp.compilers

[tmoran]

> >   That's an example of a case where a textually unchanged spec file
> > needs to be recompiled because of a change in compiler options.
>
> But GNAT doesn't do it, as you yourself point out!
  Which is a bug in gnatmake, IMHO.

> But I would expect that this happens when new options are applied to
> the withing program unit, not to the withed one. So you only recompile
> the things you ask for.
  In the example I gave, "gnatmake -gnato testgo" *should* see that
the compiler switches are different and thus recompile testgo1.ads,
which should cause a recompile of testgo2, though it had no changes
and was not mentioned on the command line, as well as testgo.

Re: Crosspost: Help wanted from comp.compilers

[tmoran]

> > If you made no changes to the source
> > of a spec and you made no changes to the compiler switches, and you are
> > using the same identical compiler exe, and you didn't clobber the object
> > file, then why the heck are you recompiling?
>
> Nervous habit?
  I understand that psychiatrists *have to* charge a lot because a high
price aids psychologically in the patient's attitude, and thus outcome.
So perhaps a lengthy cascade of recompilations is also necessary to
reassure those whose nervous habit causes them to cause unnecessary
recompilations.  ;)

Re: Crosspost: Help wanted from comp.compilers

[tmoran]

> Just looking at files on disk does not give any history as to whether
> a given _declaration_ within a file has changed.  One might end up
> recompiling a cascading tree of modules because some entirely unused
> (yet) declaration was added to a module.
  If A 'with's B and something new is added to B's spec, how does a
compiler know that the new thing is not used by A, unless it recompiles A?

Re: Crosspost: Help wanted from comp.compilers

[Ed Falis]

On Thu, 17 Jul 2003 18:02:09 GMT
tmoran@acm.org wrote:

> > >   That's an example of a case where a textually unchanged spec
> > >   file
> > > needs to be recompiled because of a change in compiler options.
> >
> > But GNAT doesn't do it, as you yourself point out!
>   Which is a bug in gnatmake, IMHO.

Use the -s switch to gnatmake if you want that behavior.  How can it be
considered a bug when it's not defined behavior in the Ada standard, and
it is in the gnat manuals?

- Ed

Re: Crosspost: Help wanted from comp.compilers

[Larry Kilgallen]

In article <CwBRa.83015$Ph3.10355@sccrnsc04>, tmoran@acm.org writes:
>> Just looking at files on disk does not give any history as to whether
>> a given _declaration_ within a file has changed.  One might end up
>> recompiling a cascading tree of modules because some entirely unused
>> (yet) declaration was added to a module.
>   If A 'with's B and something new is added to B's spec, how does a
> compiler know that the new thing is not used by A, unless it recompiles A?

The compilers in question keep in their database an index of everything
that A uses.  Obviously if A has changed as well it must be recompiled,
but that is the trivial case.

Re: Crosspost: Help wanted from comp.compilers

[David C. Hoos]

I may have missed it, but in all this discussion about unnecessary
recompilation, I have seen no mention of the -m switch for gnatmake, viz.:

-m
Specifies that the minimum necessary amount of recompilations be performed.
In this mode gnatmake ignores time stamp differences when the only
modifications to a source file consist in adding/removing comments, empty
lines, spaces or tabs. This means that if you have changed the comments in a
source file or have simply reformatted it, using this switch will tell
gnatmake not to recompile files that depend on it (provided other sources on
which these files depend have undergone no semantic modifications).

This works wonderfully, and the only drawback is that if a file has been
reformatted and/or comments inserted, the debug line number references will
be wrong.

This is far better than, say, the VADS Ada-83 compiler, which if one
indavertently recompiled a spec (even with no change whatsoever to the
source file), all of the dependents of that spec were rendered out-of-date!


----- Original Message ----- 
From: "Ed Falis" <falis@verizon.net>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Thursday, July 17, 2003 1:14 PM
Subject: Re: Crosspost: Help wanted from comp.compilers


> On Thu, 17 Jul 2003 18:02:09 GMT
> tmoran@acm.org wrote:
>
> > > >   That's an example of a case where a textually unchanged spec
> > > >   file
> > > > needs to be recompiled because of a change in compiler options.
> > >
> > > But GNAT doesn't do it, as you yourself point out!
> >   Which is a bug in gnatmake, IMHO.
>
> Use the -s switch to gnatmake if you want that behavior.  How can it be
> considered a bug when it's not defined behavior in the Ada standard, and
> it is in the gnat manuals?
>
> - Ed
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: Crosspost: Help wanted from comp.compilers

[Ed Falis]

On Thu, 17 Jul 2003 13:35:03 -0500
"David C. Hoos" <david.c.hoos.sr@ada95.com> wrote:

> I may have missed it, but in all this discussion about unnecessary
> recompilation, I have seen no mention of the -m switch for gnatmake,
> viz.:
> 
> -m

Yes.  My point was that any of these kinds of behavior may be preferred
for a given situation, but that does not mean that lacking a given mode
is a bug, as Tom maintained. GNAT provides some level of choice in the
matter.

Re: Crosspost: Help wanted from comp.compilers

[Robert A Duff]

Ed Falis <falis@verizon.net> writes:

> On Thu, 17 Jul 2003 18:02:09 GMT
> tmoran@acm.org wrote:
> 
> > > >   That's an example of a case where a textually unchanged spec
> > > >   file
> > > > needs to be recompiled because of a change in compiler options.
> > >
> > > But GNAT doesn't do it, as you yourself point out!
> >   Which is a bug in gnatmake, IMHO.
> 
> Use the -s switch to gnatmake if you want that behavior.  How can it be
> considered a bug when it's not defined behavior in the Ada standard, and
> it is in the gnat manuals?

I don't claim this particular behavior is a bug, but surely something
can be a bug even if not mentioned in the Ada standard, and mentioned in
the compiler's manual!  For example, if an Ada compiler deleted the
source files from the disk after compiling them, that would be a bug.
The Ada standard doesn't forbid it, and it's still a bug even if the
compiler's manual documents it.

- Bob

Re: Crosspost: Help wanted from comp.compilers

[Robert A Duff]

tmoran@acm.org writes:

> > Just looking at files on disk does not give any history as to whether
> > a given _declaration_ within a file has changed.  One might end up
> > recompiling a cascading tree of modules because some entirely unused
> > (yet) declaration was added to a module.
>   If A 'with's B and something new is added to B's spec, how does a
> compiler know that the new thing is not used by A, unless it recompiles A?

If A didn't change since the spec of B changed, then the compiler could
know that without recompiling A.  However, things can get tricky -- B
might introduce a declaration that conflicts with some other declaration
use-visible in A.

- Bob

Re: Crosspost: Help wanted from comp.compilers

[Ed Falis]

On 17 Jul 2003 15:24:40 -0400
Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

> I don't claim this particular behavior is a bug, but surely something
> can be a bug even if not mentioned in the Ada standard, and mentioned
> in the compiler's manual!  For example, if an Ada compiler deleted the
> source files from the disk after compiling them, that would be a bug.
> The Ada standard doesn't forbid it, and it's still a bug even if the
> compiler's manual documents it.

No, then it's a "feature" and caveat emptor!

Taking a statement that would make sense in most contexts and driving it
to a logical and absurd conclusion doesn't invalidate its sensibility in
most contexts.  All it does is point to that fact that other evaluative
criteria than classification as a bug are at play.

Re: Crosspost: Help wanted from comp.compilers

[tmoran]

> >   Which is a bug in gnatmake, IMHO.
> Use the -s switch to gnatmake if you want that behavior.
  Sorry.  I should reread the Gnat User Guide more frequently.

> How can it be considered a bug when it's not defined behavior in the Ada
> standard, and it is in the gnat manuals?
  Does the ALRM say something about "make" type programs, or order of
compilation?
  IMHO, it's a design bug that -s isn't the default for gnatmake,
(and that -gnato isn't the default for something that calls itself
"The GNU Ada 95 Compiler").

Re: Crosspost: Help wanted from comp.compilers

[Ed Falis]

On Thu, 17 Jul 2003 19:40:40 GMT
tmoran@acm.org wrote:

>   IMHO, it's a design bug that -s isn't the default for gnatmake,
> (and that -gnato isn't the default for something that calls itself
> "The GNU Ada 95 Compiler").


Ok, note that I work for Ada Core, but these features and decisions
precede my employment, and I really have no particular investment in
them. I'm speaking as an individual here.

"I don't like what was done, and wouldn't do it that way myself" is not
the same thing as "This is a bug".

Don't you think?  "This is a bug" is a much stronger statement, and has
to be made (IMO) relative to some generally accepted notion of
"objective" criteria.  In this case, I don't think labelling these
default behaviors as bugs does stand up to that kind of scrutiny.

I've worked for other Ada compiler companies that took different
decisions, and I don't consider those decisions "bugs" either.


- Ed

Re: Crosspost: Help wanted from comp.compilers

[Robert A Duff]

Ed Falis <falis@verizon.net> writes:

> On 17 Jul 2003 15:24:40 -0400
> Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> 
> > I don't claim this particular behavior is a bug, but surely something
> > can be a bug even if not mentioned in the Ada standard, and mentioned
> > in the compiler's manual!  For example, if an Ada compiler deleted the
> > source files from the disk after compiling them, that would be a bug.
> > The Ada standard doesn't forbid it, and it's still a bug even if the
> > compiler's manual documents it.
> 
> No, then it's a "feature" and caveat emptor!

;-)

> Taking a statement that would make sense in most contexts and driving it
> to a logical and absurd conclusion doesn't invalidate its sensibility in
> most contexts.  All it does is point to that fact that other evaluative
> criteria than classification as a bug are at play.

OK, sorry, I was being overly argumentative.

But we all do in fact argue whether something-or-other is a "feature" or
a "bug".  And it's based on whether we think something-or-other is good
behavior, not on whether some document says so.

- Bob

Re: Crosspost: Help wanted from comp.compilers

[Ed Falis]

On 17 Jul 2003 16:20:21 -0400
Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

> But we all do in fact argue whether something-or-other is a "feature"
> or a "bug".  And it's based on whether we think something-or-other is
> good behavior, not on whether some document says so.

Yes, you're absolutely right.  My choice of the document as an example
of something relatively objective was probably bad.  It amazes me over
and over again how we try to make our subjective stances carry the
weight of something objective (or believe they do without trying). 

Guess I was feeling philosophical because I swatted some good bugs this
afternoon.

And this was nothing against Tom, except to point out the contextual
"envelope" around labelling a behavior as a bug.

- Ed

Re: Crosspost: Help wanted from comp.compilers

[tmoran]

> "I don't like what was done, and wouldn't do it that way myself" is not
> the same thing as "This is a bug".
  Agreed.  I should have said "IMHO, it's a design error", rather than
"bug".  "Bug" has an implication of "unexpected".  "IMHO" suggests
"I imagine some people might disagree".

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

Preben Randhol wrote:
> Actually you are not listening. He just showed you why it needed to be
> recompiled.

How did he do that? He was talking about needing to recompile
after making a change.

Re: Crosspost: Help wanted from comp.compilers

[Ed Falis]

On Thu, 17 Jul 2003 21:23:41 GMT
tmoran@acm.org wrote:

> > "I don't like what was done, and wouldn't do it that way myself" is
> > not the same thing as "This is a bug".
>   Agreed.  I should have said "IMHO, it's a design error", rather than
> "bug".  "Bug" has an implication of "unexpected".  "IMHO" suggests
> "I imagine some people might disagree".

We agree ;-)

Re: Crosspost: Help wanted from comp.compilers

[John R. Strohm]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:2OERa.4718$0F4.3216@nwrdny02.gnilink.net...
> Preben Randhol wrote:
> > Actually you are not listening. He just showed you why it needed to be
> > recompiled.
>
> How did he do that? He was talking about needing to recompile
> after making a change.

Where we seem to disagree is that you seem to be believe that only changes
to source code can produce changes to semantics, and that those changes
should only propagate through one level of inheritance ('with').  You have
explicitly stated, repeatedly, that recompiling a unit whose source code has
not changed, with ONLY a change in compiler options, should NOT trigger
recompilation of dependent units.

Consider a contrived example.  First, postulate a compiler option, that
suppresses generation of type'image information for enumerated types.  This
is a fairly obvious space optimization, that does no harm at all if the rest
of the code does not use type'image.  Consider a package spec that declares
an enumerated type, that is used by a module that uses that type'image, say,
to display symbology labels.

Compile the spec with type'image generated.  Compile the using module.
Recompile the spec with type'image suppressed.  Link.

Oops.

If you are REALLY lucky, the error will be detected at link time, because
type'image data is hooked up through a special external symbol, and the
symbol isn't there, because type'image was suppressed.  If you are lucky,
you will spot it when you take the build into the lab and wonder why the
frap your symbology labels are missing.  If your luck is run-of-the-mill,
what you will be doing is wondering why the $#&^$#^ your build crashes and
burns before it even brings up the symbology.

Observe that forcing recompilation of the using module will bring the error
to light.  In this strawman scenario, it will also force you to recompile
the spec, then recompile the using module.

Alternatively, consider a compiler that has an option that will force it to
generate some extra debugging entry points if a certain compiler switch is
set.  Consider a runtime design that uses a transfer table.  Recompiling the
spec after changing the switch setting may reorder the transfer table, and
dependent modules that were compiled prior to the changing of the switch may
not know about the change.  Result: when you try to call the routine that
emergency jettison's all external stores, you instead call the routine that
fires the ejection seat squib.  This kind of error is guaranteed to make you
unpopular with the test pilot community.  (Incidentally, this is not far
from the example that Jean Ichbiah himself gave when asked why Ada required
recompilation of all dependents if a spec that had not changed was
recompiled.)

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

John R. Strohm wrote:
> Where we seem to disagree is that you seem to be believe that only changes
> to source code can produce changes to semantics, and that those changes
> should only propagate through one level of inheritance ('with').

What I believe is that people hated their compilers for doing stuff
like this, and that lengthy recompilation was such an issue that it
became part of the design specs for Ada95. Obviously you can come up
with situations where funny flag settings could require dependents
to be recompiled, but that's not really an excuse for poor quality of
implementation.

 > (Incidentally, this is not far from the example that Jean Ichbiah
 > himself gave when asked why Ada required recompilation of all
 > dependents if a spec that had not changed was recompiled.)

Where does Ada require this?

Re: Crosspost: Help wanted from comp.compilers

[John R. Strohm]

X-A-Notice: References line has been trimmed due to 512 byte limitationAbuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library2.airnews.net
NNTP-Posting-Time: Fri, 18 Jul 2003 01:24:29 -0500 (CDT)
NNTP-Posting-Host: !`-]Z1k-WDO1mC& (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:wDJRa.5501$0F4.1836@nwrdny02.gnilink.net...
> John R. Strohm wrote:
> > Where we seem to disagree is that you seem to be believe that only
changes
> > to source code can produce changes to semantics, and that those changes
> > should only propagate through one level of inheritance ('with').
>
> What I believe is that people hated their compilers for doing stuff
> like this, and that lengthy recompilation was such an issue that it
> became part of the design specs for Ada95. Obviously you can come up
> with situations where funny flag settings could require dependents
> to be recompiled, but that's not really an excuse for poor quality of
> implementation.
>
>  > (Incidentally, this is not far from the example that Jean Ichbiah
>  > himself gave when asked why Ada required recompilation of all
>  > dependents if a spec that had not changed was recompiled.)
>
> Where does Ada require this?

Review the recompilation rules that you have been kvetching about for the
last few days.

Maybe you should spend some time actually learning and using Ada.

Re: Crosspost: Help wanted from comp.compilers

[Larry Kilgallen]

In article <bf7iiq$e64@library1.airnews.net>, "John R. Strohm" <strohm@airmail.net> writes:

> Consider a contrived example.  First, postulate a compiler option, that
> suppresses generation of type'image information for enumerated types.

Consider a contrived example where a given option causes the compiler
to treat all declarations ending in B as if then instead ended in X.

Now where are the real-world examples of compilers that do these things.

Re: Crosspost: Help wanted from comp.compilers

[Larry Kilgallen]

>>  > (Incidentally, this is not far from the example that Jean Ichbiah
>>  > himself gave when asked why Ada required recompilation of all
>>  > dependents if a spec that had not changed was recompiled.)
>>
>> Where does Ada require this?
> 
> Review the recompilation rules that you have been kvetching about for the
> last few days.

That seems to me a very impolite non-answer.

Even if one granted the obligation of every person to be a full expert
in every issue on which they commented, this is a newsgroup that many
others are reading, not an email discussion.

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

John R. Strohm wrote:
> Review the recompilation rules that you have been kvetching
 > about for the last few days.

10.1.4/5 says
     When a compilation unit is compiled, all compilation units
     upon which it depends semantically shall already exist in
     the environment;

Where does it say that when a compilation unit is compiled all
compilation units which depend on it must be recompiled?

 > Maybe you should spend some time actually learning and using Ada.

Maybe you should spend some time learning to read the posts
to which you respond.

Re: Crosspost: Help wanted from comp.compilers

[Robert I. Eachus]

Larry Kilgallen wrote:

> That seems to me a very impolite non-answer.
> 
> Even if one granted the obligation of every person to be a full expert
> in every issue on which they commented, this is a newsgroup that many
> others are reading, not an email discussion.

It seemed extremely polite to me.  There have been two things going on 
here.  An informative discussion of Ada recompilation policies and why 
they are the way they are, and Hyman Rosen continually jumping in to 
pour more gasoline on the flames.  There is a lot I can add to the 
intelligent discussion but I try to control my input to avoid feeding 
the troll.

For example, there were cases where Verdix 5.4.1? blew link-time 
dependences invovling generic instantiations and required creating a new 
library and recompiling the world.  A bug?  Sure.  But the bug was there 
because Verdix did a much better job of mananging generic instances and 
their dependences, then got confused by some second order effect when 
generic unit bodies were modified.  The usual failure was a generic A 
withed generic B, and package C contained an instance of A.  Recompiling 
the body of A did not invalidate the compile of C--it only depended on 
the spec.  But that change to the body of A could create a need for new 
instances of B.  If there was a naming conflict between the new 
instances of B (in the body of A) and the old, Verdix basically threw up 
its hands.  Recompiling everything got rid of the conflicts.

So why use Verdix?  Because the elimination of the permitted (by the RM) 
but not required dependences meant that you could do things with Verdix 
that were not possible with other Ada compilers.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Crosspost: Help wanted from comp.compilers

[Robert I. Eachus]

Preben Randhol wrote:

> Perhaps I misunderstand you, but if you make the .ali files read-only
> the library won't be recompiled when you with a unit in your program. If
> it needs to be due to change of compiler or some other reason the
> compiler will stop compiling and tell you it is needed. But I guess you
> were refering to something else?

You misunderstood.  The specifications of all units, usually packages, 
that you with are recompiled everytime.  This does not affect the status 
of that unit.  It is just that it is faster and easier to do those 
recompiles than to store an intermediate representation of the spec.

To compare the two approaches:

Old way:

When you compile a package specification, a library entry is created 
containing a processed version of the package spec.

When you compile a unit that withs that package, the processed version 
is found and loaded into the compiler.

GNAT way:

IF you compile a package specification, the compiler checks it for 
errors and does nothing else.  (Well it gives you a message saying no 
code generated.  Go do gnatmake foo.ads for some package specification 
you have lying around to try it.)

When you compile a body (foo.adb) the complier creates a transitive 
closure of the with clauses, compiling each specification as found.  The 
compiler then compiles the body, including any subunits, creates an 
object file (and other files) and puts them in the directory (program 
library).

Are there cases where doing things the old way would be faster?  Sure. 
But in the majority of cases the new GNAT approach, shared by some other 
Ada 95 compilers is faster.  And as far as I am concerned, it is better 
for actual Ada programmers.  This goes back to a very old paper, 
"Nesting in Ada is for the Birds,"  by  L. Clarke, J. Wileden & A. Wolf, 
  ACM SIGPLAN Notices 15, 11 (1980), 139-145.  (How's that for Googling 
an old reference out of nowhere. ;-)  In Ada trees tend to become 
shorter and bushier as programmers get more familiar with Ada style.  So 
for all I know, compiling specs into the library was the right model for 
Ada 83, but the new model is better now.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

Robert I. Eachus wrote:
> But in the majority of cases the new GNAT approach, shared by some other 
> Ada 95 compilers is faster.

Especially when you have Dewar writing the parser :-)

It's also simpler. Since you don't have to create an
intermediate external representation of the spec, you
save yourself a whole bunch of effort.

Re: Crosspost: Help wanted from comp.compilers

[Robert I. Eachus]

Hyman Rosen wrote:

> 10.1.4/5 says
>     When a compilation unit is compiled, all compilation units
>     upon which it depends semantically shall already exist in
>     the environment;
> 
> Where does it say that when a compilation unit is compiled all
> compilation units which depend on it must be recompiled?

It DOESN'T!  What you want is found in 10.2(27): "The implementation 
shall ensure that all compilation units included in a partition are 
consistent with one another, and are legal according to the rules of the 
language."

I won't go very deeply into why an environment is allowed to contain 
illegal units.  (It supports certain types of version control systems.) 
  But the result is that an environment may contain many mutually 
illegal compilation units.  The process of creating a partition (think 
linking) is only allowed to select a set of mutually legal and 
consistant units.

Now go back to 10.1.4(5), when you compile a compilation unit, "all 
compilation units on which it depends semantically shall already exist 
in the environment." So if you (successfully) recompile a unit on which 
another unit semantically depends, those two units are now mutually 
illegal.  How do you fix that?  You recompile the dependent unit.  Got it?

But why am I spending this effort responding to a troll?  I guess 
because I like to see this newsgroup as a resource for people learning 
Ada, or interested in learning it better.  And that requires some 
attempts to preserve the ability to get accurate answers here.

This is a very subtle area of the reference manual, because it 
simultaneously wants to allow the widest possible array of configuration 
management approaches, while having some very strict rules about 
consistancy of programs.  So environments are, as you will see if you 
read all of clause 10, welcome to contain inconsistant and illegal 
compilation units.  Partitions and programs are not.

So we went to a lot of effort to word this part of the manual so that an 
environment is not required to "throw away" compilation units, but the 
process of putting together a program or partition must do that weeding. 
  You can have two versions of a library unit in the environment, one 
old, one new, and two different main programs in the environment, where 
it is possible to construct legal partitions around these main programs 
one that contains the old version of the library unit, one that contains 
the new.  All that is intentional, and I do have some environments that 
I use that way.  (Multiple main programs with possibly mutually 
inconsistant subunits.  Usually the difference is that one set of 
library units is compiled with -gnata, the other without.)

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Crosspost: Help wanted from comp.compilers

[Richard Riehle]

tmoran@acm.org wrote:

>
>   Remember that Ada has separate specs and bodies.  If you want to change
> the optimization or get additional debug output on the body, you can
> recompile the body and it doesn't cause cascades.  If you recompile the
> spec with a different optimization level then some things (record layouts,
> for instance) might change, and you certainly had better recompile
> anything that depends on that spec.

I recall one of oiur Ada 83 clients who developed a large system for the
DoD and constantly complained about how long it took to compile
programs.  We looked at the dependencies early in our review and
discovered that nearly context clause was at the package specification
level even though much of the stuff did not require context clauses
at that level.  The compiler they were using did not issue a warning about
this.

In many cases,  simply moving the context clauses to the body was
sufficient.  In other cases, slight changes were necessary to the
specification   to  permit moving context clauses.  In a few cases,
it was appropriate to declare "is separate"  for certain subprograms
in the body and move the dependencies to the separately compiled
subunits.

This solution greatly improved compilation times, made maintenance
much more convenient, and reduced some of the overhead spent on
programmers who needed to stay on into the night watching their
compilations grind on, while they watched in the hope the  computer
would not crash (it sometimes did) during recompilation.

Even with Ada 83, much of the complaining about long compilation
times was easily solved by designing the dependencies intelligently.
This is one benefit of the Ada separate compilation model.  Even
though many Ada practitioners dislike subunits, they did then and
continue today, to have a place in  good design.

Richard Riehle

Re: Crosspost: Help wanted from comp.compilers

[Marin David Condic]

And the odds are they were wishing they could go back to Fortran where 
they would be forced to recompile the world to make sure it was correct 
(and even then not being sure) and then resort to playing fast & loose 
by recompiling just the one module they thought they changed and take 
their chances on the rest being wrong. ;-)

I've always liked Ada's ability to check consistency across modules - 
perhaps from having done it other ways and being burned too often. 
You're absolutely correct that one has to learn how to use the tools 
properly (exempli gratis, not "withing" everything at the package spec 
level) if one wishes to avoid unnecessary work. However, even used 
incorrectly - recompiling the world every time, for example - it 
probably *still* saves more time than it costs when considering how much 
time it takes to track down interface consistency errors with a debugger.

MDC

Richard Riehle wrote:
> 
> 
> I recall one of oiur Ada 83 clients who developed a large system for the
> DoD and constantly complained about how long it took to compile
> programs.  

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

Robert I. Eachus wrote:
> Now go back to 10.1.4(5), when you compile a compilation unit, "all 
> compilation units on which it depends semantically shall already exist 
> in the environment." So if you (successfully) recompile a unit on which 
> another unit semantically depends, those two units are now mutually 
> illegal.  How do you fix that?  You recompile the dependent unit.  Got it?

No. First of all, "exist in the environment" is not a defined concept,
and doesn't even have to mean object files. For GNAT, existing in the
environment just means that it can get at the source code of with'ed
modules. Second, nothing in what you stated implies that recompiling a
module forces it to be inconsistent with other already compiled modules
which depend on it. Some systems do this, but that is an implementation
shortcut they have taken, not a requirement from the language.

> But why am I spending this effort responding to a troll?

I'm not sure why you consider this to be a troll. If nothing else, the
fact the recompilation issues were part of the design requirements of
Ada 95 should demonstrate that Ada had significant problems in this area,
even without pessimizing compilation systems.

Re: Crosspost: Help wanted from comp.compilers

[Chad R. Meiners]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:FTxSa.6118$634.1978@nwrdny03.gnilink.net...

> No. First of all, "exist in the environment" is not a defined concept,
> and doesn't even have to mean object files. For GNAT, existing in the
> environment just means that it can get at the source code of with'ed
> modules.
red herring
> Second, nothing in what you stated implies that recompiling a
> module forces it to be inconsistent with other already compiled modules
> which depend on it.
Strangely enough this statement also appears to be a red herring.
>
> I'm not sure why you consider this to be a troll. If nothing else, the
> fact the recompilation issues were part of the design requirements of
> Ada 95 should demonstrate that Ada had significant problems in this area,
> even without pessimizing compilation systems.
When I read the Ada 95 Rationale's requirements section recompilation issues
were not on the list of four major design requirements.  Nevertheless, you
failed to show causality with your implication.  Recompilation issues could
have been a part of the design requirements because someone thought up a
better way to formulate them.  Just because something was changed does not
imply that there were "significant problems".  Anyway a "significant
problem" is in the eye of the beholder; therefore you implication holds no
meaning.  It is, however, emotionally charged.

Why am I going to such trouble in dissecting your statements?  I simply
wanted to show you why people sometimes consider you to be a troll.  Two red
herrings and an emotion provoking bogus implication.

Re: Crosspost: Help wanted from comp.compilers

[Robert I. Eachus]

Hyman Rosen wrote:

> No. First of all, "exist in the environment" is not a defined concept,
> and doesn't even have to mean object files.

See 10.1.4(3). Of course it doesn't mean--or have anything to do 
with--object files.

> Second, nothing in what you stated implies that recompiling a
> module forces it to be inconsistent with other already compiled modules
> which depend on it. Some systems do this, but that is an implementation
> shortcut they have taken, not a requirement from the language.

See, this is why you are a troll. RM 10.1.4(5) is completely clear on 
this issue.

> I'm not sure why you consider this to be a troll.

Let's see.  You pretend to be an expert on Ada.  And every time you open 
your mouth in this newsgroup you reveal the depths of your ignorance.

> If nothing else, the
> fact the recompilation issues were part of the design requirements of
> Ada 95 should demonstrate that Ada had significant problems in this area,
> even without pessimizing compilation systems.

If you had been paying attention, you would have noticed that they were 
considered for inclusion.  I was one of the people who commented on that 
and convinced everyone that the current model did not need fixing. 
There are different implementations of that model, and I certainly agree 
that the work that Robert Dewar and Richard Stallman (rms) plus others 
put into developing the GNAT implementation of that model were also 
played a big part.

I know the history.  I have been involved in the development and 
standardization of Ada since 1981.  I am not perfect and I don't claim 
to be.  But you may have noticed that if I make a mistake in a posting 
here I acknowledge it gracefully.  You need to learn how to do that.

I apologize to every other comp.lang.ada reader for once again being 
tempted into responding to this troll.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

Robert I. Eachus wrote:
> See, this is why you are a troll. RM 10.1.4(5) is completely clear on 
> this issue.

Not at all. That section just says that when something is compiled,
it needs to see a consistent set of the things it depends on. What
you are talking about is found in 10.1.4(7), as an implementation
*permission*. That section says that when something is compiled, an
implementation may remove its dependents from the environment. But
that is a permission, not a requirement, and is clearly suboptimal
with respect to avoiding recompilations.

> Let's see.  You pretend to be an expert on Ada.  And every time you open 
> your mouth in this newsgroup you reveal the depths of your ignorance.

I have never claimed to be an expert in Ada. On the contrary, I
have quite often prefaced my remarks with "I don't know Ada, but..."
On the other hand, I do not believe that you are correct about my
postings. I think you are defensively overreacting to perceived
slights against your favorite language.

> But you may have noticed that if I make a mistake in a posting 
> here I acknowledge it gracefully.  You need to learn how to do that.

Many of the discussions we have here revolve around different
interpertations of the same facts, so that it's seldom clear
that someone has made a mistake. I apologize for implying that
all Ada implementations had "horrible" recompilation issues,
but I think that it's unquestionable that at least some did,
and in such a way that "days-long" recompilations became a
very public and visible issue for Ada.

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

Chad R. Meiners wrote:
> red herring

I pointed out that sections which are claimed to provide
a reason for certain recompilations in fact do not. I don't
know why you consider that to be a red herring. The section
which talks about recompiling dependents when a unit is
compiled is 10.1.4(7), and that is an implementation
permission, not a requirement.

> When I read the Ada 95 Rationale's requirements section recompilation issues
> were not on the list of four major design requirements.

Section I.3, listing the four main user needs, includes
the cost of recompilation as a factor in two of them,
programming by extension and program libraries.

> Anyway a "significant problem" is in the eye of the beholder;
 > therefore you implication holds no meaning. It is, however,
 > emotionally charged.

I have posted this before -
<http://archive.adaic.com/docs/flyers/95fast.html>
     "Say good-bye to the days of multiple-day
      recompilation of Ada 83 software."
This is from a page extolling the virtues of Ada.

I don't know why I should be accused of trolling when it
seems to me that the Ada community was well aware of the
issues surrounding lengthy recompilations and proclaimed
Ada 95 as a soultion.

Re: Crosspost: Help wanted from comp.compilers

[tmoran]

Are separate compilations using different settings of compiler switches
considered to be compilations by different compilers/versions, and thus
not discussed by the ARM but left to compiler writers and users to handle?

Re: Crosspost: Help wanted from comp.compilers

[Chad R. Meiners]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1058801854.533242@master.nyc.kbcfp.com...
> Chad R. Meiners wrote:
> > red herring
>
> I pointed out that sections which are claimed to provide
> a reason for certain recompilations in fact do not. I don't
> know why you consider that to be a red herring. The section
> which talks about recompiling dependents when a unit is
> compiled is 10.1.4(7), and that is an implementation
> permission, not a requirement.

Well the first red herring didn't apply seem to apply to the argument at
hand.   In retrospect, the second herring doesn't seem to be one.  I
misunderstood its intended meaning since it was not obvious that the
statement was intended to accomplish what you wanted it to.

> > When I read the Ada 95 Rationale's requirements section recompilation
issues
> > were not on the list of four major design requirements.
>
> Section I.3, listing the four main user needs, includes
> the cost of recompilation as a factor in two of them,
> programming by extension and program libraries.
>
> > Anyway a "significant problem" is in the eye of the beholder;
>  > therefore you implication holds no meaning. It is, however,
>  > emotionally charged.
>
> I have posted this before -
> <http://archive.adaic.com/docs/flyers/95fast.html>
>      "Say good-bye to the days of multiple-day
>       recompilation of Ada 83 software."
> This is from a page extolling the virtues of Ada.

When I examine these documents, I find that they support the view that long
recompilations issues result from high coupling.  The solution that Ada 95
provided was to add more features that allowed you to reduce coupling.  So
the impression I get is that the new features provide you with more methods
to modularize your code, and a direct benefit of this improvement is a
possible reduction of recompilation time if you design your programs
properly.  I think this is similar to what some others were trying to say,
but I would have to go back a reread this thread.

> I don't know why I should be accused of trolling when it
> seems to me that the Ada community was well aware of the
> issues surrounding lengthy recompilations and proclaimed
> Ada 95 as a soultion.

Miscommunication coupled with the occasional poorly formed arguments.  If it
is any consolation, I don't think you are troll; I just think that sometimes
you miscommunicate your position.  ;-)

Re: Crosspost: Help wanted from comp.compilers

[Robert I. Eachus]

Hyman Rosen wrote:

 > Not at all. That section just says that when something is compiled,
 > it needs to see a consistent set of the things it depends on. What
 > you are talking about is found in 10.1.4(7), as an implementation
 > *permission*. That section says that when something is compiled, an
 > implementation may remove its dependents from the environment. But
 > that is a permission, not a requirement, and is clearly suboptimal
 > with respect to avoiding recompilations.

This I can happily answer.  It is in 10.1.4(7).  Let me quote it again,
with some comments to explain:

"When a compilation unit is compiled, all compilation units upon
which it depends semantically shall already exist in the environment;"

Notice two things here.  All the units on which a unit being compiled
depends must already be in the environment, and the semicolon at the
end.  IMHO the semicolon grates, but in the standard, it indicates that
this rule isn't finished yet.

"...the set of these compilation units shall be _consistent_ in the 
sense that the new compilation unit shall not semantically depend
(directly or indirectly) on two different versions of the same
compilation unit, nor on an earlier version of itself."

The fact that consistant is italized indicates that this is a formal
definition of a technical term.  So a unit is only consistant with one
version (there may be several in the environment) of any unit it
semantically depends on, and that version must have been in the 
environment when the dependent unit was compiled.

Finally we get to 10.2(27):

"The implementation shall ensure that all compilation units included in
a partition are consistent with one another, and are legal
according to the rules of the language."

There is that consistant again, but now it is used rather than defined. 
The result, when you put it all together, is that when you compile 
something into the environment, the environment _chooses_ a consistant 
set of units that the unit that you are compiling depends on.  When you 
later execute the program, the environment for your main program or 
partition contains a _consistant_ set of units.  As we saw above, it is 
only possible for a unit (call it A) to be consistant with a particular 
version of another unit (B) it depends on, if that version of B was in 
the environment when A was compiled.

Whew! Now if you look at 10.2(7):

"The user can optionally designate (<b>in an implementation-defined 
manner</b>) one subprogram as the main subprogram for the partition. A 
main subprogram, if specified, shall be a subprogram."

If your main program is A from above, and you recompile B, the 
implementation has two choices.  It can leave the original compiled 
version of B in the environment and link A and the old B, or it can tell 
you to recompile A.  There are systems that do either!  But it is 
considered highly unfriendly for the normal mode of linking to give you 
the old versions of A and B.

For example, in a version control system, I may have a "playpen" where I 
can modify units that are checked in and link with them, without 
checking the units out.  In most compilers, the playpen will be a 
separate directory.  If you link in that directory you will get the new 
B--after A is recompiled.  If you link in the version controlled 
directory, without checking the new B in, you will get the old B and the 
old A.

So this is what is confusing you.  The definition of environments is 
intentionally broad enough to encompass such version control systems. 
But combination of the paragraphs above insure that even if there are 
inconsistant and mutually illegal, or even totally illegal units in the 
environment, at the point where the program (or partition) is executed, 
you have a mutually consistant and legal set of units.

In short, you can defer some recompilations but never beyond link time.

 > Many of the discussions we have here revolve around different
 > interpertations of the same facts, so that it's seldom clear that
 > someone has made a mistake.

Ah, a lesson about Ada and interpretations.  You may see references to 
AIs.  These are officially Ada Issues which are being studied by or 
which have been studied by the ARG, the Ada Rapporteur Group, which is a 
part of ISO/IEC JTC1/SC22/WG9.  Some Ada Issues result in "binding 
interpretations" which result in changes to the Ada Reference Manual. 
The on-line version of the RM at http://www.ada-auth.org/, as explained 
there has all of the interpretations from the TC folded in. So that is a 
good place to go to check anything you might want to know.  You can also 
find all of the Ada Issues there.

Of course, no member of the ARG is perfect.  I certainly am not.  But 
when we speak "ex cathedra" of our interpretations of what the Reference 
Manual says, we are literally right even when we are wrong. (There was 
even one AI classified as a binding interpretation for Ada 83 which 
reversed an earlier AI.  We try to avoid that. ;-)  So interpretation is 
a very loaded word to use in a discussion of the Ada language.

 >                                 I apologize for implying that all Ada
 > implementations had "horrible" recompilation issues, but I think that
 > it's unquestionable that at least some did, and in such a way that
 > "days-long" recompilations became a very public and visible issue for
 > Ada.

As I said, there were some "horrible" recompilation issues, but in every 
case the horrible issues were resolved by education, mostly in software 
engineering.  There were some actual recompilation issues with early Ada 
compilers, but most of those were in the nature of bugs typical of 
compilers at that stage of development.  The conclusion that there were 
NO language-related recompilation problems was definitely non-obvious. 
But it was reached by the Ada 9X requirements team, and by the time that 
Ada 95 was approved, that conclusion was widely shared.

Incidently, a lot of that had to do with the issue of creating 
dependences on generic bodies by units that instantiated the generic. 
Originally DEC Ada took aggressive advantage of that permission by 
default, to generate more optimal code, but with more recompilations 
required.  Well before the Ada 9X process began, all of the Ada 
compilers that took advantage of that permission had been changed due to 
user pressure to make it not the default behavior.  Then what had been a 
non-binding interpretation (don't do that) became a binding 
interpretation (the Ada Reference Manual changed).

It is perfectly reasonable to have a compiler setting that does 
inter-library unit optimizations at the expense of potential additional 
recompilations.  But most programmers don't want to use such a setting 
during development.  (GNAT doesn't even have one.  You can get the 
effect by creating a few big compilation units--potentially one--but 
then it is very clear what you are asking for.)

So you can see why I say this was an education issue.  It is like 
learning that you should use gnatmake -gnato if you want all the 
standard constraint checks.  Definitely not a language issue, but you do 
need to read the (GNAT) documentation.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are
insignificant beside two prime questions, which are: 1. Can he shoot? 2.
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and
Steve Miller.

Re: Crosspost: Help wanted from comp.compilers

[Robert I. Eachus]

tmoran@acm.org wrote:
> Are separate compilations using different settings of compiler switches
> considered to be compilations by different compilers/versions, and thus
> not discussed by the ARM but left to compiler writers and users to handle?

I can't answer your question, because I can't see how to give you an 
answer that is both correct and informative.  (Well, I'll answer it: the 
compiler can make daemons fly out of your nose. See, no help.)

Any _implementation_ defines processes for creating an environment, 
adding and deleting units in that environment, and what it means to 
compile a (compilation) unit and put it into the environment.  An 
implementation is allowed to define lots of other things which are not 
part of the "standard mode."

For example with GNAT, to compile in the standard mode you must use 
gnatmake -gnato <compilation unit or pragma>.  The Ada RM says a lot 
about what must happen in standard mode, and allows ANYTHING in 
non-standard mode.  If you use the gcc that is part of GNAT to compile a 
C program?  Shrug, why should the Ada Reference manual care?  As it 
happens the compiler depends on a .ads or .adb source file extension to 
indicate a compile in standard Ada mode, and other source file 
extensions to indicate other languages.

Similarly, the RM says a lot about what must happen with standard 
pragmas, and attribute specification clauses.  The implementation can 
define compile time flags to have a similar effect, but it can't change 
the meaning of a _language_ defined attribute or pragma.

Now to answer the question that I think you had.  What is said in clause 
10 is absolute. A compiler can keep two sets of compilation units in the 
library, one compiled with debugger support and one without, and use a 
link or run-time option to determine which version you get.  Not a 
problem.  But the units have to be compiled into the environment in 
10.1.4 order and a consistant and legal set chosen at run-time in 
accordance with 10.2--if you are in standard Ada mode.  (And as should 
be clear NONE of this applies to C or Fortran mode, or whatever.)

-- 

                                             Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

Robert I. Eachus wrote:
> If your main program is A from above, and you recompile B, the 
> implementation has two choices.  It can leave the original compiled 
> version of B in the environment and link A and the old B, or it can tell 
> you to recompile A.

I'm starting to remember an earlier discussion on this subject, (that
I don't think I was involved in). If I recall correctly, it's valid to
define "exist in the environment" as "source code is readable" and to
define "compile" as "check that the code is legal". Then object file
generation doesn't have to be tied to the requirements that you are
talking about, so the issue can be sidestepped (while still remaining
true to both the letter and spirit of the Ada requirements).

Re: Crosspost: Help wanted from comp.compilers

[John R. Strohm]

X-A-Notice: References line has been trimmed due to 512 byte limitationAbuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library2.airnews.net
NNTP-Posting-Time: Tue, 22 Jul 2003 00:02:03 -0500 (CDT)
NNTP-Posting-Host: !WfJM1k-Vm_:">0 (Encoded at Airnews!)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:3b1Ta.14846$0F4.12183@nwrdny02.gnilink.net...
> Robert I. Eachus wrote:
> > If your main program is A from above, and you recompile B, the
> > implementation has two choices.  It can leave the original compiled
> > version of B in the environment and link A and the old B, or it can tell
> > you to recompile A.
>
> I'm starting to remember an earlier discussion on this subject, (that
> I don't think I was involved in). If I recall correctly, it's valid to
> define "exist in the environment" as "source code is readable" and to
> define "compile" as "check that the code is legal". Then object file
> generation doesn't have to be tied to the requirements that you are
> talking about, so the issue can be sidestepped (while still remaining
> true to both the letter and spirit of the Ada requirements).

That is true, BUT it does not satisfy the critical requirement.

The critical requirement is not for "exist in the environment".

The critical requirement, as Robert pointed out, is for "consistency" at
link time.  This is what drives the recompilation rules.

Re: Crosspost: Help wanted from comp.compilers

[Robert I. Eachus]

Hyman Rosen wrote:

> I'm starting to remember an earlier discussion on this subject, (that
> I don't think I was involved in). If I recall correctly, it's valid to
> define "exist in the environment" as "source code is readable" and to
> define "compile" as "check that the code is legal". Then object file
> generation doesn't have to be tied to the requirements that you are
> talking about, so the issue can be sidestepped (while still remaining
> true to both the letter and spirit of the Ada requirements).

NO! Wrong. You can define a simple text copy as putting a unit in the 
environment.  In effect GNAT among others does this for package specs. 
But there is no way to get around the ordering requirements, and there 
should not be.  Some people get confused by the situation with generics. 
  Modifying a generic body may seem like it should invaldate instances 
of the generic, but that is why the generic contract model is there.

An implementation can however make the "compile" process a simple 
check-in and defer code generation until link time.  I think Rational 
may still do that.  But the whole dependency checking thing is one of 
the major strengths of Ada.  Trying to short-cut it has been discovered 
time and again to not be worth the effort--whether or not it can be made 
to work.

Similarly there was a lot of screaming about "elaboration checks" and 
access-before-elaboration issues in early Ada.  The elaboration rules in 
Ada 83 (and Ada 95) were adopted fairly late in the standardization 
process.  But once compiler vendors got used to them, the issue 
disappeared from most Ada programmer's event horizons.

This is in part why I say that at least 80% of the Reference Manual 
deals with what happens when you try to shoot yourself in the foot.  For 
most programmers who understand basic software engineering principles, 
all they need to know about overload resolution is that it works.  All 
they need to know about semantic dependence is that sometimes when they 
call gnatmake (or whatever compiler) it will recompile some units they 
didn't touch.  And they may never see Program_Error raised by an 
elaboration check, because almost all of the work is done in the main 
program, not in the sequence of statements of a package body.  (In fact, 
I wonder how many package bodies even have a sequence of statements...)

-- 

                                          Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.

Re: Crosspost: Help wanted from comp.compilers

[Marin David Condic]

In my experience, almost none. And now that we have initialization 
available through Ada.Finalization, there is even less excuse. I suppose 
it is nice to have it so that packages look "orthogonal" with respect to 
procedures and functions, but in practice, if it didn't exist, I think 
we'd get along fine.

MDC



Robert I. Eachus wrote:

> program, not in the sequence of statements of a package body.  (In fact, 
> I wonder how many package bodies even have a sequence of statements...)
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Crosspost: Help wanted from comp.compilers

[Randy Brukardt]

It is important to realize the primary reason that you don't hear as much
griping about 'recompile the world' these days is that it simply doesn't
take very long to do it.

Our original MS-DOS development system was a 10 MHZ 8086 Seattle Computer
with twin 1.2 Meg 8" floppies. (This was twice as fast as the original IBM
PC.) Each compiler pass had its own development floppy, while the compile,
operating system, utilities, and shared libraries fit on the other floppy.
Recompile the world took around 4 hours on that system.

More recently, our validated Ada 83 compilers took 4-6 hours to recompile on
386/25 class machines. Running the ACVC (ACATS now) took more than 12 hours.
But the Ada 95 compiler (which is quite a bit larger) only takes 20-30
minutes to compile on my current system, and the ACATS takes less than 3
hours to run.

At those speeds, full recompiles aren't so daunting. You no longer schedule
your entire development around adding a component to the symbol table
definition.

It's true that Ada 95 helps in that it can decrease coupling. But the real
help has simply been faster hardware.

                       Randy.

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

Robert I. Eachus wrote:
> But there is no way to get around the ordering requirements,
 > and there should not be.

I'm not trying to get around the ordering requirements in
terms of making sure that a linked program is correct and
consistent. I'm trying to get around the implication that
once everything is compiled, the simple act of recompiling
a unit, when neither its source nor its compilation flags
have changed, forces all dependent units to be recompiled,
as a requirement of the Ada programming language. I still
do not believe that this is the case.

Re: Crosspost: Help wanted from comp.compilers

[Simon Wright]

tmoran@acm.org writes:

> > GNAT doesn't exhibit such behavior.
>   I just 'touch'ed a spec file, but made no changes.  I then ran gnatmake
> with the same options as previously.  Lo and behold, Gnat recompiled the
> spec, the body, and the main program that 'with'ed that spec.  So Gnat
> most assuredly does recompile when there might be a change.

If you say "gnatmake -m" it will only recompile for significant
differences (not just layout, comment etc). Great for those of us who
generate code!

Re: Crosspost: Help wanted from comp.compilers

[Vinzent Hoefler]

Hyman Rosen wrote:

>consistent. I'm trying to get around the implication that
>once everything is compiled, the simple act of recompiling
>a unit, when neither its source nor its compilation flags
>have changed, forces all dependent units to be recompiled,
>as a requirement of the Ada programming language.

Look at this:

|C:\prj\elan520>gmake clean
|rm -f *.ali *.o *.s
|
|C:\prj\elan520>gnatmake -m elan520
|gcc -c elan520.adb
|gcc -c elan520-basic_types.ads
|gcc -c elan520-cpu_registers.ads
|gcc -c elan520-mmcr.ads
|gcc -c elan520-programmable_address_region.ads
|gcc -c elan520-registers.ads
|gcc -c elan520-sdram_controller_registers.ads
|gcc -c elan520-sdram_buffer_control.ads
|
|C:\prj\elan520>\djgpp\bin\touch elan520-sdram_buffer_control.ads
|
|C:\prj\elan520>gnatmake -m elan520
|
|C:\prj\elan520>gnatmake elan520
|gcc -c elan520.adb
|gcc -c elan520-mmcr.ads
|gcc -c elan520-sdram_buffer_control.ads

As you see, after just updating the timestamp, gnatmake -m[0] still
does nothing, but gnatmake without the "minimum recompile" option
still recompiles all dependent units, of course.

My guess is, gnatmake -m is still a valid Ada compiler, so doing the
recompile can't be a requirement of the language. ;)

>I still do not believe that this is the case.

Me neither. :)


Vinzent.

[0] From GNAT User's Guide:
-m
Specifies that the minimum necessary amount of recompilations be
performed. In this mode gnatmake ignores time stamp differences when
the only modifications to a source file consist in adding/removing
comments, empty lines, spaces or tabs. [...]

Re: Crosspost: Help wanted from comp.compilers

[Hyman Rosen]

Vinzent Hoefler wrote:
> |C:\prj\elan520>\djgpp\bin\touch elan520-sdram_buffer_control.ads

Even more apropos of what I'm talking about would be to touch
the object file (if there is one for just the .ads file). I'm
OK with using source file timestamps as a proxy for considering
them changed, even though GNAT can do better, as you say below.

Re: Crosspost: Help wanted from comp.compilers

[Vinzent Hoefler]

Hyman Rosen wrote:

>Vinzent Hoefler wrote:
>> |C:\prj\elan520>\djgpp\bin\touch elan520-sdram_buffer_control.ads
>
>Even more apropos of what I'm talking about would be to touch
>the object file (if there is one for just the .ads file).

Well, there is one.

Insert same procedure like in my previous posting as appropriate:

|C:\prj\elan520>\djgpp\bin\touch sdram_buffer_control.o
|
|C:\prj\elan520>gnatmake -m elan520
|
|C:\prj\elan520>gnatmake elan520

Surprise, surprise. ;) In this case it even doesn't recompile anything
at all (in both modii).

Just for completeness, try the .ali, too:

|C:\prj\elan520>\djgpp\bin\touch sdram_buffer_control.ali
|
|C:\prj\elan520>gnatmake -m elan520
|
|C:\prj\elan520>gnatmake elan520

Again, nothing happens.

Well, there's no executable to link yet; so to be clear about that
point, even if I *delete* .o and .ali, gnat does *not* try to
recompile.


Vinzent.