Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[Stephen Leake <Stephen.Leake@gsfc.nasa.gov>]

Robert Dewar wrote:
> 
> Stephe said
>
> <<Even if you are not replacing gcc for real processors now, maybe you
>   could try to make it possible to eventually use this backend as a
>   replacement for part of gcc (talk about vague requirements!). We need to
>   get away from K&R in the core of our compilers sometime!>>
> 
> It is obvious from this that you know very little about gcc, so while you
> are reading up on JVM, read up on GCC too. The GCC backend has nothing to
> do with C or K&R per se, it is a code generator that can take input from
> multiple front ends (one is the GNU C compiler, one is GNAT, there are
> several others), and generate output for a very large variety of
> architectures.

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. 

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.

> 
> Basically if you want GCC to generate code for a new target, you just write
> a formal definition of the instruction set for that architecture, called
> a machine configuration file, and everything else is automatic. Writing
> these configuration files is quite a straightforward task once you are
> familiar with the technical approach.

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.

-- 
- Stephe