Re: ECLAT [was: Ada memory management?]

[Nick Roberts <nick.roberts@acm.org>]

Luke A. Guest wrote:

>>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.

Okay, but I particularly want to be able to offer a different back end, 
especially one that is written (substantially) in Ada.

>>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.

I think I put this badly. What I mean is that gnatmake refers to source 
code files (specs) when working out which files to recompile (and in what 
order). This requires a certain amount of extra parsing that I want to 
avoid. I also want to totally disconnect source files from the library 
rebuilding process, apart from those source files which are being 
explicitly submitted, so as not to impose avoidable limitations on the way 
source text files are stored (compressed, encrypted, on a different 
machine, privileged, etc.).

>>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.

AdaOS has been carefully designed so that all code will be 100% portable 
(at the source code level), barring hardware differences (and segmentation 
is surely a hardware difference).

Support for segmentation will be totally implicit in normal Ada code 
(general access values will be segmented, pool-specific ones will not), so 
that porting normal code to another hardware platform will only require 
recompilation. If the hardware does not support segmentation, the compiler 
will emit code which uses the flat memory model.

Only a small amount of the overall AdaOS source code will be 
hardware-dependent.

 > Segmentation is being done away with in the 64-bit x86 CPU's
> AFAIR. Some CPU's don't support it at all (PPC).

In fact both the 32-bit and 64-bit PowerPC architectures are segmented, and 
I intend to make full use of this. The way segmentation works on this 
architecture is different to the 'traditional' model used by the IA-32. All 
segments have the same size, each has a fixed location in the linear 
address space, and they are contiguous. This has the advantage that the 
addressing model can be linear or segmented.

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

There are distinct advantages to using a segmented model. It allows you to 
move blocks of data around in your linear address space, and resize them, 
without changing the machine code address of any of the data. This provides 
many benefits: dynamic stack and heap creation and resizing; easy and 
efficient shared module management; it helps with my IPC model.

All these techniques are made necessary by the fact that the 32-bit linear 
space is becoming too small nowadays. The much bigger address space offered 
by 64-bit addressing solves the same problems in a different way.

-- 
Nick Roberts