comp.lang.ada
 help / color / mirror / Atom feed
From: "Luke A. Guest" <laguest@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk>
Subject: Re: ECLAT [was: Ada memory management?]
Date: Fri, 08 Oct 2004 19:16:04 +0100
Date: 2004-10-08T19:16:04+01:00	[thread overview]
Message-ID: <pan.2004.10.08.18.16.00.210436@n_o_p_o_r_k_a_n_d_h_a_m.abyss2.demon.co.uk> (raw)
In-Reply-To: 2slvmbFs3bsrU1@uni-berlin.de

On Thu, 07 Oct 2004 23:52:57 +0100, Nick Roberts wrote:

> Honest truth is, not very far yet. There are a few docs under the 'Docs' link.

I'll have a look, but I have a feeling I may have already read them a
while ago ;-)
 
> I do want ECLAT to be (friendly :-) competition for GNAT/GCC, both in
> the front and and the back end. I think this is a case where it makes
> sense to 'reinvent the wheel'. If people who are new to Ada ask "Are
> there any free compilers?", I think it would sound a lot better to be
> able to suggest two, rather than just one. (I know there is ObjectAda,
> but it is really only a demo version.)

It would be two, two different front-ends to GCC, that makes two not one.
 
> There are some technical reasons why GNAT and GCC are unsuited to what I
> want to achieve.
> 
> GNAT's library model is based on source code files directly representing
> the library; this model isn't always ideal. I want to provide a compiler
> that has the more traditional model of a library being stored in a set
> of files which contain all the necessary information (to generate
> executables) in a binary form.

I'm not too sure what you mean here. The old/original way of handling
libraries in Ada (AFAIK) uses a kind of repository where packages are
added when they are compiled, and they have to be removed by hand. GNAT
changes the standard Ada way of handling libraries, by using normal link
libraries and a standard linker.

The only source I see is in the adainclude dir where we have *.ali and
*.ads files.

> I want ECLAT to be able to target the AdaOS native executable format for
> the IA-32 (NEAI/IA-32), which is segmented. GCC emits code which is
> suitable (only) for a 'flat' memory model, and I think adapting it to
> generate code that supports the NEAI/IA-32 segmented architecture would
> be difficult.

No offence, but your OS is not going to be too portable in the near
future. Segmentation is being done away with in the 64-bit x86 CPU's
AFAIR. Some CPU's don't support it at all (PPC).

Either way, it would be possible to provide a flat-memory model ECLAT
under GCC, via a front-end port.

Luke.




  reply	other threads:[~2004-10-08 18:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-07  9:39 Ada memory management? matthias_k
2004-10-07 12:06 ` Martin Krischik
2004-10-07 17:24 ` Nick Roberts
2004-10-07 19:04   ` Luke A. Guest
2004-10-07 22:52     ` ECLAT [was: Ada memory management?] Nick Roberts
2004-10-08 18:16       ` Luke A. Guest [this message]
2004-10-09  0:12         ` Nick Roberts
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox