I don’t know why that should be a huge problem: you already know how big the stack-frame-equivalent is, so you pop that amount off the stack, just as you would clean up the stack-frame for a normal compiler.
For the second point, I would not bet that Ada/Ed can be augmented to the required fraction of an x95 Ada compiler to process and code an early available gnat source.
I feel this enterprise will require a considerable endeavor.
Ah, but do you think it would be doable working on it for a year full-time?
My intuition is not very positive about the possibility to add enough Ada95 features to be able to compile an available earliest gnat. But advice from others are welcome and probably better than mine.
Nonetheless, a first task would be to recompile the Ada/Ed with a modern C compiler (standard normed C, not C++ or featured C). It seems there is no present Ada/Ed functional downloadable executable suite of it. for example the
is mainly a source archive (there are some execs though, but compiled for what ? )
This link is particularly interesting giving information on the internals of Ada/Ed (specially the files ais, tre, aix, axq and so on) :
I had succeeded in recompiling the imain.c by curiosity, so the rest can almost surely be recompiled but there are compilation errors to correct to comply with today C.
IMPORTANT NOTE
This task of cleanly rebuilding and re-documenting Ada/Ed could be fairly useful by itself, that would give another open source Ada 83 working compiler (which will be mentioned on Ada83 memory site ada83.org of course). With a minimum of documentation complement on use options, it could be used again.
When updating C code to compile, perhaps you will figure out the symbol table structure or the tree representation. It is probably very specialized for Ada 83, so is extending it for some Ada 95 features possible ? Mystery. And for what Ada 95 features ? It depend on the early gnat content. All this has to be studied carefully. But I feel like not very optimistic. How do others feel ?
Thank you for the consideration. My interest lies in industrial automation, or any kind of machine really, using Plan 9 (9front fork) as the core platform from the engineering workstation down to the control CPU. I’ve done some work in this area and my interest is to use Ada in place of ST.
The main hurdles are the non standard Plan 9 C library and compiler suite which is mostly C99 compliant with some unique features. No in-line assembler. Lex and yacc. Not POSIX nor Unix. MIT license. These aren’t deal breakers, plenty of “foreign” C software has been ported such as Ghostscript and Python.
Plan 9 was designed for cross platform and all the source and tools are included by default. This means any supported architecture can bootstrap another just by changing the environment variable “objtype” and building. Ideally, a Plan 9 Ada bootstrap compiler should be completely architecture agnostic allowing one to set objtype=x and run the build. This is the hard part as you would need to emit a binary for each arch. Though it’s possible to use the same cross platform technique Go uses: emit Plan 9 assembler. Then hijack the existing linkers to build the target binary. Though, at that point you’re close to a native Ada compiler, which would be interesting.
As for the entirety of Gnat and the Ada standard library, I can’t speak for that. I am not sure what is needed to enable Gnat if it heavily relies on GCC and GNU C libraries. Might be a show stopper but I would like to investigate what is possible. In the mean time I Have to brush up on my Ada.
@Efraim I just remembered something that may be of your interest/may help you in this quest. The HAC Ada Compiler, written by @zertovitch. It is an Ada"-like" language which is designed to be scriptable/quickly compiled. It may help you understand some of the compilation techniques and structures used in an Ada compiler
Just a clarification: HAC is better than an Ada-like tool: it supports an Ada subset. For instance programs developed with HAC compile with GNAT and work the same.
As a HAC user, the fact that an Ada compiler can compile an HAC source is a major advantage over other scripting solutions.
What’s more, in standalone mode, HAC is fast and reliable (tested on thousands of lines of code).
Finally, in an Ada program, if a scripting system is required, HAC seems to me to be far superior to Python (this snake’s name is not taken at random) because, beyond the similar paradigm, HAC is much easier to integrate at build…
Unfortunately HAC in its present state is unsuitable for scripting:
You cannot create a HAC package/unit programmatically from Ada. See Module Objects — Python 3.13.4 documentation. This is one minimal requirement for calling Ada host’s subprograms back from HAC as HAC subprograms passing HAC arguments in and out. Raising exceptions on the HAC context. You can do this in Python API, you can do this in Julia API.
You cannot browse HAC packages/units for callable entries. This a requirement to call HAC from Ada as an Ada subprogram passing arguments forth an back.
HAC exceptions do not propagate in Ada. E.g. in Python API you can check the pending error state and raise an Ada exception.
P.S. I would gladly use HAC for scripting as I do with Python and Julia. Moreover it would be great if GNAT Studio added HAC scripting too. Presently GNAT Studio uses messy Python like I do.
