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

[VMo]

Hello !
I am not very competent for licencing terms, probably some here will have better suggestions than mine.
The link you mentioned to archive.adaic effectively seems to be the mention of the original source code. I have a backup of the original William Easton / Peregrine work and I keep carefully the walnut creek CD’s from which I extracted the original source.

Until now, i never published anything about the system I derived from Peregrine’s work, so I did not care a lot about licence mentions.
Of course if this work on an Ada 83 compiler derived from Peregrine’s Diana system is publicized due mentions of origin and licencing terms will be included.

The original work has been transformed a lot and if the original licencing terms from Peregrine allows, it seems to me that a GPL licence would be appropriate for the present derived work so that source code of further derivations should be published.
Comments from every competent participant is welcome on this issue.

Talking about coding style, I have an open mind and I think the approach of Gnat style checking is excessive. I myself changed of style with age and I am conscious that there is not only one manner to write an understandable system.
My advices would be to to avoid a too densely written code, that is why I tend to use tabs of size 10 to spead syntax elements on a 100 characters line width.
Package specifications benefit from a compact vertical writing because it facilitates conceptual and structural comprehension. Bodies pose more of a problem of algorithmic grasping which benefits from a more verticallly spread writing.
A whole left based indentation is not always the best idea for loop or blocks labels, center those labels sometimes more efficiently draws attention on them.
Comments should not be systematic, I had a time when I filled lines with comments from column 120 to 250, before I had to acknowledge that I mainly did not read them when reading again the source code later.

Coding style is not all, choice of clear-cut concepts and good concepts naming also impacts comprehension.

The ultimate criterion is system understandability and maintainability. A good test is : write a piece of software, let it aside several months or years, then work again on it. if you understand quickly and reenter the software easily, it was well done. Everything that poses comprehension problems should probably have been done differently. Of course this test is problematic in an engineering perspective where time is often critical, but in an academic career such things can be practiced and bring some information on what is beneficial and what is not.

As for the question of licence, coding advice from experienced people is welcome. If some kind of coding standardization is recognized as a real benefit, why not, but I myself tend to be rather liberal on this coding style issue.

[VMo]

Some considerations for natural language matters. Every sensed individual will recognize that english is the vehicular language especially in Computer Science. Nonetheless, when possible, it should not be neglected that a mother language expression is more easily understood. To have an in depth understanding of LRM 1815A, I translated chapters of it in my mother language. I think it would be a good thing to subdivide and keep the documentation for different languages when translations are available.

As long as I was alone, commenting in my language with some bizarre experimental code layout trials posed no problem, it is clear that if some other people are interested to participate, I’ll come back to english comments and respect some agreed conventions.
I had a tendency to over comment with the idea of printing source from column 1 to 120 and comment to columns 250 on another page. It was not a very good idea. If source code is to be managed collectively, it would probably be better to completely remove comments and have some separate descriptive documentation for packages and sub-programs description. The problem is that it would be nice to have some integration of the two sides, source-code and multilingual documentation.

If somebody has practical experience on efficient software documentation and sogftware structure representation (structural package graphs…), advice welcome here also.

[OneWingedShark]

Thank you for looking at Byron.
You are right at getting stalled on parsing: a combination of a bout of depression and “life happening” afterwards sapped a lot of motivation… and, TBH, since then the question of “Will there be any payoff?” has haunted me.

@Lucretia is right in that I wanted to use a DIANA-inspired (though OOP) IR — in part because the idea of DIANA really appeals to my design-sensibilities, and in part because it could be a foundational technology providing a huge leap in qiality over other programming-language utilities. Example: The Alire management-system, had it used such an IR, would be able to (a) reject non-parsable code, keeping the repository clean and preventing “Dave broke the build”-commits, and (b) use a DB to not only store, but version, and possibly even flag/prohibit non-compatible dependency-sets.

Anyway, my main plan would still work for you, all we would have to do is:

