billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) (12/20/89)
From stt@inmet.inmet.com: > preprocessors create no optimization problem, > since they operate at the lexical, or possibly syntactic, level, > long before the optimizer takes a look at the program. Are you sure that this is true in the general case? (Not just for current compiler products, but in the general case?) If a preprocessor takes a high-level construct and reduces it to a series of lower-level constructs, then isn't there a certain loss of exploitable semantic content? Perhaps many present optimizers are not engaging in this level of sophistication, but analytically speaking, the most heavy-duty of optimizing compilers would squeeze the final drops from every single bit of semantic knowledge available to it, using semantics to develop sophisticated reasoning leading to proofs that certain optimizations can be safely performed. If something like Anna/TSL were incorporated into Ada, and the preprocessor were to preserve all the semantic information during transformation (inserting annotations to restore the semantics lost during preprocessing), then under those conditions the actions of a preprocessor would probably not incur any penalty. But if this is not the case, then it would seem, at least theoretically, that there would be considerable losses in the potential for optimization. Bill Wolfe, wtwolfe@hubcap.clemson.edu
stt@inmet.inmet.com (12/22/89)
Regarding preprocessors, optimization, and standardization: I was talking about preprocessors in the "C Preprocessor" vein. E.g., defines, ifdefs, etc. I am sorry if I gave the impression I was talking about a preprocessor like C++ 2.0. Such a "preprocessor" is really a full compiler which happens to emit C rather than object code. For the C++ kind of "preprocessor," you are absolutely right that optimization of the output can be more difficult. I also presume that Dave Emery's proposal for Ada was oriented toward the conditional compilation type of preprocessor. Frankly, I had personally written off the concept of a standard preprocessor for Ada. However, seeing the interest in Dave's proposal, it seems worth considering again. As a compiler implementor, I hated the old "pragma Include" because it made automatic recompilation a different kind of problem. As it is now, it is possible to recompile from parse trees. With "pragma Include," that was effectively impossible. However, I *can* imagine a careful definition of conditional compilation mechanisms which would preserve the ability to recompile from parse trees. This would *not* be a preprocessor approach, however. Instead, it would mean creating new syntax. Here is a quick proposal: Allow if constructs and case constructs within a sequence of declarations, so long as all conditional and case expressions are static, and each if/case "arm" contains only declarations (rather than statements). Note that variant records already use the case construct at the end of a list of declarations. This proposal would simply generalize this a bit (?), and allow the case expression to be an arbitrary static expression as well as the currently-legal discriminant. Furthermore, identifiers *could* be reused in mutually exclusive if/case arms, since this would not interfere with compile-time type checking. One could even imagine allowing if/case constructs in context clauses, to do conditional "with"ing. The nice thing about this kind of approach is that it builds on the existing concepts of the language (namely static expressions, if/case constructs, and variant records), rather than introducing a new/foreign syntax like "#ifdef". It is interesting to compare the situation in Ada with that in C++. Now that C++ has the concepts of inlines and "consts" the need for preprocessors is reduced for C++, though apparently not eliminated (for the same reasons that Dave is providing for Ada). It seems like it might be a better solution in the C++ arena to also start allowing conditional constructs among declarations, and strip them out as part of generating C (presuming that the C++ "compiler" already has to be able to evaluate static expressions). Here is an example demonstrating this proposal (though I admit this example could probably be done better using other methods): with Parameters; package Fum is case Parameters.Target is when Parameters.VAX => type Target_Double is digits 11; when Parameters.S370 => type Target_Double is digits 14; when others => type Target_Double is digits 15; end case; . . . end Fum; Probably an important additional requirement would be that the arms of an if/case construct which are not chosen should not be required to be semantically correct (though they would still require syntactic correctness). This should apply whether the if/case construct is acting as a declaration or a statement. This would allow reference in such unselected arms to declarations which were similarly unselected. This also has the net effect of mandating conditional compilation, rather than leaving it as an optional "optimization." And while we're at it..., AI-00128 which disallows use of short-circuit control forms in static expressions should probably be revisited. ----------------------- S. Tucker Taft uunet!inmet!stt; taft@ajpo.sei.cmu.edu Intermetrics, Inc. Cambridge, MA 02138