Does TLALOC still use any code from the Walnut Creek CDs (as you mentioned here), or is there any code in TLALOC derived from that code?
Hi !
The original source code of the diana front end has been completely restructured with a new TREE pointer type, integrated phases, and a gnat like naming system, amongst other modifications. So it is derived from the code I referenced, but there is now a good distance with the original.
The expander and the target_code parts are completely from myself with controlled help of Claude+ChatGPT.
I think back then , things were really shaky on the PC with out linux and using Ada on Dec was actually a really positive experience. The Data Dictionary , version numbering , QIO’s . And the slowness of everything sort of gave good excuses for conversation. And the DEC multi player flight simulator with had Bofors Guns and Mosquitos, and even star ships. Do you want to join my old man club?
Certainly
- LSE (the editor had prompt and auto-expansion on alphanumerical terminal! It was fully programmable. For example, you could program block selection by yourself (and no Python anywhere).
- DEC debugger was integrated into LSE. It had zero overhead breakpoints. The best debugger ever.
- No bindings. You could call any subprogram, any system call from Ada or other language.
PC had Turbo Pascal with the single compiler error message for all cases and the single run-time error message - frozen PC.
Oh yes, the Language Sensitive Editor, on a VT220. Bringing back good memories
DEC VMS is open source isnt it? I still dream of it. The versioning and purge , was possibly my favourite thing - it pulled my fat so far out of the fire so many times
Inherited from the FILES-11 filesystem under RSX-11.
Interesting is that Windows has file versioning now. But it is implemented in a typical MS way that few know about it and probably nobody uses it.
Unfortunately, it isn’t. VMS Sofftware Inc has developed an x86_64 version of OpenVMS, and, judging by OpenVMS OS the Alpha and Integrity are apparently still available commercially.
There is hobbyist use of VAX/VMS from the HP era, so binaries and some associated source kits were available, but that was under a restricted license.
None of these are open source.
You can find source for at least one very old version of VAX/VMS online, but does not have any evidence that it was released legally, and the source code carries copyrights from DEC with all rights reserved.
Hi all !
TARGET_CODE has been integrated in TLALOC. As the compiler gets more powerful, a DCL like CLI has been added so that commands are now typed like those examples (Linux prompt changed to SYSTEM> and TLALOC installed as command in ~/.local/bin) :
Produce the DIANA tree and stop after semantic phase :
SYSTEM> TLALOC COMPILE /STOP_PHASE=SEMANTICS dis_bonjour.adb
Compile to “.FINC” LLIR with a project path :
SYSTEM> TLALOC COMPILE /PROJECT=../my_projects/tests enum_test.adb
Produce the “.fas” LLIR header for assembly :
SYSTEM> TLALOC BIND dis_bonjour.adb
Assembling a cross ELF for arm64 and write exec map :
SYSTEM> TLALOC CODE /TARGET=ARM64 /MAP DIS_BONJOUR
I was also a DEC fan. So much time spent on micro VAX II with EVE/TPU and DEC Ada ! Also a lot of funny times on Multics.
Hi.all !
Some reorganization has been done on repositories so that I hope things are clearer.
I also modified the README which was completely out of sync after all work done during summer holidays.
The gnat compiler TLALOC is now named T1.exe . It is obtained by the script ./make_T1 in the top repo directory.
T1.exe is launched by ./T1 script which is in bin/ for example :
./T1 COMPILE source_file /PROJECT=project_path
The TLALOC compiled TLALOC (the T2, or TLALOC proper) on x86/Linux is named TLALOC.x86exe and launched by ./TLALOC script. So that for example :
./TLALOC COMPILE source_file /PROJECT=project_path
An example of the whole compilation/execute sequence for a test program (We are supposed to be in the bin/ directory, otherwise paths must be adapted :
# compile enum_test.adb
./TLALOC COMPILE enum_test.adb /PROJECT=../projects/tests_TLALOC/
# produce FAS header
./TLALOC BIND ENUM_TEST /PROJECT=../projects/tests_TLALOC/
# produce binary for x86 (default)
./TLALOC CODE ENUM_TEST /PROJECT=../projects/tests_TLALOC/
# execute enum_test
../projects/tests_TLALOC/ENUM_TEST.x86exe
In the bin/ directory the comp_PREDEFS script compiles the predefined unit with TLALOC unless T1 is given as a parameter.
The same for comp_TLALOC : without script parameter TLALOC.x86exe is used to compile and code. With the parameter T1, T1.exe compiles and fasmg assembles.
Something stange, if someone can confirm : T1.exe (a gnat executable obtained from sources by make_T1 with no compilation problem, segfaults on TARGET_CODE so that ./T1 CODE DIS_BONJOUR gives :
SYSTEM> ./T1 CODE DIS_BONJOUR
raised STORAGE_ERROR : stack overflow or erroneous memory access
SYSTEM>
This is on GET_VALUE( “TARGET”) in tlaloc.adb
-------
procedure DO_CODE
is -------
begin
TARGET_CODE( CPU_NAME=> GET_VALUE( "TARGET" ),
UNIT_NAME=> GET_VALUE( "UNIT" ),
MAP=> IS_PRESENT( "MAP" ) );
end DO_CODE;
-------
TLALOC has no problem
SYSTEM> ./TLALOC CODE DIS_BONJOUR
Assembling \[DIS_BONJOUR\]....
CARTO capacites :
elements 21225 / 1000000 differes 18 / 200000
texte 271399 / 50000000
symboles 2563 / 1048576 scopes 263 / 65536
pool 16055 / 16000000
octets 33184 / 32000000
TLALOC works better than gnat ?!
This segfault at coding concerns only the T1 gnat executable which compiles ok to FINCs and fasmg then assembles so that this segfault does not pose so much problem for me. But for gnat users it is a problem. I’ll try to figure why gnat derails, perhaps it is only on my system.
The /TARGET qualifier has been added to BIND verb so that adequate FAS file is produced. FAS extensions have been uniformized : X86_64FAS, ARM64FAS and RISCV64FAS. They are recognized by TARGET_CODE with /TARGET qualifier.
Also tests for TLALOC development have been reintegrated in tests_TLALOC and the filet script runs all tests automatically plus the compiler construction. When modifying sources, the “filet” should pass integrally (non regression tests).