Now I have a decent self hosted Ada 83 compiler, but I have some organization problems for sources, builds, binaries. unix paths are heavy to use. So a few years ago I started to think about an APSE (Ada Programming System Environment), compatible with Linux, but largely masking it.
That is TAPSE (Tlaloc’s APSE), files are organized as :
I would suggest that this is the wrong way to go.
Don’t cater to one OS, but solve the problem in-general.
Perhaps a better idea would be to use a DIANA editor, foremost: that is, think of the IR as your “native format” rather than thinking of “plain text” as the native format.
There’s a book by Grady Booch (Software Components With Ada), which introduces a visual design language (similar to flowcharts, but with Ada structures); if you map this visual-design language to DIANA (incorporating something akin to Delphi’s Object Inspector), you would have a direct-manipulation of the underlying DIANA.
I know you’re doing things w/ Ada83, but consider taking GNOGA and compiling it with exports on the useful functions, importing those exports and using them. — That said, if you’re really insistent on text-editing, I’d suggest a port Borland’s TVision; I thought there was an Ada port somewhere but all I found was this and this.
Agreed. You would want the compiler to remain portable and build on exotic platforms that are not Unix/POSIX, or Windows.
I wonder how feasible it is to build a CPU independent DIANA to C89/99 compiler written in C89/99 with no gcc or clang/llvm dependencies? You could support a lot of existing platforms out of the box including something weird like Plan 9 which has its own C dialect and tool chain. Though, you would still need a native standard library and back end for the target OS to build the native compiler.
Hi !
As I work with Linux Ubuntu, I used Linux system calls for runtime. So I targeted 3 different processors all under Linux.
When assembling with fasmg, the processor/OS couple is taken into account in the codi_xxx.finc macros file.
The TARGET_CODE reproduces the fasmg behaviour and the codi file is the model.
Hi !
It was the intent of the authors of the DIANA front end from the ASR, produce a C deliverable from the Ada to DIANA conversion.
You could rewrite the whole expander to produce C (expensive) or try to express the fasmg stack machine LLIR in C (feasible and probably not too complicated, but not my project, I want independence from other non Ada tools). If I have time I’ll have a look nonetheless.
Hi !
The DIANA implementation used in TLALOC is not well adapted to modifications involved in editing, it is a semi static construction from parsing to write_lib through semantics. In the process the tree is augmented, never really modified with elements deleted and replaced. DIANA editing should be at syntax tree level (DIANA syntax subset) with a specific dynamic data structure adapted to editing.
This seems counter to the design of DIANA: that it is a tree-like abstract-data-type structure. — Thus, I would think that an implementation would have been done with that in-mind, s.t. you could use tree-/graph- transforms/editing to “take care of everything at once”, and essentially have ASIS “for free” (that is the queries and transforms would be handled simply, by hooking the structure and/or transforms directly).
I think it’s how I would handle implementing IDL (and thus DIANA) in Ada-2012: use Indefinite_Multiway_Tree on the IDL_Base'Class and have nodes [descendants of IDL_Base] handling structure, process, etc. — processing the IDL (ie producing the target-language module) would then produce (eg processing DIANA.IDL for Ada) the packages which themselves define the type[s]; you then use that to manipulate the underlying data-structure.
The Ada 83 source of TLALOC can be compiled everywhere you have an Ada 83 compatible compiler (often gnat). Let us call the resultant executable T1.
With T1, the COMPILE verb will produce FINC text files from Ada 83 source everywhere.
But, if your program submitted to T1 uses runtime (TEXT_IO, DIRECT_IO, ..), then it will currently execute (on 3 different processors) only under Linux because Linux Syscalls are used in codi files. This is the case of TLALOC T2. So TLALOC T2 can only build itself currently on Linux.
This was a choice of development because it is what I have at hand, it could be adapted with ad hoc codi files. Probably a Windows version of codi would be a good idea.
Now a precision : codi files are initially used with fasmg, then TARGET_CODE (the independent assembler of TLALOC) is modelled after codi files. That is, a Windows version would entail writing another EMITS package for CODE verb internal assembly. Nonetheless the fasmg process is always available at the condition of having an Intel x86 because fasmg only knows this processor.
Void Linux using lib Musl is my daily driver. Though I also also run FreeBSD on my home server, while Plan 9 runs my network and the focus of most of my programming work. I use Windows, but only when I have to these days. My website runs on an OpenBSD VPS.
