From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,bc1361a952ec75ca
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-09-10 12:40:21 PST
Path: 
 archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!hammer.uoregon.edu!skates!not-for-mail
From: Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>
Newsgroups: comp.lang.ada
Subject: Re: RTEMS and Ada, Was: Re: Ada OS talk (was: Progress on AdaOS)
Date: 10 Sep 2001 15:29:45 -0400
Organization: NASA Goddard Space Flight Center
Message-ID: <uelpehmja.fsf@gsfc.nasa.gov>
References: <mailman.999544263.23337.comp.lang.ada@ada.eu.org>
 <9n2jcd$b50$1@nh.pace.co.uk> <9n3h11$9ic1@news.cis.okstate.edu>
 <9n7vfh$nq6$1@nh.pace.co.uk> <9n8o51$aik1@news.cis.okstate.edu>
 <9nala6$p3$1@nh.pace.co.uk> <9nhbjd$dcg$1@suaar1aa.prod.compuserve.com>
 <Vt2n7.2101$%u4.2249@www.newsranger.com>
NNTP-Posting-Host: anarres.gsfc.nasa.gov
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: skates.gsfc.nasa.gov 1000150252 329 128.183.220.71 (10 Sep 2001
 19:30:52 GMT)
X-Complaints-To: dscoggin@cne-odin.gsfc.nasa.gov
NNTP-Posting-Date: 10 Sep 2001 19:30:52 GMT
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
Xref: archiver1.google.com comp.lang.ada:13000
Date: 2001-09-10T19:30:52+00:00
List-Id: <comp.lang.ada>

Simon Clubley <simon_clubley@remove_me.excite.com-Earth.UFP> writes:

> <snip> 
> The situation's a bit more complicated than that. :-)
> 
> OARcorp _do_ support Ada as a development environment for RTEMS. However,
> some of the BSP's (for example, the i386 BSP) have moved from COFF to ELF.

Hmm. In my experience, a Board Support Package (BSP) is written in C,
or Ada, or (most likely) Assembler. _not_ object code. 

So what does it mean that a BSP has "moved from COFF to ELF"? 

Maybe the BSP defines the loader, and it needs to know the object file
format. I guess that would make sense.

> The current GCC used for GNAT, 2.8.x, generates COFF format
> binaries. 

This is misleading. GCC, the compiler, does not generate binaries; it
generates Assembler code. The system assembler and linker generate
binaries. If using the Gnu assembler and linker, they come from the
binutils package, not the gcc package. So just because GNAT uses gcc
2.8.1, does not mean RTEMS can't use it with binutils 2.11 (latest on
Gnu site).

I suppose there may be some upward incompatibilities, but I'd be
surprised.

> It has been commented on several times in the RTEMS mailing list
> that OARcorp are eagerly awaiting for ACT to deliver a GNAT for GCC
> 3.x. :-)

They don't have to use only the binary distributions from ACT! I would
consider it part of a 3rd parties job, to repackage things for exactly
this kind of reason.

-- 
-- Stephe