[Info-vax] VMS Software Q1 '23 Update

[John Reagan]

On Wednesday, January 25, 2023 at 5:35:22 PM UTC-5, Arne Vajhøj wrote:
> On 1/25/2023 5:16 PM, John Reagan wrote: 
> > I wrote that sentence in the PDF file. Vadim is less optimistic. We'll see who is right. 
> > Depends on how often they change the water in my "head in a jar". 
> > 
> > As I've said before, the issue is COMMON blocks. When I first did the design of 
> > how to convert GEM CIL and GEM symbol table to LLVM, I didn't appreciate the 
> > difference in how COMMON blocks are described to LLVM and the UNIX environment 
> > in general. It isn't just BASIC, you can see broken COMMON blocks in the Fortran 
> > cross-compiler if you look hard enough. The problem is that the BASIC MAP statement 
> > doesn't work right and almost every BASIC program uses MAPs for something. I have 
> > a BASIC cross-compiler. If you don't use a MAP, it probably works (although the test 
> > system doesn't very far without MAP). 
> > 
> > I also didn't appreciate the complexity of how BASIC uses (exploits?) the GEM interfaces. 
> > We already found one place where it relied on the GEM implementation in spite of the 
> > GEM documentation saying "don't do that". We extended the G2L converter to emulate 
> > the GEM behavior about positioning of variables on the stack. 
> > 
> > I'm actually code reviewing (well, I haven't started reviewing yet) a solution from one 
> > of my engineers. It fixes the Fortran issues. I hope it will help BASIC but I haven't 
> > looked. We'll keep pounding on it.
> I am surprised that Fortran COMMON is a problem given 
> flang, but the details tend to be full of little devils. 
> 
> :-) 
> 
> Do you need to fix everything in G2L or can you sometimes 
> get a change into the LLVM backend? 
> 
> Arne
G2L recurses down the symbol table and converts the static variables in each block as it finds
them.  The difference is that GEM frontends can record the desired offset into the PSECT in
any order.  We sort by offset in each block, but we need to hoist all the static variables out in
another pass, sort them, and do them all at the module level.  PSECTs are created by the linker.
They exist outside the control of the compiler.  

Here's a nasty Fortran program where each subroutine initializes and reinitializes parts of the 
same common block in a particular order.

        subroutine print_common
        common /mypsect/ i1,i2
        integer*4 :: i1,i2
        write (*,10) i1,i2
10      format (' ',Z8,' ',Z8)
        return
        end

        subroutine update_longwords
        common /mypsect/ i1,i2
c start with putting hex AAAAAAAA into both longwords
        integer*4 :: i1='AAAAAAAA'X,i2='AAAAAAAA'X
        return
        end

        subroutine update_words
c and update bottom words with BBBB
        common /mypsect/ w1,w2,w3,w4
        integer*2 :: w1,w2='BBBB'X,w3,w4='BBBB'X
        return
        end

        subroutine update_bytes
c and update bottom bytes with CC
        common /mypsect/ b1,b2,b3,b4,b5,b6,b7,b8
        integer*1 :: b1,b2,b3,b4='CC'X,b5,b6,b7,b8='CC'X
        return
        end

        program main
c by now, the two longwords in the common should be
c CCBBAAAA CCBBAAAA
        call print_common
        end