Anyone interested in resurrecting an open source strict Ada 83 (mil-std 1815A) compiler?

 Hello to all !

I strongly believe there is a place for a strict Ada 83 open source compiler. Of course there is the modern gnat and successive revisions of Ada , but these are very complex systems and many applications do not need object programming or leading edge programming functionnalities.

In my career I appreciated the original Ada 83 as a super Pascal which let me understand easily today my thesis source code I made forty years ago with DEC Ada and never looked at between.

The early Ada 83 language was (and still is) a peculiar programming environment with no equivalent (modern Ada revisions are somewhat different worlds), it would be a great loss to abandon it ; Ada 83 is the best introduction to modern revisioned Ada.

I am looking at people with some compiler experience and good software practice, perhaps of my generation (I’m 61) interested in taking part in rebuilding an Ada 83 compiler written in strict Ada 83 (no Ada 95 or more recent revisions) and open source for a community of passionates or for young students.

I have done quite some work on an Ada 83 front end producing DIANA intermediate representation based on a Peregrine translator.

There is few compiler open source code for original Ada compiling, and nearly none in Ada 83. Ada-Ed was in C translated from SETL, some subsets have been attempted in Pascal. There is also the lovely work on HAC, but which is not Ada 83 and handles a language subset.

The only open source full Ada 83 front end which auto compiles its sources I know of is the Peregrine translator found in one of the two disks of the Ada repository. I modified it extensively to clarify its compiling phases structure and it still produces DIANA form for all its pieces.

Now it is lacking a code generator. The intent of Bill Easton from Peregrine was to translate DIANA to C. I found some Pascal work done in Poland coding from DIANA to an A-code stack machine. But perhaps a backend like QBE would be a better modern choice with the idea of also taking advantage of ELF dynamic linking.

If someone is interested in this project, I have setup a framagit project and I can be contacted on my email : vincent.morin@univ-brest.fr.

3 Likes

you might want to talk to Edward GitHub - OneWingedShark/Byron: The Byron project is a community-driven Ada compiler, toolchain, and IDE-system.

Thank you for your fast reply.

Many tentatives target Ada 95 or more recent versions (the case of Byron) which is an enormous undertaking and moreover does not keep the original atmosphere of Ada 83 programming which deserves to be maintained alive not only for historical witnessing.

Perhaps people will find I am old fashion, but I would like to adhere stricly to Ada 83 defined in original LRM ANSI/MIL-STD-1815A. A reasonably lightweight system can be thus obtained and mastered with modern technology.

For the Ada 83 original definition, the translator I derived from Peregrine’s already does lexical and syntax analysis plus semantic analysis in a seemingly correct way, and a DIANA tree is ready for use. That is much of the way is already done and would only need thorough verification of some details. But as is, the front end has eaten many code lines without complaining.
The remaining work is essentially about code generation (high level intermediate, optimization, machine code generation), which I hope could be done by reusing existing ideas/pieces translated in Ada 83.

For curious people interested in the work already done, I opened my framagit project available at : Vincent Morin / Ada-83-compiler-tools · GitLab

1 Like

Yes, it does. He’s re-engineering DIANA and the APS.

For back end, there’s plenty, libfirm, llvm, qbe. You could take a small one and translate it. some here too.

Unless it’s a platform GNAT is ported on, or the machine doesn’t have the resource to run it, I don’t understand why you would need a compiler that covers only the 83 standard, considering GNAT already exists and there is a pragma for a strict Ada 83 mode. So it’s not lacking a compiler. Or it’s a pet project / hobby ?

It’s always good to have multiple options. You never want to rely on a limited set of vendors.

Ada is like jello. There’s always room for more.

2 Likes

Many projects do not need object programming, tagged types, child packages and so on. All this is extremely interesting, but those “facilities” lead to an enormous compiler complexity which is completely useless for many useful projects.

Sure, I am a relatively simple user, not programming for fighter jets software, but every time I used Ada 9X/2X features, I ended with a lower quality software structure with more complexity and difficulties to come back to an old work after some years. And finally I came back to a solution with original Ada 83. When I tried other languages, C was a terrible experience for long term maintenance, and Pascal was much inferior to Ada 83 when project size increases. So Ada 83 is in fact a very good choice for many projects when maintenance is a priority target.

My experience starting with DEC Ada in 1986 up to now is thus that for “simple users” with maintainability through numerous years as utmost priority, strict Ada 83 is better than revisions. Sorry if some of you tax me iconoclast, but it is my practical finding.

Gnat is a wonderful system, but not only -gnat83 does not enforce strict Ada 83 (it tolerates some wanderings), but why using such a huge system to compile only what today looks like a simple subset of Ada 9X/2X ?

