Re: GNAT on NT anybody

[lab.ultra.nyu.edu!kenner@nyu.edu (Richard Kenner)]

In article <1993Aug27.024824.21373@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael
 Feldman) writes:
>This question makes me wonder if anyone has yet tried to _port_ GNAT.
>It's an interesting process, because GNAT is written in Ada, not C.
>One could bootstrap it by using a commercial Ada compiler - NYU first
>compiled GNAT with Alsys. This process was documented in an NYU post
>a while ago. 

In fact, you can't do this for any of the versions we've distributed,
only the very early systems we had.  Now the `gnat1' executable is
mixed-language, containing the C code of the GCC backend and the Ada
code for the Ada front-end.  In fact, just recently we changed things
so the backend (in C) calls Ada code for some tree-processing
functions rather than providing duplicate C functions.

Since no commercial compiler provides such a seamless integration
between languages, GNAT can only be compiled with itself at this point.

>But that's no fun - it requires a commercial compiler. An all-GNU
>approach is to use the gcc cross-compilation facilities. If a GNU
>SPARC-to-Sun3 cross exists (just to take one example), then one compiles
>GNAT on the SPARC, takes the assembly language output to the Sun-3
>and re-assembles. It is alleged to be fairly easy if you're an
>experienced gcc hand.

That's right.  In fact there are two approaches.  You can build a full
cross-system, including GNAT (and GCC) along with a cross-assembler
and linker (e.g., GAS and GLD).  Brett Porter, one of the folks on the
GNAT project, recently did this to be able to run Ada code an
evaluation board containing some variant of the 68k (actually, he was
originally interested, I believe, in C code, but built a cross-GNAT to
see if it would work and it did).

This approach is quite straightforward and almost automatic.

If you don't want to bother with a cross-assembler and linker, you can
do as Mike suggests and just produce the assembler files with a
cross-GCC, then take them to the target and assemble them there.  It's
straightforward, but involves some manual steps.  I did this for the
RS/6000 a few weeks ago and will shortly need to do it for DEC's
MIPS-based workstations, since that's what will be at Tri-Ada.

>Indeed, I believe NYU is using only GNAT to compile new versions, 
>using Alsys only for "occasional sanity checks" as I think one of the 
>NYU guys put it.

That's very close to correct.  I don't believe that the folks here who
use Sparcs use Alsys anymore.  Robert Dewar, though, uses a PC and
still does most of his work with Alsys since the OS/2 version of GNAT
has been lagging a bit.

>If there are any gcc cross-compilatiuon gurus out there
>with a little time to tinker, I think it would be fun to start some
>porting, so when the final version pops out, it will instantly be
>available on a bunch of platforms. 

I don't think there's much point in doing this work.  For one thing,
it's fairly straightforward to do it on each target individually.  But
the major issue is that doing it now for a target won't mean that it
won't have to be redone later.  If you make a binary for some target
right now, that does NOT mean that that binary will necessarily be
useful later.  It is not at all uncommon for some code we've written
in GNAT to hit a bug or unsupported feature in a previous GNAT
version.  When that happens, the binaries will be useless for
compiling later versions and the cross-work will need to be redone.

It it our plan to not require a binary to build GNAT, merely a C
compiler.  Most of the Ada code is at a fairly low level and fairly
regular.  We intend to provide an Ada-to-C translator for the subset
of Ada used in most of GNAT.  For some of the other Ada modules, such
as error handling, we'll provide C code that will link, but not do
much (i.e., abort when asked to print an error, since there won't be
any compiling GNAT).  This will allow a bootstrap path.

Collecting executables for all systems on which GNAT will work is not
practical.  I just counted and found that GCC (and hence GNAT) has
configuration files for 188 different systems, most of which are not
binary-compatible with each other.  It's true that many of these
systems don't exist anymore or are only of extremely narrow interest,
but there are still probably dozens of distinct configurations that
are current.  Having so many binaries doesn't seem practical.

Unfortunately, what started this discussion was Windows NT.  There are
no ports of GCC to any Windows NT configuration.  It was not clear
which one was of interest to the original poster.  I will be doing a
GCC port to the DEC Alpha version of NT as soon as DEC can get such a
machine to me.  A port to NT on a PowerPC should also not be very far
away, since we're starting to do the modifications to the RS/6000
configuration files to support the various Motorola chips that are
implementations of the PowerPC architecture.

As far as I know, no one is working on a GCC port to Windows NT on an
x86.  The x86 work lately seems to be concentrating on the various
dialects of OSF/1 (Rose and Elf).  I don't recall seeing any requests
for a x86 NT port of GCC on the GCC mailing lists; most requests
lately seem to be for the various embedded processors.

If someone wants to do a GCC port to the x86 Windows NT, it would be
appreciated and GNAT would fall out for free.  Unlike porting to a new
architecture, which requires a lot of knowlege about GCC, porting to a
new system on a supported architecture merely requires (intimate)
knowlege of the target operating system and is usually just a matter
of setting appropriate configuration macros.  The only time that it
can get tricky is if none of the standard object file formats (a.out,
COFF and it's variants, Rose, or ELF) are used and there is also a
problem with using the system's assembler.  I do not know if NT has
these problems, but we've been running into them on OS/2.