From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 27 Aug 93 10:07:51 GMT From: lab.ultra.nyu.edu!kenner@nyu.edu (Richard Kenner) Subject: Re: GNAT on NT anybody Message-ID: <25kmdn$16u@cmcl2.NYU.EDU> List-Id: 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.