From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 2 Aug 93 18:17:50 GMT
From: seas.gwu.edu!mfeldman@uunet.uu.net  (Michael Feldman)
Subject: Re: Query about monitor (passive) task optimization
Message-ID: <1993Aug2.181750.19343@seas.gwu.edu>
List-Id: <comp.lang.ada>

In article <CB4z6w.863@ddciiny.UUCP> jls@ddciiny.UUCP (Jonathan Schilling) writ
es:

[stuff deleted]
>
>These are valid points, but they extend to virtually every language feature
>in Ada, not just synchronization tasks.  For instance, changing one of the
>bounds of an array type declaration from a static to a dynamic value could 
>well result in *much* more code being generated for object declarations and
>operations of that type.  Yet most compilers that I know of will not issue 
>a warning when this happens, nor have a pragma to explicitly "control" it.

Once your customers read this, you may indeed get a bunch of requests to
implement it. After all, it's another way to second-guess the compiler. :-)
>
>The essence of compiler optimization in Ada is recognizing simple instances
>of potentially complex constructs, and generating only the code appropriate
>for the simple case.  This goes on all the time in Ada, with array types,
>record types, discriminants, slices, type conversions, tasks, representation
>clauses, and so on.  While compiler user documentation may attempt to outline
>what construct usages the compiler will see as "simple", the coverage is
>rarely complete.  Users often stumble across minor source changes that
>produce significant differences in object efficiency, for reasons that are
>understandable to the compiler writers but less so to anyone else.

And this will ALWAYS be true of high-level languages and optimization.
If you've gotta control every bit, write it in assembler. If you're
writing it in a HLL, these things will bite you now and then. Yep.
That's life.
>
>Unless someone wants to change Ada, or create another real-time language,
>such that the language specification itself imposes execution-time
>efficiency requirements on every construct in the language (has anyone 
>ever tried this?), I'm not convinced of the usefulness of giving special
>treatment to the monitor task optimization.

Exactly!

Mike Feldman