[Info-vax] VMS Software Q1 '23 Update

[John Reagan]

On Thursday, January 26, 2023 at 5:27:41 PM UTC-5, Arne Vajhøj wrote:
> On 1/26/2023 9:32 AM, Arne Vajhøj wrote: 
> > I do not think the exact same problem can be recreated in 
> > Basic (as far as I can read the documentation then Basic 
> > does not allow static initialization in map's). 
> > 
> > But to show something in Basic it is easy to do with 
> > assignment: 
> > 
> > program p 
> > 
> > map (d) long lw1, long lw2 
> > 
> > external sub s1, s2 
> > 
> > lw1 = 1 
> > lw2 = 2 
> > 
> > call s1 
> > call s2 
> > 
> > print lw1, lw2 
> > 
> > end program 
> > ! 
> > sub s1 
> > 
> > map (d) word w1, word w2, word w3, word w4 
> > 
> > w2 = 1 
> > w4 = 2 
> > 
> > end sub 
> > ! 
> > sub s2 
> > 
> > map (d) byte b1, byte b2, byte b3, byte b4, byte b5, byte b6, byte b7, 
> > byte b8 
> > 
> > b4 = 1 
> > b8 = 2 
> > 
> > end sub 
> > 
> > $ bas p 
> > $ lin p 
> > $ r p 
> >  16842753      33685506
> The Fortran version with static initialization (using data statements!) 
> and no calls: 
> 
> $ type p2x.for 
> program p2 
> integer*4 lw1,lw2 
> common /d/lw1,lw2 
> data lw1/1/,lw2/2/ 
> write(*,*) lw1,lw2 
> end 
> $ for p2x 
> $ type s1.for 
> subroutine s1 
> integer*2 w1,w2,w3,w4 
> common /d/w1,w2,w3,w4 
> data w2/1/,w4/2/ 
> end 
> $ for s1 
> $ type s2.for 
> subroutine s2 
> integer*1 b1,b2,b3,b4,b5,b6,b7,b8 
> common /d/b1,b2,b3,b4,b5,b6,b7,b8 
> data b4/1/,b8/2/ 
> end 
> $ for s2 
> $ link p2x + s1 + s2 
> $ run p2x 
> 16842753 33685506 
> $ link p2x + s2 + s1 
> $ run p2x 
> 65537 131074 
> 
> (tested on VMS Alpha) 
> 
> The order of the OBJ files in the link command change the output. 
> 
> Yuck. 
> 
> Arne
Correct.  My example was a condensed version of the problem report.
The original was multiple modules.  My example is the worst case scenario
(both in terms of what the compiler has to handle and in terms of my sense
of decency).  The static initializations is what I didn't consider in the past.

For  BASIC, the example of

map (d) long lw1, long lw2

probably would accidentally create 4 longwords due to how BASIC describes
it to GEM.  I didn't take a full survey of all the frontends back at the initial G2L
design.  Mostly focused on C & BLISS (to boot the OS) followed by Fortran
and COBOL (we knew that packed decimal and complex needed special
attention).

And yes, I think Dave asked earlier.  All of the frontends (C++ is different)
continue to generate GEM CIL and GEM symbol table.  Having each frontend
generate its own LLVM IR would be much more work and you run the risk
of introducing subtle differences.  Having the single conversion in G2L
is much better.  The LLVM interface (which is in C++ and would be hard to
code to from BLISS-based frontends without an extensive set of jacket
routines [yes, LLVM has a C-based interface but it not well supported])
isn't upward compatible.  We had to make changes to the G2L code from
the version that interfaces to the LLVM used for the cross compilers and
the newer LLVM used for the native compilers.  Only a single place to change
by having G2L.