Re: Questions, concerns about ANDF

Hello Everyone:


I am writing this in response to Article [117] from Dick Dunn. First of all
I want to thank Dick and all the others who have expressed their views so
far on ANDF and I'd like to encourage everyone to continue to discuss any
issues (positive AND negative!) related to ANDF. It is extremely important
to have an open process and the more feedback we get, the higher are the
chances of converging on the best possible approach to the problem that we
are trying to solve!


Here are my responses to Dick's concerns and I'd like to qualify my responses
by mentioning that I reserve the right to change my views based on the
technologies that we are about to receive in response to the RFT.


1: UNCOL versus ANDF:


ONE of the three approaches to ANDF , viz. compiler intermediate format is
conceptually similar to UNCOL. Perhaps the biggest difference between
UNCOL and this (1/3)rd of ANDF is not in concept but in timing in the history
of computing. Computer Science has a come a long way since the UNCOL times
in the area of architecture-neutrality.


New and powerful phenomena like UNIX and C were non-existent then. Besides
many many computer vendors have their proprietary compiler technology based
on a common intermediate language for several languages. (I'd rather not
mention any names, but talk to someone who has worked in compiler development
in several computer companies.) So a common intermediate language for multiple
languages and machines is hardly "a quest for holy grail", but pretty much
a de-facto standard for building compilers today in proprietary architectures.
(Whether or not it is a good idea is a different story and perhaps not
without controversy!)


2: portability versus architecture-neutral


The distinction between the two is very real and it is very important to
understand it. ANDF will be an architecture-neutral program representation
and it is not the same as an architectural-neutral program! You can have
programs which are not architectural neutral expressed in an ANDF
representation! ANDF would be irrelevant without an emphasis on portability
during software development. And this emphasis has grown stronger since
UNCOL times.


3: Can ANDF be an "encrypted source"?


I reserve my judgement on the issue until I see the technologies
submitted to us.


4. A "paper solution" for a couple more architectures:


Good suggestion. Extensibility is a mandatory requirement that will be
given a lot of attention in the evaluation process.


5. Extensibility to languages


Same as (4).


6. Building Hardware atuned to ANDF:


I would be interested in hearing what people think about the validity of the
conjecture as well as the implications.


7. National Language Support:


One way an ANDF proposal might have difficulty in supporting National
Languages might be an assumption in the design that characters can
be 8-bits and only 8-bits wide, for example.


Thanks again!
[From sri@osf.osf.org (Sri Vasudevan)]
--

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