Re: Query about monitor (passive) task optimization

[seas.gwu.edu!mfeldman@uunet.uu.net (Michael Feldman)]

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