Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!labrea!decwrl!decvax!ima!compilers-sender From: rcd@ico.ISC.com (Dick Dunn) Newsgroups: comp.compilers Subject: Questions, concerns about ANDF Message-ID: <3850@ima.ima.isc.com> Date: 5 May 89 21:36:16 GMT Sender: compilers-sender@ima.ima.isc.com Reply-To: Dick Dunn Lines: 134 Approved: compilers@ima.UUCP I'd like to see some discussion about the idea of ANDF. I've got some questions and concerns to try to get it going. Naturally, I hope Doug Hartman (or some other representative of OSF) will respond, but it would also be interesting to see what other folks think. Try these for starters: =>1. When I first skimmed the RFT, I had this uneasy feeling that it sounded an awful lot like UNCOL. I doubt that I'm alone in this reaction. I assume that OSF is familiar with the history of UNCOL attempts...so the first question is "How is the ANDF concept qualitatively different from the UNCOL concept?" =>2. The RFT states the intention that... > Hardware vendors can: >... - rely on the availability of a rich applications base for new > technologies. This seems to imply that OSF believes ANDF will allow a program to be run on new hardware on which it has not been tested or ported. I think our general experience with moving software around in the UNIX world is that it *is* often possible to write programs in a way that allows them to be moved to new machines--for which they have not been tested--and have them work. However, what is "possible" and what actually happens in the real world are rather different here. Many programs have sensitivities to particular architectural features--sometimes blatant, sometimes quite subtle. One must be careful about confusing "architecture-neutral" with "portable", yet there is a strong connection between them. Next, I submit that the source form of a program, whatever its quality might be, is at the upper bound of portability and architecture-neutrality for the program. That is, a translation step, such as moving from source to ANDF, cannot decrease the program's architecture sensitivity. (If a translation could remove architecture-sensitivity, then either the trans- lation somehow violates or substantively alters the semantics of the pro- gram, or the architecture-sensitivity wasn't really there in the first place.) The implication from this line of reasoning is that programs distributed in ANDF will be subject to at least as many problems of non- portability as are existing programs which are distributed in source form. Granted, one can detect certain types of architecture-sensitivity during translation, but by no means is all of it detectable. So here, "Is my understanding of the implication correct, that an existing program in ANDF is expected to be able to run on new hardware?" =>3. With regard to characteristics of a solution, the RFT suggests: > 1. A specification for providing architecture-neutral software > distribution. Possible examples include specification of an > intermediate compiler format, encrypted source, or tagged ^^^^^^^^^ ^^^^^^ I don't understand how this would meet the criteria. If the format were encrypted source, an ANDF compiler system would have to contain the decryption algorithm. Wide availability of ANDF compilers would make it highly likely that a "decrypter" could be constructed and surreptitiously passed around. With regard to the goal of protecting the original source, then, "Is it not the case that the translation from source to ANDF *must not* be an infor- mation-preserving transformation?" =>4. Regarding the requirements for ANDF: > Multiple architectures > Support for at least two distinct machine architectures must be > demonstrated... >...The technology must be extensible...to additional hardware > architectures... I can understand that OSF might not want to require support for many machine architectures, simply because this would place such a large burden on the groups developing technology, to develop multiple back ends as part of the submission. However, experience in this area of portability has shown that techniques which appear promising, and which work well for a few machines, frequently either fail or collapse of their own weight when extended to a larger number of machines. This places a heavy burden on OSF, to evaluate ANDF candidates for their extensibility to all machines of potential interest. I think they could have made their jobs easier by requiring demonstration for two architec- tures and a "paper solution" for a couple more. =>5. The same concern applies on the "front end" requirement: > Languages > The mechanism must support applications written in ANSI C... >...The technology must be extensible...to additional programming languages. "UNCOL-style" work in programming languages has probably failed more often due to the diversity of programming languages, than due to the diversity of machine architectures. I can't imagine how OSF is going to be able to evaluate a submission for extensibility to additional languages based on support for a single language. It would have been helpful to have some set of additional languages against which submissions could be evaluated. I would think that extensibility to at least FORTRAN, COBOL, Pascal (or a derivative), and Ada would be necessary. =>6. A colleague of mine offered a conjecture: ANDF will not remain architecture-neutral. If ANDF is, as seems likely, an intermediate trans- lation format, there could be serious commercial advantage to building hardware which is attuned to the characteristics of ANDF. It's an interesting conjecture. The implications are far-reaching, and not necessarily good. Comments? =>7. One small matter I didn't understand: > National Language Support > Implementations must be capable of supporting a broad range of > national languages, including at least European, Semitic, and Asian > languages. It was not clear to me how the ANDF would influence, nor be influenced by, the choice of national language. Is this simply a piece of "boilerplate" which is always stated for safety (even if compliance is trivial)? Or is there some anticipated problem--some way in which an ANDF might fail to admit variation in national language? --- Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 ...Relax...don't worry...have a homebrew. [The moment I saw reports of the ANDF RFT it immediately impressed me as yet another chapter in the quest for the UNCOL holy grail. The fact that they even put out the RFT suggests that (optimist) they know somebody who has made a major breakthrough and has actually got such a thing or (pessimist) they know somebody who thinks he's done it but will find like all previous attempts at UNCOL that it's real hard, on a par with, say, automated translation of poetry from English into Chinese. But I suppose as moderator I should try to avoid being too opinionated. -John] -- Send compilers articles to compilers@ima.isc.com or, perhaps, Levine@YALE.EDU Plausible paths are { decvax | harvard | yale | bbn}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request