What CPU ports should have working Ada?

What CPU ports should have working Ada?

[Joel Sherrill]

Hi,

I am curious as to which CPU ports are believed to have
at least one port of GNAT that works reasonably well.
For the sake of argument, let's say on either the
last 2.8.1 based gnat or gcc 3.x based gnat.

I know these CPUs have GNAT ports:

  + i386     (Linux, RTEMS, LynxOS, Windows, etc)
  + mips     (SGI, VxWorks, RTEMS, etc)
  + powerpc  (LynxOS, VxWorks, RTEMS, etc)
  + sparc    (Solaris, RTEMS, etc)
  + hppa     (HP-UX)
  + alpha    (Tru64 UNIX and OpenVMS)
  + m68k     (VxWorks)

NOTES:
  + LynxOS 4.0 is ELF and not supported.  Only
    XCOFF based 3.1.1 is supported from gcc 2.8.1 base.
  + m68k is from gcc 2.8.1 base and thus probably COFF only. 
    3.2 source base does not build due to this error from
    raise.c: __builtin_eh_return_data_regno not currently supported
  + i386, mips, powerpc, and sparc are buildable in 3.2 source.
  + I don't know the status of hppa and alpha in the 3.2 source.

Are there any details I am missing or incorrect on?

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: What CPU ports should have working Ada?

[Andreas Schwab]

Joel Sherrill <joel.sherrill@OARcorp.com> writes:

|>   + m68k is from gcc 2.8.1 base and thus probably COFF only. 
|>     3.2 source base does not build due to this error from
|>     raise.c: __builtin_eh_return_data_regno not currently supported

That should be fixed in gcc 3.3, though it may still be buggy, since I
could not do many tests yet.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: What CPU ports should have working Ada?

[Joel Sherrill]

Andreas Schwab wrote:
> 
> Joel Sherrill <joel.sherrill@OARcorp.com> writes:
> 
> |>   + m68k is from gcc 2.8.1 base and thus probably COFF only.
> |>     3.2 source base does not build due to this error from
> |>     raise.c: __builtin_eh_return_data_regno not currently supported
> 
> That should be fixed in gcc 3.3, though it may still be buggy, since I
> could not do many tests yet.

Great.  Was this fixed in any other ports as far as you know?

And what does the definition of __builtin_eh_return_data_regno
boil down to anyway?  

> Andreas.
> 
> --
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

Re: What CPU ports should have working Ada?

[Andreas Schwab]

Joel Sherrill <joel.sherrill@OARcorp.com> writes:

|> Andreas Schwab wrote:
|> > 
|> > Joel Sherrill <joel.sherrill@OARcorp.com> writes:
|> > 
|> > |>   + m68k is from gcc 2.8.1 base and thus probably COFF only.
|> > |>     3.2 source base does not build due to this error from
|> > |>     raise.c: __builtin_eh_return_data_regno not currently supported
|> > 
|> > That should be fixed in gcc 3.3, though it may still be buggy, since I
|> > could not do many tests yet.
|> 
|> Great.  Was this fixed in any other ports as far as you know?

No.  Every target must be handled specially.

|> And what does the definition of __builtin_eh_return_data_regno
|> boil down to anyway?  

It requires a working implementation of __builtin_eh_return, which
includes definitions of the macros EH_RETURN_DATA_REGNO,
EH_RETURN_STACKADJ_RTX and EH_RETURN_HANDLER_RTX, plus support for them in
the prologue and epilogue generation.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: What CPU ports should have working Ada?

[Marc Espie]

In article <3E3A7BC4.2B3069A7@OARcorp.com> you write:
>
>Hi,
>
>I am curious as to which CPU ports are believed to have
>at least one port of GNAT that works reasonably well.
>For the sake of argument, let's say on either the
>last 2.8.1 based gnat or gcc 3.x based gnat.
>
>I know these CPUs have GNAT ports:
>
>  + i386     (Linux, RTEMS, LynxOS, Windows, etc)
+OpenBSD
yes, it works. :)

Re: What CPU ports should have working Ada?

[Matthew Wilcox]

> I know these CPUs have GNAT ports:
> 
>   + i386     (Linux, RTEMS, LynxOS, Windows, etc)
>   + mips     (SGI, VxWorks, RTEMS, etc)
>   + powerpc  (LynxOS, VxWorks, RTEMS, etc)
>   + sparc    (Solaris, RTEMS, etc)
>   + hppa     (HP-UX)
>   + alpha    (Tru64 UNIX and OpenVMS)
>   + m68k     (VxWorks)

Debian has gnat available for the following ports:

  gnat-3.2 | 1:3.2.2-0pre8 |      unstable | alpha, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc

ARM and m68k are missing as they wouldn't compile.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: What CPU ports should have working Ada?

[Robert Dewar]

This is a hard question to answer, since it depends on what you mean by
working. For us, working means passing our entire test suite, and in those
terms, none of the Debian ports are close to doing this yet. We are finally
getting to the point where for some selected targets, we are getting
clean runs, but there is still quite a way to go.

Re: What CPU ports should have working Ada?

[Joel Sherrill]

Robert Dewar wrote:
> 
> This is a hard question to answer, since it depends on what you mean by
> working. For us, working means passing our entire test suite, and in those
> terms, none of the Debian ports are close to doing this yet. We are finally
> getting to the point where for some selected targets, we are getting
> clean runs, but there is still quite a way to go.

I was wanting to get a list of the CPU families that had > 0 support for
Ada so would know which ones even had a possibility of being worth
attempting
to use on GNAT/RTEMS.  The behavior of RTEMS is a known and consistent
quantity across all ports.  Thus if GNAT is stable enough to compile the
run-time 
for a particular CPU family, then we should get the same ACATS test
results
across all RTEMS ports.  I was hoping this would help with the testing
since
the OS wouldn't be as much of a factor in the problems.

I did not expect 100% passing at this time on the gcc 3.x source base. 
Only
similar test results if GNAT compiled for a particular CPU familiy at
all.

As it stands, we are now providing RPMs with GNAT for every CPU family
(except hppa) that has a "working" GNAT and RTEMS port -- sparc,
powerpc, 
mips, and i386.  The big ones to add next are the m68k and ARM. And
as of the 3.3 branch, the m68k is supposed to have the exception
handling
stuff in place.

Thanks, Dr. Dewar.

--joel