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-Thread: 103376,c68551ab190372c8 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!not-for-mail From: Nick Roberts Newsgroups: comp.lang.ada Subject: Re: ECLAT [was: Ada memory management?] Date: Sat, 09 Oct 2004 01:12:35 +0100 Message-ID: <2soonlF1oglcpU1@uni-berlin.de> References: <2slce8F1manqgU1@uni-berlin.de> <2slvmbFs3bsrU1@uni-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de pGWuQnvIHSCIY7UhRQjVbQtihxFDNgXlgiN6c3ATjj/n2UhUs= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en In-Reply-To: Xref: g2news1.google.com comp.lang.ada:4943 Date: 2004-10-09T01:12:35+01:00 List-Id: 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