Re: Janus/Ada 3.2.1 Released!

["Randy Brukardt" <randy@rrsoftware.com>]

"Optikos" <optikos@verizon.net> wrote in message 
news:8b10bd11-cc45-4842-8746-6b061bf1619d@googlegroups.com...
On Wednesday, June 26, 2019 at 5:36:29 PM UTC-5, Randy Brukardt wrote:
> "Optikos" wrote in message
> news:228117e3-4382-4faf-807e-e562c41657c4@googlegroups.com...
> ...
>> >Randy, would putting Janus/Ada's front end on
>> >0) LLVM backend
>>> >be more difficult than any major target feature listed above alone 
>>> >(e.g.:
>> >1) Janus/Ada as-is without LLVM plus ELF on x86;
>>
>> These are almost completely orthogonal: the existing code generator would
>> work for Linux, and the (old) Unix JLink did ELF.  The issue with Linux 
>> is
>> updating the runtime to use Linux system calls (these are different than 
>> the
>> ones from the old Unix).
>
>I can sympathize to some degree.  But on the other hand, Janus/Ada's old
>UNIX runtime would likely have been from the Spec 1170 era.  Putting an
>end to the Unix wars, Spec 1170 evolved into the Single Unix Specification
>(SUS).  The Linux Standard Base (LSB) pays immense homage to
>SUSv3:POSIX2001 (but not SUSv4:2008through2018 yet) without being
>perfectly compliant with SUSv3 in a minority of areas.

The old Unix compilers didn't use any C interface to make system calls, they 
actually reproduced the binary calls (a call to a particular trap address 
with a numeric code in a register - Linux does not use this same scheme). If 
one was going to follow a scheme more like the one used for Windows with a 
Linux compiler, all of that would have to be replaced. (And the 15+ years of 
changes to the runtime would have to be created.) I don't think the actual 
routines called would be that different.

>> OTOH, attaching LLVM is a totally different level of work, and I don't 
>> know
>> enough about LLVM to say how easy or hard it would be. OTOH, we did
>> something similar of Unisys, so we already have most of the ability
>> available.
>
>Prior precedent is great news!  The 4th cycle of learning (i.e., for LLVM's 
>ways) is
>usually easier than the
>1st (i.e., from scratch: Z80 for CP/M) and
>2nd (i.e., relatively easy port of 8085 concepts on the Z80 to 8086 
>concepts) and
>3rd (i.e., major stressor on the design to withstand an entirely different 
>backend than
>the 2 prior RR-Software backends).

For the record, the Unisys one was the 7th different backend for Janus/Ada:

1st & 2nd (Z80 for CP/M, 8086 for MS-DOS) directly generated with no 
intermediate code (and only peephole optimizations);
3rd (8086 for MS-DOS) using an intermediate code and full optimizer;
4th (80386 [32-bit] for MS-DOS with extender and later Windows), based on 
the 3rd but different in some ways and adding concepts from the 5th;
5th (68020 for SunOS), built for a specific customer and never released (or 
quite finished);
6th (SPARK), also built for a specific cutomer and never really tested after 
funding disappeared;
7th (U2200 for Unisys) - 36-bit 1-complement numbers, using their back-end.

                                   Randy.