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 14:35:19 GMT From: ddciiny!jls@uunet.uu.net (Jonathan Schilling) Subject: Re: Query about monitor (passive) task optimization Message-ID: List-Id: In article <1993Aug2.064113.938@celsiustech.se> bjkae@celsiustech.se (Bjorn Kal lberg) writes: >In article jls@ddciiny.UUCP (Jonathan >Schilling) writes: > >>I've heard of these objections before, but I don't fully understand them. >>Assuming the optimization is transparent to the programmer, and does not >>in any way change the semantics of the program, what "control" is being >>lost? > >I thought a Real Time program was a program, where timing was an essential >part of the semantics. Thus, semantics is changed. > >>>From within the program, using only standard Ada, one wouldn't >>even be able to detect whether the optimization had happened or not >>(this might be doable with CIFO-type interfaces, depending on the >>runtime system implementation). The only difference is that the program >>runs faster. > >Or suddenly slower, when you change the program in some little way, so >the compiler can not apply the optimization any longer, that it previously did . >And you do not get a warning or error, which you will if you have explicitly >told the compiler, that this must be a passive task. 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. 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. 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. -- Jonathan Schilling DDC-I, Inc. uunet!ddciiny!jls