So I maintain that it would really useful to have an Ada 83 written open source modern strict Ada 83 compiler, and that community people who want to build an Ada compiler would be better inspired to stick to the roughly 200 hundred pages of std-1815A rather than to five times thicker modern revisions ; even if it seems old fashion. Let this herculean job to AdaCore engineers. Even with std-1815A, a normal programmer can spend his life on Ada 83 subtleties.

Gnat availability and modern IDEs allows quick Ada development, and producing a strict Ada 83 compiler, itself programmed in strict Ada 83 so that it compiles itself ok, is now a much more accessible project compared to forty years ago.

Now for curious people, you can take a look at the git repository Vincent Morin / Ada-83-compiler-tools · GitLab . Even just for a look at old fashion Ada !

1 Like

So your only practical issue is not a lack of support for a platform, but that -gnat83 isn’t as standard-conforming as it should. Ok, I understand… now whether or not that justifies writing a new compiler…

1 Like

When a tool offers additional features, they are used, even if the lack of those features could in fact prove beneficial after close examination of the solved problem, Very few people will write Ada 83 if they have an Ada 9X/2X compiler at hand. Being constrained by a good tool is desirable, constrain oneself requires unusual motivation.

Taken into account the number of usable Ada in Ada open source compilers available today (one, Gnat) “writing a new compiler”, as you say, does not seem complete nonsense. Compare with the number of open source C compilers written.

When project Byron started a decade ago, they started from scratch with the ambition of targeting revision 2012 and the github seems to have stalled 4 years ago in parsing phase. In my opinion, there is some chance that it will never complete because revisions Ada 9X/2X are overly complex.

I tackled the problem differently, I chose the simplest Ada version, if I can say so, which is already fairly complicated and tried to find already existing Ada 83 software components.

One day I found in the swtools directory of the first 1995 walnut Creek Ada CD a DIANA frontend programmed on DEC Vax which seemed complete though somewhat inorganized. I refactored it deeply to well separate lalr and idl tooling form the frontend itself but keeping it Ada 83 conformant.

It means that there is good chance that half of a complete Ada 83 compiler written in Ada 83 is already available and can compile itself, that is it produces semantically verified DIANA 86 trees for every part of itself with presumably few defects. If so, writing a new compiler is essentially reduced to producing in Ada 83 a converter from DIANA 86 to ELF embedded target code. Which is not as overwhelming as writing an Ada 2X compiler from scratch. But perhaps is it already more than a compiler developping community is ready to consent.

I never found an Ada 83 software component for converting DIANA 86 to Intermediate level optimizable code, it seems that all open work on IR has been done mainly in C. I have not the least idea of how Janus, DEC Vax or Alsys code generators looked like. It is regrettable no producer of Ada 83 compiler ever released some source code, it represents too much work probably and/or sensitive technology.

Using llvm is reattaching to an enormous system, something like QBE would be more realistic, but must be adapted from C.

When I was younger, I spent time on a “medio” compiler which had a high level 3 addresses IR code with final coding to M68K inspired by Aho & Ullmann books reading. If I keep on alone I’ll probably divert M.Ciernak work on DIANA 86 to stack toward DIANA to this optimizable IR. But if some good soul has some Ada 83 example source code of code generators for Ada 83 compilers from university or industry, I am interested to study them.

I hope you are able to find some people able to help out. I’m not particularly interested in ada83 myself. I found it exactly opposite of your experience. I was elated when ada2005 came out. However I do understand your point of view and fully hope this project gains speed. I think it would be an excellent addition to the community.

One question: in your opening post you only referenced working with framagit and then in a later post linked a gitlab project. I wasn’t clear on what public location for the project is?

If it isn’t related to the gitlab project then it might be nice to provide the public repo link. You might get some extra help from folks with pull requests and suggestions

There was talk on IRC a few times over the years about creating a new language starting with Ada83 and modifying that, i.e. normal class system, no anonymous type stuff.

Ada 9X/2X object programming with classes tagged types and so on is very good for people who need this. I sometimes used it in the past and I found it a remarquable system ; but I also found that it was not serving my objectives of maintainability.

If I make a piece of very classical software working on it for several months, and then letting it aside for months or years, I wish to have no difficulty in working with it again if necessary. That’s why Ada 83 is for me the best choice. Some other users will have other requirements and will prefer later revisions features.

I do not see the interest to create a new language from Ada 83 by adding a class system which would be less performant than 9X/2X’s. The Ada line of language revision is surely the most well thought software production system. It is just that sophistication and features of tooling should be adapted to project objectives.

