Native Pascal compiler for VMS x86-64 in test field test now

[Arne Vajhøj]

I have not seen it posted here, but native Pascal compiler for
VMS x86-64 is in test field test now.

4 down (C, C++, Fortran Pascal). 2 to go (Cobol, Basic).

Arne

[Arne Vajhøj]

Get those 2 (Cobol and Basic).

Get Java and Python.

Get Rdb.

And then most ISV's/customers could put their migration
projects full speed ahead.

Arne

[Single Stage to Orbit]

On Fri, 2023-05-05 at 15:22 -0400, Arne Vajhøj wrote:
> 4 down (C, C++, Fortran Pascal). 2 to go (Cobol, Basic).

Wunderbar! And to add the icing on the cake too, I finally received my
invitation to the VSI forums!
--
Tactical Nuclear Kittens

[John Reagan]

By the way, the release notes in the kit aren't quite complete. I was rushing to get it out the door.

I'm planning on revising the kit (and the other native compilers) soon.

John

[John H Reinhardt]

I just got the email from VSI with the formal release notice. It was available in the SP site a few days early.

John H. Reinhardt
(another, not so prolific John R.)


VSI Pascal X6.3-137 for OpenVMS x86

VMS Software Inc. is pleased to announce that a test release of the Pascal compiler for OpenVMS x86 is now available. This is the first publicly accessible release of the compiler, and we will appreciate your feedback since this is a field test. Use the built-in issue report form on the SP if you are a commercial customer; community members may report bugs on our forum.

[Single Stage to Orbit]

On Mon, 2023-05-08 at 09:40 -0700, John Reagan wrote:
> > Wunderbar! And to add the icing on the cake too, I finally received
> > my invitation to the VSI forums!

> By the way, the release notes in the kit aren't quite complete.  I
> was rushing to get it out the door.
>
> I'm planning on revising the kit (and the other native compilers)
> soon.

I've extracted my old development files and wil be putting the
compilers through their paces to see if they will still work under
x86_64. Might be a few days. They last worked on OpenVMS 6.2 on VAX, 32
years ago.
--
Tactical Nuclear Kittens

[Robert A. Brooks]

On 5/8/2023 7:31 PM, Single Stage to Orbit wrote:
> I've extracted my old development files and wil be putting the
> compilers through their paces to see if they will still work under
> x86_64. Might be a few days. They last worked on OpenVMS 6.2 on VAX, 32
> years ago.

32 years ago, the current VAX/VMS version was V5.4-2

--

--- Rob

[Single Stage to Orbit]

On Mon, 2023-05-08 at 19:41 -0400, Robert A. Brooks wrote:
> > I've extracted my old development files and wil be putting the
> > compilers through their paces to see if they will still work under
> > x86_64. Might be a few days. They last worked on OpenVMS 6.2 on
> > VAX, 32 years ago.
>
> 32 years ago, the current VAX/VMS version was V5.4-2

Could've sworn it was 6.2 but the dates for 5.4 fits 1991. Oh well,
thanks.
--
Tactical Nuclear Kittens

[Jonathan]

Any chance we're going to get /noseparate compilation with the Basic compiler? We're going to have to do some (a lot of?) work if this isn't available. (It stopped working after HP v1.7 Basic compiler.)

[Arne Vajhøj]

On 5/10/2023 4:38 PM, Jonathan wrote:
> Any chance we're going to get /noseparate compilation with the Basic
> compiler? We're going to have to do some (a lot of?) work if this
> isn't available. (It stopped working after HP v1.7 Basic compiler.)

Itanium?

It seems to work (at least the qualifier is accepted) on Alpha:

$ bas/ver
VSI BASIC V1.8-005 on OpenVMS V8.4-2L2
$ bas/nosep native_test
$

Arne

[John Reagan]

/NOSEPERATE is the default. Do you mean /SEPARATE? Yes, I have a bug report that it stopped working on the latest BASIC on Itanium.

For x86, it is even more of a pain to get a single compilation to generate multiple ELF modules all inside a single .OBJ file. (That is what you get with BASIC's and Fortran's /SEPARATE. Both compilers default to /NOSEPARATE; you can also do it in BLISS just by having another MODULE/ELUDOM on the same source file).

[Arne Vajhøj]

On 5/11/2023 11:41 AM, John Reagan wrote:
> On Wednesday, May 10, 2023 at 4:38:39 PM UTC-4, Jonathan wrote:
>> Any chance we're going to get /noseparate compilation with the
>> Basic compiler? We're going to have to do some (a lot of?) work if
>> this isn't available. (It stopped working after HP v1.7 Basic
>> compiler.)
>
> /NOSEPERATE is the default. Do you mean /SEPARATE? Yes, I have a
> bug report that it stopped working on the latest BASIC on Itanium.

