Janus/Ada 3.2.1 Released!

Janus/Ada 3.2.1 Released!

[Randy Brukardt]

A new version of Janus/Ada has finally made it to release. This version 
includes recognition of the full Ada 2012 syntax, null exclusions, private 
with, a number of language-defined libraries from both Ada 2005 and 2012, 
and code quality warnings to detect likely bugs early.

Read the full announcement at 
http://www.rrsoftware.com/html/blog/ja-321a-rel.html.

Existing customers with a current support agreement (including those in 
their first 90 days of ownership) can download the new version and use their 
existing key to unlock it. For everyone else, see our website for pricing: 
http://www.rrsoftware.com/html/companyinf/prices.htm.

                                              Randy Brukardt.

P.S. I apologize to anyone that would rather not see the blatant ad. I try 
not to do this more often than once per year, and the information ought to 
be relevant to those who sometimes forget that there are other, actively 
developed Ada compilers out there. 

Re: Janus/Ada 3.2.1 Released!

[Jeffrey R. Carter]

On 6/26/19 7:12 AM, Randy Brukardt wrote:
> A new version of Janus/Ada has finally made it to release. This version
> includes recognition of the full Ada 2012 syntax, null exclusions, private
> with, a number of language-defined libraries from both Ada 2005 and 2012,
> and code quality warnings to detect likely bugs early.

Good news. 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?

-- 
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72

Re: Janus/Ada 3.2.1 Released!

[briot.emmanuel]

> P.S. I apologize to anyone that would rather not see the blatant ad. I try 
> not to do this more often than once per year, and the information ought to 
> be relevant to those who sometimes forget that there are other, actively 
> developed Ada compilers out there.

I think such an announce is completely fine in this newsgroup. It isn't as if we are swamped by ads for Ada offerings...

Thanks for sharing
Emmanuel

Re: Janus/Ada 3.2.1 Released!

[Dmitry A. Kazakov]

On 2019-06-26 07:12, Randy Brukardt wrote:

> P.S. I apologize to anyone that would rather not see the blatant ad. I try
> not to do this more often than once per year, and the information ought to
> be relevant to those who sometimes forget that there are other, actively
> developed Ada compilers out there.

What? Compiler info is the most important Ada topic I can imagine. 
Certainly far more on topic than discussions about square brackets! (:-))

P.S. I hope Janus will target Linux some day. It could be a 
Windows-hosted cross. I think many would buy that thing.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Janus/Ada 3.2.1 Released!

[Shark8]

On Tuesday, June 25, 2019 at 11:12:18 PM UTC-6, Randy Brukardt wrote:
> A new version of Janus/Ada has finally made it to release. This version 
> includes recognition of the full Ada 2012 syntax, null exclusions, private 
> with, a number of language-defined libraries from both Ada 2005 and 2012, 
> and code quality warnings to detect likely bugs early.
> 
> Read the full announcement at 
> http://www.rrsoftware.com/html/blog/ja-321a-rel.html.
> 
> Existing customers with a current support agreement (including those in 
> their first 90 days of ownership) can download the new version and use their 
> existing key to unlock it. For everyone else, see our website for pricing: 
> http://www.rrsoftware.com/html/companyinf/prices.htm.
> 
>                                               Randy Brukardt.
> 
> P.S. I apologize to anyone that would rather not see the blatant ad. I try 
> not to do this more often than once per year, and the information ought to 
> be relevant to those who sometimes forget that there are other, actively 
> developed Ada compilers out there.

Awesome news.

Re: Janus/Ada 3.2.1 Released!

[Optikos]

On Wednesday, June 26, 2019 at 3:52:51 AM UTC-5, Dmitry A. Kazakov wrote:
> On 2019-06-26 07:12, Randy Brukardt wrote:
> 
> > P.S. I apologize to anyone that would rather not see the blatant ad. I try
> > not to do this more often than once per year, and the information ought to
> > be relevant to those who sometimes forget that there are other, actively
> > developed Ada compilers out there.
> 
> …
> 
> P.S. I hope Janus will target Linux some day. It could be a 
> Windows-hosted cross. I think many would buy that thing.

I concur, but the highest-RoI would be for Janus/Ada to have the LLVM backend in one fell swoop.  Then we as users would naturally get various object-file formats (e.g., ELF, XCOFF) and ISAs (e.g., Apple ARM) and debug formats (e.g., gdb's; lldb's)—both native and cross-compiled—inherited as a by-product, killing multiple birds with one stone.

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;
2) Janus/Ada as-is without LLVM plus PE-on-ARM for the forthcoming ARM-based bendable/foldable Surface Phone thingy-whatever-it-will-be-called, deriving from Andromeda & Courier prototypes with Composable-Shell and Windows Core OS)?

Re: Janus/Ada 3.2.1 Released!

[Jeffrey R. Carter]

On 6/26/19 10:52 AM, Dmitry A. Kazakov wrote:
> 
> What? Compiler info is the most important Ada topic I can imagine. Certainly far 
> more on topic than discussions about square brackets! (:-))