As a remark in passing, I wonder why class based programming systems seem to obsess software industry. Many software systems can avoid class, hierarchical heritage and most of related concepts ; in many cases this integrated system of classes is cumbersome (the “gorilla with the banana” when needing a banana) and classical modular object oriented language (not object proper) amply suffices. Class object programming is a special paradigm whose excesses were seen in Smalltalk where it was explained that “a+b” was to be understood as b sending a message to a to add with it ! If your project is about polynomials or numeric methods and you come from Fortran world, you will find this view somewhat offset from your reality. Of course when looking back at MacIntosh early software, you understand why tagged types and extendable records can be useful (GrafPortRec in WindowRec).

One task, one best tool. To drive a nail, a hammer. But for the hammer, no need to lug around the whole workshop.

Hence the usefulness of a strict light Ada 83 compiler.

2 Likes

Hello,

For historical reasons, I created a project on framagit org which uses gitlab for project hosting and management. I am not very competent with version managing systems, so I use this more as a simple backup. The project would surely benefit from the competences of a younger manager, I begin to belong to the ancient epoch.

I gave before the address of the public repository where I uploaded my work on the DIANA frontend and associated work on a backend stub but the two posts have been flagged and masked probably because of the link I inserted. Perhaps the managers can do something, it is not spam.

If the link cannot be unmasked, or if something I did is incorrect, please tell me.

When the link is available, feel free to take a look at it or sending interested people, every remark will be welcome to bonify, even negative ones.

The link works. I would change the names to use all lower case as is current convention for compatibility with case sensitive file systems., also when upper case is used on case insensitive systems, they tend to not be used consistently.

Also, you usually don’t put binaries in source control and the usual naming is “bin” now.

Ada 83 is a very good language, and well ahead of its time; so far ahead that it’s still a better language than most of the commonly used languages today. That said, it still has some problems that need addressing: finalization and integers with an unsigned representation, along with a few others. There are also nice-to-have things, like mutual exclusion without a thread of control and hierarchical namespaces. DO-178-certified avionics S/W was created in Ada 83, so these are clearly not fatal problems.

I would welcome an open-source, working Ada-83 compiler. It might find limited use, but having an additional tool seems like a good thing to me. If all that is needed is converting from DIANA to assembler/object code, or to an IR with an existing optimizer/code generator, then it sounds feasible. I unfortunately have no experience with this sort of thing, so I doubt I could be helpful.

2 Likes

The link works. I was just making sure it was the correct one since your original post indicated you preferred email and didn’t have a repo link. I was just verifying that the link in the second post was the repo mentioned in the first post

Using class inheritance can definitely go crazy pretty quick but I sometimes think people can get too polarized on it. I think maintenance can be a problem when you start having deep multi level inheritance trees but I feel that there is a space in the middle where some classes can enhance readability and maintainability. I tend to favor a more trait based approach to classes which is often restricted to a one level deep inheritance. I have seen drastic improvements in maintenance and huge reductions in bugs by converting large discriminated record systems into using an interface/implement model (again 1 level deep)

1 Like

@VMo Wow, nice :heart_eyes:! Some questions

  • What is license?
  • Do you have coding style preferences? Some files in the repository is far from recommended in Ada Quility and Style Guide.

PS. It seems this is the original code, right?

RELEASE NOTICE

This prologue must be included in all copies of this software.
Restrictions on use or distribution:  NONE

DISCLAIMER

	This software and its documentation are provided "AS IS" and
without any expressed or implied warranties whatsoever.  No warranties
as to performance, merchantability, or fitness for a particular
purpose exist.
	The user is advised to test the software thoroughly before
relying on it.  The user must assume the entire risk and liability of
using this software.  In no event shall any person or organization of
people be held responsible for any direct, indirect, consequential or
inconsequential damages or lost profits.

PPS Index of /ase/ase02_02/tools/diana

I have seen a number of posts on Reddit of users who still use 83. Perhaps a green hills compiler or something. I used to think that was arcane but now I’m not so sure. I shall be brutally honest as usual. Ada goes to great length to provide for creating portable code and yet most of the GNAT and Ada std libs are not compatible with light targets or spark with in my opinion little benefit for that detriment. Booch original components seem more readable to me and they are compatible with any target unlike the 95 or stdlib versions/containers. I would never swap Ada for Rust but this has been the one thing that has made me wonder for a few seconds at times if I should be using Rust. At the same time I am sure there are > 83 features I would miss that are compatible with all targets/light runtimes. Predicates for example.

If you’re a nerd like me and can’t read French, here’s an automatic translation of Markdown files (README.md, doc/introduction.md, wiki/*) using DeepL.

Max Reznik / Ada-83-compiler-tools · GitLab (See topic/english branch).

PS. Comments in Ada code to be done :clown_face:?
PPS. It appears that files in wiki/alrm_9.*.md are translations of corresponding Ada '83 Language Reference Manual chapters. Perhaps I should delete them :man_shrugging:.

1 Like