Questions, concerns about ANDF

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]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.