floating point problem

floating point problem

[bill]

hi again, 
if you read my last post then you know i am 
very new to gnats ada95 compiler.  I installed it last night
and after overcoming some stupidly simple problems i think i have actually
encountered a "real" problem as far as these things go..

in testing simple programs using things like ada.float_text_io and 
ada.integer_text_io i have been unable to compile anything that uses floating 
point values.


I don't understand the error that occurs except to say that my screen is 
spammed to death by comments that say something like..


c:\usr\local\lib\gcc-lib\i386-pc-cygwin32\2.7.2\gnat1.exe frame 15 : sp = 
0x276f360, pc = 0x5bc5b4
end of stack trace,  more stack frames may be present.


the code i used to produce this fault was

with ada.float_text_io;
procedure floattest is
x: float;
begin
x := 3.2 + 4.8;
ada.float_text_io.put (x);
end floattest;

obviously very simple so anyone have any ideas why i can't use the floating 
point?

does it matter that my system is only a 486sx2/66 ?

thanks in advance.
bill rawlinson

   ___                ___            
  (/__) .  /) /)     (/__)    http://webpages.marshall.edu/~rawlins2                          
  /__) (__(__(___    /\    __          /) .     _    _              
 (                  (  \  (_/(_(_(_(__(__(_/\/_/_)__(_)_/\/______   

Re: floating point problem

[Corbin Dunn]

it should work....

On Wed, 26 Feb 97 04:52:24 GMT, rawlins2@marshall.edu (bill) wrote:

>hi again, 
>if you read my last post then you know i am 
>very new to gnats ada95 compiler.  I installed it last night
>and after overcoming some stupidly simple problems i think i have actually
>encountered a "real" problem as far as these things go..
>
>in testing simple programs using things like ada.float_text_io and 
>ada.integer_text_io i have been unable to compile anything that uses floating 
>point values.
>
>
>I don't understand the error that occurs except to say that my screen is 
>spammed to death by comments that say something like..
>
>
>c:\usr\local\lib\gcc-lib\i386-pc-cygwin32\2.7.2\gnat1.exe frame 15 : sp = 
>0x276f360, pc = 0x5bc5b4
>end of stack trace,  more stack frames may be present.
>
>
>the code i used to produce this fault was
>
>with ada.float_text_io;
>procedure floattest is
>x: float;
>begin
>x := 3.2 + 4.8;
>ada.float_text_io.put (x);
>end floattest;
>
>obviously very simple so anyone have any ideas why i can't use the floating 
>point?
>
>does it matter that my system is only a 486sx2/66 ?
>
>thanks in advance.
>bill rawlinson
>
>   ___                ___            
>  (/__) .  /) /)     (/__)    http://webpages.marshall.edu/~rawlins2                          
>  /__) (__(__(___    /\    __          /) .     _    _              
> (                  (  \  (_/(_(_(_(__(__(_/\/_/_)__(_)_/\/______   
>

--
corbin@cruzio.com
--
"640K ought to be enough memory for anybody"
-Bill Gates, 1981

Re: floating point problem

[tmel]

I have the same problem with GNAT3.07! I am also using a 486sx.
What I do is run the program from the command line by entering the name 
of the executable file only. DO NOT use the gexecute <filename> command, 
the program will crash.

Also remember that GNAT3.07 only recognizes the first 8 characters of 
your filename.  


TMK

corbin@cruzio.com (Corbin Dunn) wrote:
>it should work....
>
>On Wed, 26 Feb 97 04:52:24 GMT, rawlins2@marshall.edu (bill) wrote:
>
>>hi again, 
>>if you read my last post then you know i am 
>>very new to gnats ada95 compiler.  I installed it last night
>>and after overcoming some stupidly simple problems i think i have actually
>>encountered a "real" problem as far as these things go..
>>
>>in testing simple programs using things like ada.float_text_io and 
>>ada.integer_text_io i have been unable to compile anything that uses floating 
>>point values.
>>
>>
>>I don't understand the error that occurs except to say that my screen is 
>>spammed to death by comments that say something like..
>>
>>
>>c:\usr\local\lib\gcc-lib\i386-pc-cygwin32\2.7.2\gnat1.exe frame 15 : sp = 
>>0x276f360, pc = 0x5bc5b4
>>end of stack trace,  more stack frames may be present.
>>
>>
>>the code i used to produce this fault was
>>
>>with ada.float_text_io;
>>procedure floattest is
>>x: float;
>>begin
>>x := 3.2 + 4.8;
>>ada.float_text_io.put (x);
>>end floattest;
>>
>>obviously very simple so anyone have any ideas why i can't use the floating 
>>point?
>>
>>does it matter that my system is only a 486sx2/66 ?
>>
>>thanks in advance.
>>bill rawlinson
>>
>>   ___                ___            
>>  (/__) .  /) /)     (/__)    http://webpages.marshall.edu/~rawlins2                          
>>  /__) (__(__(___    /\    __          /) .     _    _              
>> (                  (  \  (_/(_(_(_(__(__(_/\/_/_)__(_)_/\/______   
>>
>
>--
>corbin@cruzio.com
>--
>"640K ought to be enough memory for anybody"
>-Bill Gates, 1981

Re: floating point problem

[Robert Dewar]

tmel said

<<tmel said

<<Also remember that GNAT3.07 only recognizes the first 8 characters of
your filename.>>

This advice is incorrect, even for systems where file names are limited
to 8 characters (where if you think about it, it makes no sense). Please
consult the GNAT documentation for rules on naming files.

This is a good reminder of a fundamental principle when using the news'
groups. You cannot tell if advice you read is written by someone who
knows what they are talking about, or by someone who has very partial
knowledge and is misinterpreting what they understand. That doesn't mean
you should ignore advice you read here, just that you should be cautious!

Re: floating point problem

[Kenneth W. Sodemann]

On Wed, 26 Feb 97 04:52:24 GMT, rawlins2@marshall.edu (bill) wrote:

[snip]
>I don't understand the error that occurs except to say that my screen is 
>spammed to death by comments that say something like..
>
>
>c:\usr\local\lib\gcc-lib\i386-pc-cygwin32\2.7.2\gnat1.exe frame 15 : sp = 
>0x276f360, pc = 0x5bc5b4
>end of stack trace,  more stack frames may be present.
>
>
>the code i used to produce this fault was
>
>with ada.float_text_io;
>procedure floattest is
>x: float;
>begin
>x := 3.2 + 4.8;
>ada.float_text_io.put (x);
>end floattest;
>

Code looks valid.

>obviously very simple so anyone have any ideas why i can't use the floating 
>point?
>
>does it matter that my system is only a 486sx2/66 ?
                                            ^^

The SX designation on a 486 means that your math co-processor (IOW,
floating point unit) is disabled.  Therefore, any program you right to
use floating point will have to use an floating point emulation
library to do the math.  Maybe GNAT has some kind of a problem with
this.  See if there is a compiler switch to turn FP emulation on/off,
and turn it on if it exists.

>thanks in advance.

Just a shot in the dark, but it is worth a try.


--
Ken Sodemann
stuffle@pcii.net
http://users.mwci.net/~stuffle

Re: floating point problem

[Robert Dewar]

Ken says

<<The SX designation on a 486 means that your math co-processor (IOW,
floating point unit) is disabled.  Therefore, any program you right to
use floating point will have to use an floating point emulation
library to do the math.  Maybe GNAT has some kind of a problem with
this.  See if there is a compiler switch to turn FP emulation on/off,
and turn it on if it exists.>>

GNAT does NOT support the x86 without coprocessor, so it will not work
on an SX unless you install a separate coprocessor.

Re: floating point problem

[Larry Kilgallen]

In article <dewar.857535729@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Ken says
> 
> <<The SX designation on a 486 means that your math co-processor (IOW,
> floating point unit) is disabled.  Therefore, any program you right to
> use floating point will have to use an floating point emulation
> library to do the math.  Maybe GNAT has some kind of a problem with
> this.  See if there is a compiler switch to turn FP emulation on/off,
> and turn it on if it exists.>>
> 
> GNAT does NOT support the x86 without coprocessor, so it will not work
> on an SX unless you install a separate coprocessor.

Is this GNAT limitation only for programs which use floating point ?

Larry Kilgallen

Re: floating point problem

[Robert Dewar]

Larry says

<<Is this GNAT limitation only for programs which use floating point>>

Yes, but you have to take into account the WHOLE program, including
bodies of library units. For example, fixed_io uses floating-point.

Re: floating point problem

[Larry Kilgallen]

In article <dewar.857586895@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Larry says
> 
> <<Is this GNAT limitation only for programs which use floating point>>
> 
> Yes, but you have to take into account the WHOLE program, including
> bodies of library units. For example, fixed_io uses floating-point.

Are other such examples which might not be obvious documented,
or would one have to study the compiler source ?

Re: floating point problem

[Robert Dewar]

Larry says

<<> Larry says
>
> <<Is this GNAT limitation only for programs which use floating point>>
>
> Yes, but you have to take into account the WHOLE program, including
> bodies of library units. For example, fixed_io uses floating-point.

Are other such examples which might not be obvious documented,
or would one have to study the compiler source ?>>


The GNAT limitation is that it only supports x86 environments in which
full floating-point support is available, either at the hardware level
or through transparent emulation. If you run GNAT on a machine without
such support, somethings will work and somethings will not work. No,
there is no documentation as to what will work, the official position
is that nothing will work. Even scanning the whole sources is not enough,
since a new version of the compiler might use floating-point where it has
not been used before!

GNAT is not suitable for supporting x86 processors with no floating-point
support. If people want to use it in such environments, they are, as far
as we are concerned, misusing it, and it is up to them to deal with any
problems that arise from such misuse.

Re: floating point problem

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>The GNAT limitation is that it only supports x86 environments in which
>full floating-point support is available, either at the hardware level
>or through transparent emulation.

Is this a limitation of the gcc backend (and hence also of GNU C, GNU C++,
GNU Fortran, etc.), or is this specific to the GNAT front-end?

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: floating point problem

[Robert Dewar]

Fergus asks

<<Is this a limitation of the gcc backend (and hence also of GNU C, GNU C++,
GNU Fortran, etc.), or is this specific to the GNAT front-end?>>

It is a fundamental limitation, and nothing to do with the front end
or the backend. All these compilers generate floating-point instructions
for floating-point operations.

These will only work correctly on machines that either have hardware
floating-point (true incidentally of essentially all currently available
x86 chips), or software systems which provide floating-point emulation.

Re: floating point problem

[Larry Kilgallen]

In article <dewar.857974200@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Fergus asks
> 
> <<Is this a limitation of the gcc backend (and hence also of GNU C, GNU C++,
> GNU Fortran, etc.), or is this specific to the GNAT front-end?>>
> 
> It is a fundamental limitation, and nothing to do with the front end
> or the backend. All these compilers generate floating-point instructions
> for floating-point operations.
> 
> These will only work correctly on machines that either have hardware
> floating-point (true incidentally of essentially all currently available
> x86 chips), or software systems which provide floating-point emulation.

So can anyone give an example for the Intel-challenged regarding how
one would easily detect this float-challenged hardware at runtime in
order to issue a nastygram ?

Larry Kilgallen

Re: floating point problem

[Robert Dewar]

Larry asks

<<So can anyone give an example for the Intel-challenged regarding how
one would easily detect this float-challenged hardware at runtime in
order to issue a nastygram ?>>

The proper code is a little delicate, but is documented in the relevant
Intel microprocessor manuals. Note that all DX chips, and of course all
Pentiums have built-in floating-point, so this is really only a concern
with ancient machines that you cannot purchase any longer.

Re: floating point problem

[Larry Kilgallen]

In article <dewar.858142750@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Larry asks
> 
> <<So can anyone give an example for the Intel-challenged regarding how
> one would easily detect this float-challenged hardware at runtime in
> order to issue a nastygram ?>>
> 
> The proper code is a little delicate, but is documented in the relevant
> Intel microprocessor manuals. Note that all DX chips, and of course all
> Pentiums have built-in floating-point, so this is really only a concern
> with ancient machines that you cannot purchase any longer.

So I would gather one cannot do this test from Ada.

As to machine models affected, my concern is that when my program is
put onto the wrong machine (regardless of any documentation I might
provide) an unambiguous message regarding the nature of the problem
is issued to the naive user.  Support calls cost money.

Larry Kilgallen

Re: floating point problem

[Robert Dewar]

Larry said

<<> The proper code is a little delicate, but is documented in the relevant
> Intel microprocessor manuals. Note that all DX chips, and of course all
> Pentiums have built-in floating-point, so this is really only a concern
> with ancient machines that you cannot purchase any longer.

So I would gather one cannot do this test from Ada.
>>

Of course you can, that is what machine insertions are for!

Re: floating point problem

[Larry Kilgallen]

In article <dewar.858314207@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Larry said
> 
> <<> The proper code is a little delicate, but is documented in the relevant
>> Intel microprocessor manuals. Note that all DX chips, and of course all
>> Pentiums have built-in floating-point, so this is really only a concern
>> with ancient machines that you cannot purchase any longer.
> 
> So I would gather one cannot do this test from Ada.
>>>
> 
> Of course you can, that is what machine insertions are for!

Well that might be "using an Ada compiler", but I would hardly
call it "from Ada".  Aside from a tools choice issue it seems
to me the same as calling an external program written in Assembler.

Of course I have called from Ada to other languages for other
purposes, but in this case (since I don't recall any test in the
RM) I was hoping some language-lawyer would say that exceptions
would surely be raised by some particular expression and thus I
could intercept the exception.  Naturally raising such exceptions
would not be a viable approach if some implementations never "got
that far".

Larry

Re: floating point problem

[Robert Dewar]

Larry said

<<Of course I have called from Ada to other languages for other
purposes, but in this case (since I don't recall any test in the
RM) I was hoping some language-lawyer would say that exceptions
would surely be raised by some particular expression and thus I
could intercept the exception.  Naturally raising such exceptions
would not be a viable approach if some implementations never "got
that far".>>

Of course you cannot look in the RM to find out what an Ada compiler should
do when it is run in a configuration which it does not support. You might as
well try loading the Ada compiler into a washing machine and adding 
detergent, and then say -- well I knew it wouldn't run perfectly, but I
thought from the RM that some exception should be raised :-)

When you run GNAT on a machine with no floating-point and no floating-point
emulation, it is not quite as bad as putting it in a washing machine, but from
a formal point of view it is the same.

Who knows what happens? I never tried it, so I don't know, but you certainly
cannot look in the RM to see what happens. Mike must know what happens, since
he complains about his from time to time!

Re: floating point problem

[Joel VanLaven]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
: Larry asks

: <<So can anyone give an example for the Intel-challenged regarding how
: one would easily detect this float-challenged hardware at runtime in
: order to issue a nastygram ?>>

: The proper code is a little delicate, but is documented in the relevant
: Intel microprocessor manuals. Note that all DX chips, and of course all
: Pentiums have built-in floating-point, so this is really only a concern
: with ancient machines that you cannot purchase any longer.

Ouch.  Actually all intel 486DX chips have a math co-processor however
386DX chips and 486SX chips do not.  I wouldn't call computers a few
years old ancient just yet. A 286 you might be justified calling ancient
but even that seems to be stretching it. Also, corret me if I am wrong
but isn't floating point support provided by software emulation on such
machines?  It may be that your problem isn't.  I'd go find a machine that
doesn't have floating point to try your program on just to be sure that
there is a problem at all.
-- 
-- Joel VanLaven

Re: floating point problem

[Robert Dewar]

Joel said

<<Ouch.  Actually all intel 486DX chips have a math co-processor however
386DX chips and 486SX chips do not.  I wouldn't call computers a few
years old ancient just yet. A 286 you might be justified calling ancient
but even that seems to be stretching it. Also, corret me if I am wrong
but isn't floating point support provided by software emulation on such
machines?  It may be that your problem isn't.  I'd go find a machine that
doesn't have floating point to try your program on just to be sure that
there is a problem at all.>>

  As I noted in my previous post, GNAT will work on any x86 which has a
  floating-point processor, or with any operating system environment that
  transparently emulates the floating-point.
  
  GNAT will definitely NOT work in some environments. In particular, the
  DOS version of GNAT on DJGPP does not work on such machines, so if you
  try the DOS version on an ancient machine without a coprocessor it
  definitely will NOT work.
  
  (as for whether a 386 is ancient at this stage, that's a matter of
  terminology, you can barely give away a 386 based machine at this
  stage!)
  
  Given that one can buy a brand new machine that can run GNAT just fine
  for a few hundred dollars these days, this has never been a priority
  (getting GNAT to work on non-coprocessor machines under DOS), and of
  course as time goes on, the utility of such an effort diminishes.

<<it maybe that your problem isn't>>

   We don't have a problem. As far as we are concerned, GNAT simply does
   not support x86 machines with no floating-point emulation, and we do
   not intend to do anything about it!
   
   If some volunteer wants to work on this problem, that would be useful to
   some people, but better work fast, or even Joel will be willing to agree
   about ancient :-)
   
   Going back to cheap PC's, if you want to run GNAT, you really need a minimum
   of a 486 with 16 megs of memory. Yes, I know you *can* run on a 386, and
   I know you *can* run in 8 megs, but these days when 16 megs of memory costs
   $79, you have to value your time very cheaply for this to be worthwhile.
   
   In general memory can make a HUGE difference in compilation speeds with
   GNAT. GNAT is NOT written to compile fast on small machines! How much
   memory you need depends on the environment. For running simple programs,
   16 meg on a PC, or 32 megs on a Unix work station is adequate, but for
   serious large programs, I would recommend double this. We recently had
   a customer complain that a compilation took 4 hours. We recommended
   adding memory (to go from 32megs to 64megs on a SPARC, costing less
   than $300 I think), and the compilation time fell to 5 minutes.

Robert Dewar
Ada Core Technologies

Re: floating point problem

[Kenneth W. Sodemann]

On 12 Mar 1997 00:00:30 -0500, dewar@merv.cs.nyu.edu (Robert Dewar)
wrote:

>Larry asks
>
><<So can anyone give an example for the Intel-challenged regarding how
>one would easily detect this float-challenged hardware at runtime in
>order to issue a nastygram ?>>
>
>The proper code is a little delicate, but is documented in the relevant
>Intel microprocessor manuals. Note that all DX chips,

Almost true.  All DX 486 chips have built in FPUs.  On the 386, the
SX/DX designation meant something else all together (external bus data
size).  You needed the 80387 co-processor for floating point.

>and of course all
>Pentiums have built-in floating-point, so this is really only a concern
>with ancient machines that you cannot purchase any longer.
>

Agreed with new machines.  However, there are tons of older 386 and
486SX machines floating around out there still being used without the
floating point unit.
--
Ken Sodemann
stuffle@pcii.net
http://users.mwci.net/~stuffle

Re: floating point problem

[Robert Dewar]

<<Agreed with new machines.  However, there are tons of older 386 and
486SX machines floating around out there still being used without the
floating point unit.>>

Sure there are tons of such machines, but for serious development work,
which is what GNAT is intended for, it is silly to use an ancient 386
or 486SX when for under $600 you can get a brand new machine that will
do the job so much better. (look around, you will find many good deals
on new PC's that are under the power curve -- I bought a 50MHz DX2 486
with 2X CD ROM, 8 megs memory, lots of junk installed software, a few
months ago (actually probably a year ago now) for $399, you can do
better today.

The people most affected are those with old notebooks with 486 SX
processors. GNAT and DOS and such machines do not mix if you want to
do floating-point. Mike Feldman has often complained about this (but
has not fixed it :-)

As has been pointed out, moving to other operating systems which provide
proper emulation of the fpt chip is one answer.

It probably would not be that hard to rig up something that worked on DOS,
it's just not on our radar screen of worthwhile things to spend time on (a
list tha has plenty of entries).

I think this is a problem that will rapidly go away. I polled the entire
incoming CS class last semester, nobody had anything like that primitive
a machine (many of them had machines that would attract anyone's hardware
envy :-)

Re: floating point problem

[Larry Kilgallen]

In article <dewar.858438733@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> <<Agreed with new machines.  However, there are tons of older 386 and
> 486SX machines floating around out there still being used without the
> floating point unit.>>
> 
> Sure there are tons of such machines, but for serious development work,
> which is what GNAT is intended for, it is silly to use an ancient 386

That is too bad.  I had hoped GNAT might be useful for deployment.
Just to make sure we are on the same wavelength, my concern is
entirely with what happens at runtime with generated programs.
For running the compiler I can buy (actually already have) some
appropriate machines.

> or 486SX when for under $600 you can get a brand new machine that will
> do the job so much better. (look around, you will find many good deals
> on new PC's that are under the power curve -- I bought a 50MHz DX2 486
> with 2X CD ROM, 8 megs memory, lots of junk installed software, a few
> months ago (actually probably a year ago now) for $399, you can do
> better today.

But it is really tough to sell software to people if you tell them they
have to spend 40x the software price to buy a new computer.

Larry Kilgallen

Re: floating point problem

[Geert Bosch]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
 ``GNAT does NOT support the x86 without coprocessor, so it will not work
   on an SX unless you install a separate coprocessor.''

Why do you think the OS/2 version of GNAT doesn't work on a x86 system
without co-processor? 

Correct me if I'm wrong, but the OS/2 version of GNAT should just
work fine on any 80x86 with x >= 3, since OS/2 emulates the co-processor
if it is not present. 

Regards,
   Geert
-- 
--  E-Mail: geert@sun3.iaf.nl    
--    `` If trainstations are places where trains stop, 
--	 then what are workstations? ''

Re: floating point problem

[Fergus Henderson]

geert@fozzie.sun3.iaf.nl (Geert Bosch) writes:

>Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
> ``GNAT does NOT support the x86 without coprocessor, so it will not work
>   on an SX unless you install a separate coprocessor.''
>
>Why do you think the OS/2 version of GNAT doesn't work on a x86 system
>without co-processor? 
>
>Correct me if I'm wrong, but the OS/2 version of GNAT should just
>work fine on any 80x86 with x >= 3, since OS/2 emulates the co-processor
>if it is not present. 

Same for Linux too, I believe.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: floating point problem

[Scott Ingram]

Fergus Henderson wrote:
> 
> >Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
> > ``GNAT does NOT support the x86 without coprocessor, so it will not work
> >   on an SX unless you install a separate coprocessor.''

> Same for Linux too, I believe.
> 
Thanks Fergus.  I was just on the verge of running home to tell
my machine to stop doing all that GNAT stuff that it can't do :-)

--
Scott Ingram
Hunting submarines in a Maryland meadow...

Re: floating point problem

[Robert Dewar]

Geert says

<<Why do you think the OS/2 version of GNAT doesn't work on a x86 system
without co-processor?
>>

Indeed,, that's probably right, though I never tried it (I must say the
thought of running OS/2 on 386SX is pretty gruesome, I like OS/2, but
I consider a top of the line Pentium to be minimal acceptable computing
power to support it :-)

Re: floating point problem

[Tom Moran]

> Several years ago for a procurement, we
> went looking for Ada (83) compilers that could be validated on PCs
> without an FPU.
  How many years ago was that?  I used the validated Janus Ada 83
compiler compiling on a 286 and generating code for an 8088, both
without FPU.  That was at least several years ago.

Re: floating point problem

[Robert I. Eachus]

   Robert Dewar said:

   > Sure there are tons of such machines, but for serious development work,
   > which is what GNAT is intended for, it is silly to use an ancient 386

In article <1997Mar16.113256.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:

   > That is too bad.  I had hoped GNAT might be useful for deployment.
   > Just to make sure we are on the same wavelength, my concern is
   > entirely with what happens at runtime with generated programs.
   > For running the compiler I can buy (actually already have) some
   > appropriate machines.

   Ah, I see the confusion.  If you want programs that will run on
"any" PC, you need to avoid the use of floating point in your
programs.  (And to test on a 386 with no FPU, just to check.)  The
GNAT compiler itself uses floating point, in some cases even when your
program doesn't, so you need to develop on an FP equipped machine.
(And the random number generator is one library package which uses
float, even if your program doesn't explicitly.  Any others?)

   Now for some value added.  Several years ago for a procurement, we
went looking for Ada (83) compilers that could be validated on PCs
without an FPU.  We couldn't find one, we couldn't find a compiler
vendor willing to build and sell one, and we couldn't even find a
compiler which ran on a machine with an FPU and produced validatable
code for a non-FPU machine.  This was back when the 286 and 386 were
the "standard" CPU chips.

    However, in the machines which used Motorola 680x0 chips, all
machines/compilers seemed to support emulation of the FPU if not
present.  In fact some compilers gave you a choice between non-IEEE
(and therefore non-hardware) floating-point libraries, and those which
relied on IEEE hardware support, but ran much slower if the emulator
was invoked.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: floating point problem

[Robert Dewar]

<<   Now for some value added.  Several years ago for a procurement, we
went looking for Ada (83) compilers that could be validated on PCs
without an FPU.  We couldn't find one, we couldn't find a compiler
vendor willing to build and sell one, and we couldn't even find a
compiler which ran on a machine with an FPU and produced validatable
code for a non-FPU machine.  This was back when the 286 and 386 were
the "standard" CPU chips.>>

This must have been in a very small window, because I wrote emulators
(floating-point emulators) for both the 286 and 386 Alsys products very
early on in the lifetime of the 386. So several here must be at least 10!
\x1adp

Re: floating point problem

[Robert I. Eachus]

In article <332E255B.14EC@bix.com> Tom Moran <tmoran@bix.com> writes:

  >   How many years ago was that?  I used the validated Janus Ada 83
  > compiler compiling on a 286 and generating code for an 8088, both
  > without FPU.  That was at least several years ago.

   I think it was '89 or '90.  The contract award was protested (for
other reasons, whew!).  During the recompete the rules were changed
somewhat, and I think then a target validation but not a host
validation on a '286 sans '287 (or 68020 sans 68881) was required.  It
wasn't that hard a thing to support, but at the point it came up the
first time around, it was to late to ask for it.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Floating point problem

[Kees de Lezenne Coulande]

Larry Kilgallen <kilgallen@EISNER.DECUS.ORG> wrote
on the subject of a floating-point coprocessor being needed for use
of the GNAT compiler:

>That is too bad.  I had hoped GNAT might be useful for deployment.
>Just to make sure we are on the same wavelength, my concern is
>entirely with what happens at runtime with generated programs.
>For running the compiler I can buy (actually already have) some
>appropriate machines.

>But it is really tough to sell software to people if you tell them they
>have to spend 40x the software price to buy a new computer.

     Last year I bought a 387 floating-point coprocessor for my father's 8
Mb 386DX-40 for the equivalent of about $15. Just as an experiment, I have
tried running one of my large Ada programmes on it (which was migrated from
a VAX to a PC using GNAT for OS/2). It ran OK, slowish, but no worse than
the good old VAX on a warm and busy day. And this was under DOS using the
EMX.EXE DOS-extender. I have not tried the compiler on this machine. I
would expect it to work, but too slow for any practical purpose.
     In another silly experiment at "how low can you go", about a year ago
we tried the then-current GNAT for DOS on a low-end 386. I cannot remember
the exact details anymore, but I think it was a 386SX with 2 Mb, and
definitely no FP. Compiling "Hello World" took about 20 minutes, with the
hard disk thrashing about most of the time, and the compiled program ran
OK. Running any useful programme (compiled on a more capable machine) did
not work because of the lack of floating-point coprocessor.
                             Kees de Lezenne Coulander
---------------------------------------------------------------------
  C.M. de Lezenne Coulander
  Amsterdam-Zuidoost
  The Netherlands
  E-mail: lezenne@compuserve.com

  Aircraft Development and Systems Engineering B.V.
  Schiphol-Rijk, The Netherlands
=====================================================================

Re: Floating point problem

[Robert Dewar]

Larry Kilgallen <kilgallen@EISNER.DECUS.ORG> wrote
on the subject of a floating-point coprocessor being needed for use
of the GNAT compiler:

>That is too bad.  I had hoped GNAT might be useful for deployment.
>Just to make sure we are on the same wavelength, my concern is
>entirely with what happens at runtime with generated programs.
>For running the compiler I can buy (actually already have) some
>appropriate machines.


Actually I think there is no big problem in using GNAT in an environment
in which floating-point needs to be simulated. It's not a big task to
provide for emulating floating-point. We didn't do it yet, because
we have not encountered a customer interested in such a product
(interested means more than just saying on CLA that you are interested!)

Re: Floating point problem

[Larry Kilgallen]

In article <dewar.859526944@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Larry Kilgallen <kilgallen@EISNER.DECUS.ORG> wrote
> on the subject of a floating-point coprocessor being needed for use
> of the GNAT compiler:
> 
>>That is too bad.  I had hoped GNAT might be useful for deployment.
>>Just to make sure we are on the same wavelength, my concern is
>>entirely with what happens at runtime with generated programs.
>>For running the compiler I can buy (actually already have) some
>>appropriate machines.
> 
> Actually I think there is no big problem in using GNAT in an environment
> in which floating-point needs to be simulated. It's not a big task to
> provide for emulating floating-point. We didn't do it yet, because
> we have not encountered a customer interested in such a product
> (interested means more than just saying on CLA that you are interested!)

Personally I don't have much need for floating point on machines
without hardware floating point.  My only concern is that generated
code fail in a highly predictable fashion if the environment is not
correct in such a major fashion as this.  If my program makes
no explicit calls to floating point and the runtime library is
going to fail in the absence of floating point, I would think
that automatic detection would be in order.

Considering that the Ada software environment is one where
the type of the argument must match the the formal argument
more closely than in any other language, I would expect the
match between the hardware environment and the required
hardware environment would also be carefully checked on
a non-optional basis.

If the Ada approach is that runtime machine environment
checking is to be entirely manual, I guess the community
is still too centered around the military project model
rather than the model of providing "shrink-wrapped" software.

Obviously this is only a problem where the operating system
does not defend the program against lack of hardware support.

Larry Kilgallen

Re: Floating point problem

[Robert Dewar]

<<Personally I don't have much need for floating point on machines
without hardware floating point.  My only concern is that generated
code fail in a highly predictable fashion if the environment is not
correct in such a major fashion as this.  If my program makes
no explicit calls to floating point and the runtime library is
going to fail in the absence of floating point, I would think
that automatic detection would be in order.

Considering that the Ada software environment is one where
the type of the argument must match the the formal argument
more closely than in any other language, I would expect the
match between the hardware environment and the required
hardware environment would also be carefully checked on
a non-optional basis.>>

Who knows what particular hardware a particular program might require.
So far, we have had no one who has had an interest in this kind of
ayutomatic detection. Note that doing it automatically is far from
trivial, since you have to arrange to reliably trap the fpt operations
and field the traps -- it's just something that is not on our current
list of requirements. We have relatively few serious customers using
low end machines, and none interested in their software working on
a 486sx or rather, as Larry discusses, NOT working "reliably".

If you do want to add this check to your software, or to check for
any other hardware, it is easy enough to do, the cookbook recipe for
checking for the presence of an fpt processor is in the Intel docs.

Going back to our requirements. Right now, virtually all our x86
customers are developing in environments which would not feasibly
run on non-fpt machines in the first place. The first exception will
be for embedded x86 targets, and there we definitely will address
the problem (since some of these targets have no fpt).

I never heard of any serious developer using Unix, OS/2 or NT on
a 486SX class machine, given that reasonable machines can be obtained
for well under $1000 these days, it seems unlikely, as I mentioned
before, that those working on SX class machines are likely to be
a source of a critical customer base!

Actually I would guess that Larry is not in fact concerned about trying
to use GNAt in that environment for his own use, but is rather operating
in "gadfly" mode, which is fine, people are always free to suggest all
sorts of things for GNAT, and occasionally the suggestions are good ones
which can influence what we do, even if no immediate $$$ are involved, so
it's fine to make suggestions.

But I am afraid that working to make GNAT more reliable on low end obsolte
machines running low end x86 operating systems is NOT likely to be on our
work schedule in the forseeable future!

Re: Floating point problem

[Tom Moran]

Robert Dewar said:
> Actually I would guess that Larry is not in fact concerned about trying
> to use GNAt in that environment for his own use, but is rather operating
> in "gadfly" mode,

Apparently forgetting that Larry had said:

> I had hoped GNAT might be useful for deployment.
> Just to make sure we are on the same wavelength, my concern is
> entirely with what happens at runtime with generated programs.
> For running the compiler I can buy (actually already have) some
> appropriate machines.

But, knowing that FPU detection code can be found in Intel docs, is it
possible for a user program to run that code early enough (ie before the
RTS or elaboration code has crashed and burned) to give a nice error
message to the user?

(Having many years ago found that any attempt to run MASM would hang my
brand new 286 because MS didn't test properly for an FPU, I'm personally
curious about this.)

Re: Floating point problem

[Larry Kilgallen]

In article <333E18D8.1F84@bix.com>, Tom Moran <tmoran@bix.com> writes:

> But, knowing that FPU detection code can be found in Intel docs, is it
> possible for a user program to run that code early enough (ie before the
> RTS or elaboration code has crashed and burned) to give a nice error
> message to the user?

And if Ada is intended to be source-compatible between platforms,
why should a programmer need to know the Intel instruction set and
differences betwee chips.  Power-PC and Alpha computers also have
certain instructions which available on some chip models but not
others. Since compiler developers by definition must deal with
such instruction set issues, the Ada implementation would seem
to be the most efficient place for such efforts to be expended.

That does not solve the issue of finding funding for compiler
developers to add such support.  But if Ada is to become more
widely used ultimately the cost of even saying RTFM in response
to trouble calls will drive detecting runtime failures in a
helpful fashion.  This sort of attitude has already been used
for compile-time as no compiler developer has thought it enough
to give a minimal (RM-allowed ?) level of compilation diagnostics
by delivering only a single "not a good Ada program" message
in response to a compilation attempt.

Larry Kilgallen

Re: Floating point problem

[Robert Dewar]

Larry says

<<And if Ada is intended to be source-compatible between platforms,
why should a programmer need to know the Intel instruction set and
differences betwee chips.>>

That seems to be getting a little absurd to me. Larry, do you think the
compiler should be careful to generate code that detects that it is running
on an 8080 and aborts if so (it is definitely possible to write such
discriminating code, in fact you can find it in Intel manuals).

If you try to run a program for one architecture on a computer with a
different architecture, you should hardly be surprised if it does not
work. You cannot possibly derive from the intention that Ada be
source-compatible between platforms that a compiler for a specific
architecture (x86 with fpt support) must diagnose at runtime an attempt
to run on some other architecture (x86 without fpt??? 286??? 186??? ...)

All you can deduce is that if you have an Ada program that works on
architecture X and is written portably, then *if* you have a compiler
for architecture Y, and *if* you recompile for architecture Y, then
you can run on architecture Y.

Larry if you are really interested in running GNAT on an x86 with no
floating-point and an OS that does not support fpt, why not investigate
how to fix the problem, I doubt it is that hard. The reason we don't
spend any effort on this problem is that we don't really have an interest
in running GNAT on such platforms!

Re: Floating point problem

[Larry Kilgallen]

In article <dewar.859869032@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> That seems to be getting a little absurd to me. Larry, do you think the
> compiler should be careful to generate code that detects that it is running
> on an 8080 and aborts if so (it is definitely possible to write such
> discriminating code, in fact you can find it in Intel manuals).

If there is an operating system which will start up the program on
the "wrong" chip, yes.

> Larry if you are really interested in running GNAT on an x86 with no
> floating-point and an OS that does not support fpt, why not investigate
> how to fix the problem, I doubt it is that hard. The reason we don't
> spend any effort on this problem is that we don't really have an interest
> in running GNAT on such platforms!

I have no interest in running the output of Ada compilers on such
platforms either.  My interest, again, is sure-fire detection of
such situations.  Ignoring issues of how much time I have to pursue
a solution for a compiler, I fear the same problem would arise with
the difference between SPARC-2 and SPARC-1 (if there is such a thing)
if compiler developers take the attitude that any issue of machine
incompatibility is to be detected solely by humans reading the box
before purchasing the output of the Ada compiler.

It is certainly the case that operating-system level approaches
would solve this for all compilers, but sometimes one wants to
sell software to those with least-common-denominator taste in
operating systems.

I say "compiler developers" since although this has talked about
GNAT I have not noticed any of the other Ada compiler developers
speaking up to say "our compiler handles that" :-)

Larry Kilgallen

Re: Floating point problem

[Tom Moran]

> to say "our compiler handles that" 
I'm not a compiler vendor, but I note in the Janus manual that the
default is to assume no FPU - you need to set a compilation option "on"
to generate direct FPU codes.  I also seem to recall that Aonix (at
least with ActivAda and I think with ObjectAda) has a compiler option.

  To the best of my knowledge, however, they don't support the
"__gnat_initialize" that Dewar tells us is not a "special vendor
supplied hook".  ;)))

Re: Floating point problem

[Larry Kilgallen]

In article <33418B11.62B4@bix.com>, Tom Moran <tmoran@bix.com> writes:
>> to say "our compiler handles that" 
> I'm not a compiler vendor, but I note in the Janus manual that the
> default is to assume no FPU - you need to set a compilation option "on"
> to generate direct FPU codes.  I also seem to recall that Aonix (at
> least with ActivAda and I think with ObjectAda) has a compiler option.

Great !  Thanks for the pointers.

Larry Kilgallen

Re: Floating point problem

[Robert Dewar]

<<> I'm not a compiler vendor, but I note in the Janus manual that the
> default is to assume no FPU - you need to set a compilation option "on"
> to generate direct FPU codes.  I also seem to recall that Aonix (at
> least with ActivAda and I think with ObjectAda) has a compiler option.>>

ObjectAda certainly *should* have such an option, since I wrote the 
floating-point emulation package for Alsys, for both the 286 and 386,
back in the days when there were real customers around with machines
that lacked floating-point.

If GNAT were that old, it undoubtedly would have the option too. Generally
I would expect all Ada 83 vintage technologies to have this capability,
because once upon a time, PC's with no floating-point were quite common.

In fact one of the most amusing revision requests was one that specifically
suggested that Ada 9X have a language feature that would ensure that
programs would operate correctly on a machine with no floating-point
coprocessor (it was worded exactly that way :-0)

I actually find it surprising that no one has investigated what would bne
needed to get this working on DJGPP (that is really all we are talking about
here, most of the other operating systems for the PC eiher require FPT
themselves, or supply transparent emulation -- so we are only talking about
running obsolete operating systems on obsolete machines). Still with all
the talk, you would think that someone would have figured out how to do
this -- can't be that difficult. 

Despite Larry's focus on a dynamic test to ensure the program not running,
I think that what most people with these old machines around would like is
for GNAT to be able to correctly execute floating-point stuff. Since there
are lots of emulators around, and indeed I ythought DJGPP came with one,
but perhaps not, it seems more useful to put in the work to get this
working rather than diagnose when it does not.

Re: Floating point problem

[Jerry van Dijk]

In article <dewar.859986711@merv> dewar@merv.cs.nyu.edu writes:

>I actually find it surprising that no one has investigated what would bne
>needed to get this working on DJGPP

Well, it did work with the V1.x series, for which I remember having tried
at least two fpt emulators. I do not remember any of them ported to the
V2 enviroment.

As I still must have the sources somewhere in my archive, I'll see if
porting any of them to V2 and GNAT would be a possibility (I suspect it
will be).

--

-- Jerry van Dijk       | Haarlem, Holland
-- Business Consultant  | Team Ada
-- Ordina Finance       | jdijk@acm.org

Re: Floating point problem

[Jerry van Dijk]

In article <860042044.8snx@jvdsys.nextjk.stuyts.nl> jerry@jvdsys.nextjk.stuyts.nl writes:

>
>In article <dewar.859986711@merv> dewar@merv.cs.nyu.edu writes:
>
>>I actually find it surprising that no one has investigated what would bne
>>needed to get this working on DJGPP
>
>Well, it did work with the V1.x series, for which I remember having tried
>at least two fpt emulators. I do not remember any of them ported to the
>V2 enviroment.

Guess what, wmenu (the linux fpt emulator ported to DJGPP) has been ported
to V2. I'll take a look to see if it will work with the EZ2LOAD distribution.

Jerry.

--

-- Jerry van Dijk       | Haarlem, Holland
-- Business Consultant  | Team Ada
-- Ordina Finance       | jdijk@acm.org

Re: Floating point problem

[Jerry van Dijk]

>>Well, it did work with the V1.x series, for which I remember having tried
>>at least two fpt emulators. I do not remember any of them ported to the
>>V2 enviroment.
>
>Guess what, wmenu (the linux fpt emulator ported to DJGPP) has been ported
>to V2. I'll take a look to see if it will work with the EZ2LOAD distribution.

Well, I did some further testing, and as far as I can tell both the
standard DJGPP fpt emulator and the wemu one work as expected.

Notes:

   1. It seems that the standard setup doesn't really work, to use the
      ftp emulation add the old style (V1) lines:

      SET 387=N
      SET EMU387=C:/GNAT307/BIN/EMU387.DXE

      to your autoexec.bat and make sure the file emu387.dxe (normally
      in the directory \gnat307\bin) is in your path for both the
      development and target machines.

   2. An alternative is to link the the emulator library to your
      executable (the advantage being that the .dxe file doesn't
      have to be installed on the target machine), but unfortunately
      this library is not part of the standard EZ2LOAD distribution.
      Getting this library from the net is no solution since the current
      one is for DJGPP v2.01 (and contains some bug fixes, in collaboration
      with fixes to libm) and the current GNAT release is based on the
      -incompatible- DJGPP 2.00.

   3. Another option is getting the alternative wmenu library from the net
      (simtelnet/gnu/djgpp/v2misc) which includes both the .dxe and lib
      files. The advantage of wmemu is rumored to be that it is better
      debuggable. However, this port is rather old and might hold some
      supprises (although I didn't run in to any).

   4. Mike F. notes that he had some reports of conflicts between the
      tasking and the fpt emulation. More info is missing, and I again
      did not run into any problems here.

   5. Documentation notes that there has not been any significant testing
      of either emulator on real fpt-less machines, so beware.

--

-- Jerry van Dijk       | Haarlem, Holland
-- Business Consultant  | Team Ada
-- Ordina Finance       | jdijk@acm.org

Re: Floating point problem

[Robert Dewar]

<<If there is an operating system which will start up the program on
the "wrong" chip, yes.>>

There are operating systems for some machines that will attempt to start
up arbitrary binary files. So by your peculiar reasoning:

(a) All compiler writers for all machines must know about that case
(b) They must put in defences against the program starting up in this case

dubious I think ....

I agree that it would be nice if there were a check for no fpt processor.
But it is of an importance level such that there are so many things ahead
of it that unless someone is more interested in doing the work than
complaining, it probably will never happen!

Actually there is also the point that putting in such a check would reduce
current functionality, since right now you CAN run GNAT on a machine with
no fpt, if you stay away from real arithmetic.

You can use pragma Restrictions (No_Floating_Point) in Ada 95 (it is an
annex H feature, of course implemented in GNAT, since we implement all
annexes):

     1. pragma Restrictions (No_Floating_Point);
     2. procedure q is
     3.    g : float;
               |
        >>> violation of restriction "no_floating_point"

     4. begin
     5.    g := 1.0;
           1    2
        >>> violation of restriction "no_floating_point"
        >>> violation of restriction "no_floating_point"

     6. end q;


So in fact you can use GNAT now on such a machine, with the compiler
checking for violations of the restriction.

The nice feature would be to condition the dynamic check on the presence
of floating-point in the program, but that's even more work, and even
less likely to get done.

Re: Floating point problem

[Robert Dewar]

Tom Moran said

<<Apparently forgetting that Larry had said:

  > I had hoped GNAT might be useful for deployment.
  > Just to make sure we are on the same wavelength, my concern is
  > entirely with what happens at runtime with generated programs.
  > For running the compiler I can buy (actually already have) some
  > appropriate machines.>>

I did not forget that, but people all the time say, "if only GNAT had
xxx, it might be useful". From experience, I ignore all such statements
unless they are in the context of serious negotations.

Tom said

<<But, knowing that FPU detection code can be found in Intel docs, is it
  possible for a user program to run that code early enough (ie before the
  RTS or elaboration code has crashed and burned) to give a nice error
  message to the user?>>

yes, one would use the initialization hook for this. We will be glad to
help any supported user of GNAT with the necessary procedures.

Robert Dewar
Ada Core Technologies

Re: Floating point problem

[Tom Moran]

> <<But, knowing that FPU detection code can be found in Intel docs, is it
>   possible for a user program to run that code early enough (ie before the
>   RTS or elaboration code has crashed and burned) to give a nice error
>   message to the user?>>
> 
> yes, one would use the initialization hook for this. We will be glad to
> help any supported user of GNAT with the necessary procedures.
> 
  It appears that means "No.  It is not possible for a user program to
run FPU detection code before a Gnat program has crashed and burned,
unless the programmer has used special vendor supplied hooks".  Is that
correct?

Re: Floating point problem

[Robert Dewar]

iTom Moran says

<,  It appears that means "No.  It is not possible for a user program to
run FPU detection code before a Gnat program has crashed and burned,
unless the programmer has used special vendor supplied hooks".  Is that
correct?>>

"special vendor supplied hooks???"

Don't know what you are talking about, I am talking about the call to
__gnat_initialize which is intended exactly for this purpose. It may
work to do this at the start of the main program, or in elaboration
code for a user unit, but since __gnat_initialize is EXACTLY intended
for this kind of purpose (to get control BEFORE any elaboration code
is activated), why would you not use it???

Re: Floating point problem

[Tom Moran]

Which Ada 95 compilers will/won't generate code that runs under which
(80x86) OSes on hardware lacking FP?

Re: Floating point problem

[J-P. Rosen]

>Larry Kilgallen <kilgallen@EISNER.DECUS.ORG> wrote
>on the subject of a floating-point coprocessor being needed for use
>of the GNAT compiler:

There is also the issue of LapTops. Mine is a 486SX, and I could use
it for GNAT until 3.05. I can't get it working with 3.07

And please Robert, don't tell me I should by a newer machine. My
laptop is sub-A4, weighs 1.6Kg, and can run 4 hours+ on a single
battery (when the battery is new, admitted ;-). I can't find any
modern machine that comes close to that.
+------------------------------------o-------------------------------------+
|   J-P. Rosen                       |    Rosen.Adalog@wanadoo.fr          |
|   ADALOG - 27 avenue de Verdun     |    Tel: +33 1 46 45 51 12           |
|   92170 Vanves - FRANCE            |    Fax: +33 1 46 45 52 49           |
+------------------------------------o-------------------------------------+

Re: Floating point problem

[Robert Dewar]

<<There is also the issue of LapTops. Mine is a 486SX, and I could use
it for GNAT until 3.05. I can't get it working with 3.07

And please Robert, don't tell me I should by a newer machine. My
laptop is sub-A4, weighs 1.6Kg, and can run 4 hours+ on a single
battery (when the battery is new, admitted ;-). I can't find any
modern machine that comes close to that.>>

First, of course there are machines with this kind of profile available.
Second I never said you should buy a newer machine, I said you should
buy a newer machine if you want to run GNAT! Not surprisingly, the
community that wants to run cheap old machines is not exactly the
community to look to to generate resources for enhancements that
will benefit such machines :-)

Everyone agrees that it would be nice if GNAT ran on machine X, for all
possible X, if they don't have to find the resources to make it happen :-)

I never said it was actively desirable for GNAT not to run on old SX
machines, or on embedded chips without fpt -- just that (a) it does
not support such machines, just as it does not support the transputer
and (b) we have no plans to do such a port -- just as we have no plans
to support the transputer.

If some volunteer wants to make GNAT work on coprocessor-less machines
using operating systems that do not support this transparently, that
would be nice. It would also be nice if a volunteer made a version of
GNAT for the transputer. Neither are high demand items (I did a poll
in my class last semester, no one had anything vaguely as out of 
date as a 486SX, indeed many had amazing machines), so that's why
they don't exist yet, but that does not mean it would not be a
good idea for them to exist!