Re: Janus/Ada 3.2.1 Released!

[Optikos <optikos@verizon.net>]

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.

> 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).

> But again, note that a code generator is a small (and usually easiest) part 
> of porting to a new target. Making a usable runtime (that is, exception 
> handling, finalization, overflow checking, divide-by-zero traps, basic I/O, 
> and most of all, tasking) is generally a bigger job.

If Janus/Ada's runtime is utilizing really oddball Unix system calls that fell outside of Spec 1170, then I can see those topics being a major rethink effort, finding analogous modern Linux functionality and morphing the design & source code to the rethink.  But more likely than not, the system calls made by Janus/Ada's old Unix runtime were standardized in Spec 1170 through SUSv3/POSIX:2001 and are largely present in LSB3.0 (2005) unless one of the relative few backwards compatibilities broken in LSB5.0 (2015).

On Wednesday, June 26, 2019 at 5:40 PM UTC-5, Randy Brukardt wrote:
> "Jeffrey R. Carter" <spam.jr...@spam.not.acm.org> wrote:
> > I see that the website still refers to the compiler as 
> > Janus/Ada 95. How much additional work is needed before you have a full 
> > Ada-12 compiler? 
> 
> Probably more years than I have left on the planet. ;-) While I've mapped
> out a design for most new features, a few things have been pretty much
> ignored (esp. interfaces and real-time stuff). 
> 
> If I was able to find a business plan that made sense, it could get done 
> faster, but as it stands I don't expect to ever break even with it and as 
> such one can't really spend $$$ (as opposed to time) on it. 

Several of us here on c.l.a keep trying to help brainstorm business-model paths to expanded markets for Janus/Ada for RR Software's benefit. ;^)