Re: GNAT 3.01 Source For OS/2

[jschafer1@iquest.net]

On 27 Apl 1996 12:19:57 -0400 dewar@cs.nyu.edu (Robert Dewar) wrote:

> If you are having trouble duplicating this build, most likely you are
> just not doing the build the same way we are. For instance, our stndard
> options for compiling the compiler are -gnatap (assertions on, range
> checking off). We turn range checking off because it is our experience
> that with assertions on, the range checking does not find additional
> real errors, but has been known to cause problems (as appears to be
> the case in your build). Of course the case you found should be fixed,
> but as you have undoubtedly found out, the issue here is one of choosing
> right subtypes, not a functoinality issue, i.e. the 3.03 compiler behaves
> fine as we build it in this respect. It is possible that some of your
> other problems with the build come from similar cases, or not. Hard
> to say without more details.

  I won't even go into the STUPIDITY of building with range checks off.  What
I WILL ask is: "So how did ACT programmers get so God-like that they have
deemed that a MAJOR feature of Ada just gets in the way so it won't get used" ??
By any chance did your staff learn Ada as a second language after learning
high level assember (i.e. C or C++) ????  ACT is the first group I have ever
seen in the Ada community that ballsy enough to admit that thier code worked
with range checkes off and failed with them turned on !!!!!

  But to hit the nail on the head, explain why your Makefile in the 3.03 source
is setup to use "-gnata -gnatg" ????   Was the "-gnatap" some secret that an
ass like me needs to beat out of you ????  It does explain a few things
however.

  Now I guess the emphisis must shift to tring to convince you that the code
should compile and work correctly reguardless of the settings for the
range checking.  Normally for most Ada people, this means that when you
turn off range checks, the code still works.  The argument I may need to
pursue is the converse argument: When the checks are turned ON the code
should continue to work too.

  The only possible argument for REQUIRING range checks off is due to dweeb
coders who make fundamental mistakes like using Constraint checks to see if
a value is in range or not.  You can eliminate this problem by removing range
checking.  But it's a rather drastic thing to do when a little coder training
would be MUCH more cost effective.

> The OS/2 compiler does get completely built at least once a day. The
> problem in getting releases out is packaging and testing. In the future,
> we are going to release the OS/2 directly from my working version, which
> should make it easier to get OS/2 releases out. Before we were rebuilding
> a referene version on another machine for the release, and this is teh
> step that was taking time, and not getting done due to its low priority.
> The disadvantage of this approach is that we are less likely to track
> changes in EMX, since there is no point for me to update EMX versions
> if my development version is working fine. Of course if some volunteer
> can help with putting things together with the latest EMX, we would
> be more than happy to work with them.

  Try installing EMX09b's minimum set.  Then install GNAT 3.01 but be carefull
NOT to overwrite the gcc.exe executable or the gcc.a file.  The ones in the
GNAT 3.01 executables for OS/2 are specific to EMX09a.  And luckily, Eberhard
Mattes is kind enough to provide a gcc.exe in EMX09b that supports GNAT.  After
you build the 3.03 version, you MAY want to use the newly created gcc.exe
however.

   About the only other problem you will run into is building the GCC parts of
the compiler.  I started with the original GCC 2.7.2 source and Binutils from
MIT and your 3.03 source.  Then by applying the EMX patches to the sources
I was easily able to build the GCC compiler to get the .o files needed for the
backend of GNAT.  Building GAS was nearly effortless.

  I excluded the bounds checking for C but that could be added easily.  All
GNAT would need was an extra .o file or two when building gnat1.

  The only outstanding problem with EMX has to do with a resource locking 
problem.  It doesn't stop the compiler from working it just stops the user
from running two copies of the same physical executable at the same time.  I
will be researching this as time allows, but it is not a real problem on
a single user system like OS/2.

   I am beginning work on testing an optimized version of GNAT 3.03.  Earlier
tests has problems.  We'll see what happens.  I'll let you know what I run
into.

   What do you need to move up to EMX09b?  I currently have 3.03 working on
OS/2 Warp with EMX09b.  Of course, you haven't convinced me that the subtype
declaration issue is resolved, so my version does NOT eat as much memory as
a standard GNAT 3.03.  I don't see anything broken because the extra subtype
declarations are not there.

   I could sure use an explanation that defines specifically why these subtype
declarations are needed.  And of course, as always, at the title of the
thread states, "A copy of the 3.01 source would be REALLY nice".

Joe Schafer
jschafer@iquest.net