1. Write a DIANA to SeedForth (a tokenized, minimal Forth) backend;
2. Write a SeedForth interpreter;
3. Translate the compiler source (with the backend from #1), yielding SF/Ada;
4. Translate the interpreter of #2, yielding SF/SF;
5. Implement the SeedForth words (about 30) for whatever new processor;
6. Combining #4 & #5 yields a SeedForth interpreter on the new processor;
7. Using #6, we can then interpret #3 (SF/Ada) and compile on the new HW;
8. If native code is needed, a new backend can be done;
9. Combining #7 & #8 yields a native-code compiler, on that HW;

Technically, at #6, you could just be satisfied with that: using the SeedForth as a bytecode and the interpreter as a VM; but for a real Ada experience you really want some of the other stuff, the idea that the APSE kind of pointed to — if the system is implemented within/upon a database, then the “Library” becomes merely a subsystem within the DB… and you could also store things like “recipes”, algorithms, and even do version-control workspaces as outlined in Workspaces and Experimental Databases: Automated Support for Software Maintenance and Evolution.

The benefits of a DB-based IDE are plenty, especially because you can share components of the DB-engine and static-analysis and proof-systems, all three — this RFI response details how such a system (with VHDL and PL/SQL) could be created and used to good effect.

[VMo]

Hello,

Thanks for your answer. As I said, the Ada83 DIANA front-end derived from Peregrine and amply modified is available and translates itself ; which is already an achievement because the translator itself is already complicated.
So, but for verifications and ease of use, I consider that the frontend question is mainly solved for Ada83, which is a complicated and useful enough language.

I oscillated on the backend question between 3 addresses IR for optimization and stack IR as used by polish students, I also thought about Forth and various other possibilities as Qube. But I finally obtained my first executable a few days ago by producing stack machine fasmg macro code. The approach is defendable even if it produces lots of source writing because it allows some direct debugging by reading.

fasmg is an assembly engine which produces an output byte flux from sophisticated preprocessed/interpreted/compiled macro language. I think it is a better intermediate target than producing C for example, and a stack IR can be immediately translated to target machine code through fasm macros. Even without optimization, some acceptable X86 code can be obtained. This path is better than virtual machines which pose problems with interpreter/hardware decoupling (branch prediction desync for example).

As a simple example my first exec running without seg fault (!) from test.adb :

PROCEDURE TEST IS
  I	: INTEGER := 0;
  J	: INTEGER := 1;
BEGIN
  I := J + 1;
END;

is front-end compiled to DIANA and then DIANA converted to fasmg macro text (TEST.DCL.COD file) :

namespace TEST
elab:
  virtual at 8
    LOC::
  end virtual
	LINK 1,	loc_siz

  virtual LOC
    align_w
    I_disp = $
    dw ?
  end virtual
	LDI	 0
	STw  1,	I_disp

  virtual LOC
    align_w
    J_disp = $
    dw ?
  end virtual
	LDI	 1
	STw  1,	J_disp

  virtual LOC
    loc_siz = $
  end virtual
begin:
	LDw  1,	J_disp
	LDI	 1
	ADD
	STw  1,	I_disp
	UNLINK 1
	RTD
end namespace 

This text is included in a fasmg “launch file” with preinclusion of stack machine macros for LDw, ADD, and so on ; as well as a simple ELF64 header/program header.

include '../../src/code_gen/fasmg/codi_x86_64.fas'

	CALL	TEST.elab
	SYSEXIT

include 'TEST.DCL.COD'

So that fasmg assembly of the “launch file” produces a directly working x86-64 ELF64 executable (displayed without 120 byte header) :

0000000000000078 <.data+0x78>:
  78:   e8 07 00 00 00          call   0x84
  7d:   6a 3c                   push   $0x3c
  7f:   58                      pop    %rax
  80:   31 ff                   xor    %edi,%edi
  82:   0f 05                   syscall
  84:   41 51                   push   %r9
  86:   49 89 e1                mov    %rsp,%r9
  89:   48 83 ec 0c             sub    $0xc,%rsp
  8d:   50                      push   %rax
  8e:   6a 00                   push   $0x0
  90:   58                      pop    %rax
  91:   66 41 89 41 f8          mov    %ax,-0x8(%r9)
  96:   58                      pop    %rax
  97:   50                      push   %rax
  98:   6a 01                   push   $0x1
  9a:   58                      pop    %rax
  9b:   66 41 89 41 f6          mov    %ax,-0xa(%r9)
  a0:   58                      pop    %rax
  a1:   50                      push   %rax
  a2:   66 41 8b 41 f6          mov    -0xa(%r9),%ax
  a7:   50                      push   %rax
  a8:   6a 01                   push   $0x1
  aa:   58                      pop    %rax
  ab:   5b                      pop    %rbx
  ac:   01 d8                   add    %ebx,%eax
  ae:   66 41 89 41 f8          mov    %ax,-0x8(%r9)
  b3:   58                      pop    %rax
  b4:   4c 89 cc                mov    %r9,%rsp
  b7:   41 59                   pop    %r9
  b9:   c3                      ret

It is a work in progress very imperfect for now but it is working.
Next objective is modifying target stack management (using rax as top register interfers with calls) and producing the hello exec from :

with TEXT_IO;
use  TEXT_IO;
PROCEDURE TEST_1 IS
  MSG	:constant STRING	:= "Bonjour";
BEGIN
  PUT_LINE( MSG );
END;

Though simple, it implies using a TEXT_IO code, somewhat more complex than just a PUT_STR macro for parametrizing a write syscall.

[VMo]

Hello to all !

Just a short post to tell that the test_1.adb “hello world” (Bonjour) program has been compiled and produced a viable x86-64 executable.

A Machine_Code package has been added and enabled in the Ada83/DIANA translator.

Then a Text_IO package squeleton with a Put_Line procedure (syscall through machine code insertions) has been correctly compiled to fasmg macro engine text TEXT_IO.FINC (fasmg include file).
The Test_1 procedure calling Text_IO.Put_Line was compiled to TEST_1.FINC

Finally the fasmg assembler took the launcher test_1.fas file which includes TEST_1.FINC itself including TEXT_IO.FINC so that an elf64 executable of 257 bytes (includes 120 elf header bytes) that is 122 code+15 Ada string constant bytes is produced and works as expected.

Some interesting characteristics :

• No linker is necessary, assembler engine with include files and 4 passes resolves the labels and section work.
• A trick with conditional assembly based on used identifiers enables code elimination from unused package procedures.
• Elaboration is done by straight flow from elf entry to entry point for Ada program procedure elaboration and body execution.
• Machine_Code package is strictly conformant with LRM 13.8 (record aggregate, no gnu like oddities)
  So it seems a “short path” is really practicable from Ada83/DIANA to target code via fasmg macro engine intermediate code.

Next step : compiling some simple useful program with loops and floating computations.

[Exosvs]

Hi there. Are you still working on this? I see recent updates in the link.

I’m very interested in this

[VMo]

Hello !
Yes I am still working on this, but as I am alone I periodically get some rest by working on Kalinda OS or physics alternately.

In fact I worked on Ada 83 and this project for many years first transforming and understanding the DIANA translator from Peregrine. The virtual page pointer system has been completely revised a few years ago to remove some negative numbers tricks which obscured the system.

I was somewhat blocked by the complexity of building a backend for the translator, until I discovered FASM assembly engine powerful characteristics.

Last weeks I was thinking about the problem of generic implementation for Text_io. I have some ideas but a few points are still obscure on how I can compile the generic once and use a standard code for various instantiations.

Simultaneously I added the loops and began coding indexed arrays.

For now the code is a direct translation to stack IR and x86-64 machine code, at some point a 3 address IR will have to be inserted to optimize code (index computations and loops lead to suboptimal stack code).

I you are interested, feel free to take a look at the framagit project. If you need some explanations, tell me. Surely some organization should be arranged to work in team on this project.