From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_MSGID,
	SUBJ_ALL_CAPS autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,9e20292f693f1408
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM
Date: 1997/09/18
Message-ID: <dewar.874622854@merv>#1/1
X-Deja-AN: 273649384
References: <dewar.873998738@merv> <34196E8E.1790@gsfc.nasa.gov>
 <dewar.874165896@merv> <341D47EE.3804@gsfc.nasa.gov> <dewar.874439071@merv>
 <342002F1.6913@gsfc.nasa.gov>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-09-18T00:00:00+00:00
List-Id: <comp.lang.ada>


Stephe says

<<I guess I wasn't clear. I do understand that gcc meets my needs; in
fact, I am using it. I've ported the gcc backend to generate assembler
code for the UT69R000 microprocessor. What I meant by getting away from
K&R is that the gcc _source_ is _written_ in K&R style C; for example,
functions are often not declared before they are used (at least in the
user configuration files I was editing). This has bitten me several
times. I tried to include the headers that defined the functions that I
was using, but could not figure out an include order that worked; some
macro or other was always left undefined. I understand that this style
was necessary when gcc was started; K&R compilers were the only
compilers available. And it is precisely this style, together with a
liberal use of preprocessing, that makes gcc operate on so many hosts.>>

  The people who know and maintain this code can read it FAR more easily
  than they could read Ada code. Familiarity is worth a big factor more
  than objective language differences. Yes, if you are an Ada programmer,
  you will have a hard time reading the code, just as the GCC folk have
  a hard time reading the GNAT front end (even though most people consider
  this to be very clearly written code).

<<I understand that there is a _HUGE_ amount of work in truly replacing
the current gcc with an equivalent Ada 95 implementation. I am sure ACT
cannot afford that on its own; that is why I was surprised to hear that
the JVM implementation was not using gcc. Now I have an inkling of why;
the JVM is not similar to a typical processor.>>

  ACT would not think of embarking on such a counter-productive task. Hundreds
  of people contribute to the development, improvement, and maintenance of
  the existing gcc backend, and even if one did waste resources translating
  the backend of gcc into Ada 95, you would just create a dead end branch, 
  that almost no one would pay any attention to. I cannot imagine a less
  worth while expenditure of time.

<<Almost. You have to write some C glue to transform some RTL instructions
that are not directly available in the target architecture (in my case,
I had to simulate indirect addressing). There was enough C involved to
make me wish it was Ada. In addition, when I left stuff out, or just got
it wrong, the only way I could figure out what was missing was reading
the gcc source. It is well commented, and usually well structured, but
it is not Ada 95.>>

  Well no doubt Eiffel programmers would prefer it in Eiffel, Smalltalk 
  programmers would prefer it in Smalltalk, etc, but that is not a reason
  to do any of these translations.

It never makes sense to me to translate code in language A to language B just
for the sake of having the code in language B. Some very silly projects in the
past have done just that where language B was Ada, and it is one of the things
that have unfortunately convinced some people that Ada does not make sense if
it causes such activities to be undertaken.

By the way, if you do a bit of homework and learn JVM, you will see that
the task of generating JVM is not even remotely like the job of generating
machine language. JVM is much closer to Java in semantic level than it is
to machine language. People often think that it would make sense to somehow
have JVM as a target for GCC, but if they think that then they have serious
misconceptions about the GCC backend, or JVM, or both!