I cannot recreate with a trivial example. There must be something
extra needed.

Basic 1.8 on Alpha:

$ type ex.bas
program ex

external sub s1

call s1

end program
!
sub s1

external sub s2

call s2

end sub
!
sub s2

print "Hi from Basic!"

end sub
$ bas ex
$ lin ex
$ run ex
Hi from Basic!
$ libr/obj/crea ex
$ libr/obj/ins ex ex
$ libr/obj/list/name ex
Directory of ALPHA OBJECT library DISK2:[ARNE]ex.OLB;2 on 11-MAY-2023
20:14:08
Creation date: 11-MAY-2023 20:14:08 Creator: Librarian A09-32
Revision date: 11-MAY-2023 20:14:08 Library format: 3.0
Number of modules: 1 Max. key length: 128
Other entries: 3 Preallocated index blocks: 213
Recoverable deleted blocks: 0 Total index blocks used: 2
Max. Number history records: 20 Library history records: 1

Module ex
EX
S1
S2

$ bas/sep ex
$ lin ex
$ run ex
Hi from Basic!
$ libr/obj/crea ex
$ libr/obj/ins ex ex
$ libr/obj/list/name ex
Directory of ALPHA OBJECT library DISK2:[ARNE]ex.OLB;3 on 11-MAY-2023
20:14:08
Creation date: 11-MAY-2023 20:14:08 Creator: Librarian A09-32
Revision date: 11-MAY-2023 20:14:08 Library format: 3.0
Number of modules: 3 Max. key length: 128
Other entries: 3 Preallocated index blocks: 213
Recoverable deleted blocks: 0 Total index blocks used: 2
Max. Number history records: 20 Library history records: 1

Module EX
EX

Module S1
S1

Module S2
S2

Basic 1.8 on Itanium:

$ type ex.bas
program ex

external sub s1

call s1

end program
!
sub s1

external sub s2

call s2

end sub
!
sub s2

print "Hi from Basic!"

end sub
$ bas ex
$ lin ex
$ run ex
Hi from Basic!
$ libr/obj/crea ex
$ libr/obj/ins ex ex
$ libr/obj/list/name ex
Directory of ELF OBJECT library DISK1:[ARNE]ex.OLB;2 on 11-MAY-2023 20:18:05
Creation date: 11-MAY-2023 20:18:05 Creator: Librarian I01-42
Revision date: 11-MAY-2023 20:18:05 Library format: 6.0
Number of modules: 1 Max. key length: 1024
Other entries: 3 Preallocated index blocks: 213
Recoverable deleted blocks: 0 Total index blocks used: 2
Max. Number history records: 20 Library history records: 1

Module ex
EX
S1
S2

$ bas/sep ex
$ lin ex
$ run ex
Hi from Basic!
$ libr/obj/crea ex
$ libr/obj/ins ex ex
$ libr/obj/list/name ex
Directory of ELF OBJECT library DISK1:[ARNE]ex.OLB;3 on 11-MAY-2023 20:18:05
Creation date: 11-MAY-2023 20:18:05 Creator: Librarian I01-42
Revision date: 11-MAY-2023 20:18:05 Library format: 6.0
Number of modules: 3 Max. key length: 1024
Other entries: 3 Preallocated index blocks: 213
Recoverable deleted blocks: 0 Total index blocks used: 2
Max. Number history records: 20 Library history records: 1

Module EX
EX

Module S1
S1

Module S2
S2

Arne

[Jonathan]

It is, weirdly, triggered by the specific length of the source file path after logical evaluation. I have a reproducer, if you're interested.

[Jonathan]

Sorry, yes I meant /SEPARATE. (We hard-wired /SEPARATE into our build system decades ago when we migrated from Basic-Plus2; not using it caused problems and we punted. I can't remember if it was the default in BP2. I suspect it was.)
We've got 25,000 lines of .com files to build over 1,000,000 lines of code, so there's some work to redoing this, mostly involving updating link library lists. A working /SEPARATE means no work :). We would also end up linking against shared memory that isn't accessed, which seems ugly.

Jonathan

[John Reagan]

Absolutely. Back when I first saw the report, I tried to find the edit that caused the regression. The only that could have been at fault
seemed fine (stupid, but fine) to me. Maybe this one will trigger something. Post here or email to me at some guessable email account.

[Jonathan]

I sent to the (I hope) guessable email account.

Jonathan