Shouldn't that be [:]] ?

I agree that this was perfectly acceptable to post here.

-- 
Jeff Carter
"IMHO, Interfaces are worthless."
Randy Brukardt
117

Re: Janus/Ada 3.2.1 Released!

[Randy Brukardt]

"Optikos" <optikos@verizon.net> 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).

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.

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.

                                                          Randy.

Re: Janus/Ada 3.2.1 Released!

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:qev4og$mk5$1@dont-email.me...
> On 6/26/19 7:12 AM, Randy Brukardt wrote:
>> A new version of Janus/Ada has finally made it to release. This version
>> includes recognition of the full Ada 2012 syntax, null exclusions, 
>> private
>> with, a number of language-defined libraries from both Ada 2005 and 2012,
>> and code quality warnings to detect likely bugs early.
>
> Good news. 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.

                                                  Randy.

Re: Janus/Ada 3.2.1 Released!

[Optikos]

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

Re: Janus/Ada 3.2.1 Released!

[Randy Brukardt]

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

Re: Janus/Ada 3.2.1 Released!

[Shark8]

On Thursday, June 27, 2019 at 11:48:49 AM UTC-6, Randy Brukardt wrote:
> 5th (68020 for SunOS), built for a specific customer and never released (or 
> quite finished);
Hm, interesting.
How much would be required to do a 68020 vxWorks [5.2]?
Or would bare-metal on the 68020 be easier?

> 6th (SPARK), also built for a specific cutomer and never really tested after 
> funding disappeared;
How much would be required to bring this up to SPARK 2014?

Also, regarding DSA, would it be possible to use Janus/Ada to split a program across, say:
(1) a Motorola 68k (running vxWorks, or bare-metal),
(2) a Sun Ultra 45 (UltraSPARC IIIi, running SunOS),
(3) several x86-64 (Intel and/or AMd, running Windows)
Or is that beyond the capabilities of the tooling? (And if so, how much would you estimate this DSA tooling to cost?)

Re: Janus/Ada 3.2.1 Released!

[Dennis Lee Bieber]

On Tue, 9 Jul 2019 08:44:25 -0700 (PDT), Shark8 <onewingedshark@gmail.com>
declaimed the following:

>
>> 6th (SPARK), also built for a specific cutomer and never really tested after 
>> funding disappeared;
>How much would be required to bring this up to SPARK 2014?
>

	I suspect that was supposed to be SPARC processor
https://en.wikipedia.org/wiki/SPARC architecture.


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: Janus/Ada 3.2.1 Released!

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:db462b34-69f3-4641-9e6b-016e9f48bd54@googlegroups.com...
> On Thursday, June 27, 2019 at 11:48:49 AM UTC-6, Randy Brukardt wrote:
>> 5th (68020 for SunOS), built for a specific customer and never released 
>> (or
>> quite finished);
> Hm, interesting.
> How much would be required to do a 68020 vxWorks [5.2]?
> Or would bare-metal on the 68020 be easier?

Hard to know. That project was abandoned around 1990, so it was Ada 83. I'd 
guess that the backend would not need a lot of changes (the basic design 
hasn't changed much). Probably the target-specific stuff wouldn't need a lot 
of changes, either (but there were a lot of options added for the U2200 
project, and those would have to be redone). The Ada parts of the runtime 
would probably not need much updating, either. However, tasking was never 
finished for that compiler, and new tasking like protected objects would 
have to be created. Similarly, finalization and exception information are 
newer than that compiler. And target I/O would have to created (for whatever 
sort of target). There's enough unknowns that it would be hard to estimate. 
Of course, if there was actually a customer for it, one could spend some 
time poring over old code to see how much would need to be changed (not 
worth it for random cla chat).

>> 6th (SPARK), also built for a specific cutomer and never really tested 
>> after
>> funding disappeared;
> How much would be required to bring this up to SPARK 2014?

SPARC, the processor, not SPARK the whatever it is :-). Sorry about any 
confusion.

> Also, regarding DSA, would it be possible to use Janus/Ada to split a 
> program across, say:
> (1) a Motorola 68k (running vxWorks, or bare-metal),
> (2) a Sun Ultra 45 (UltraSPARC IIIi, running SunOS),
> (3) several x86-64 (Intel and/or AMd, running Windows)
> Or is that beyond the capabilities of the tooling? (And if so, how much 
> would you estimate this DSA tooling to cost?)

We never did any DSA tooling (or support). I tried to keep the design so 
that it would be possible if demand for it appeared, but it never did. The 
few cases where one needed that sort of support were easier to manage with 
cooperating programs using TCP/IP streams (rather than building lots of 
complex compiler support).

I'm sure it's possible, but I don't have a clear idea of how much effort it 
would take. (Besides,anything always takes twice as much effort as expected, 
even something simple like balancing one's credit card amounts.)

                                                Randy.