[Info-vax] Editors, was: Re: VT keyboard replacement

[John Reagan]

On Monday, November 22, 2021 at 9:41:00 AM UTC-5, Robert A. Brooks wrote:
> On 11/21/2021 10:19 PM, Michael Moroney wrote: 
> > On 11/21/2021 4:32 AM, alanfe... at gmail.com wrote: 
> > 
> >> BTW, why did it take so long for someone to fix the hard-coded 22-line 
> >> limit on EDT? How long could it have taken? Well, I'm very happy about it 
> >> now! 
> > 
> > That "someone" is myself. As to why did it "take so long", EDT was 
> > considered obsolete for decades. Nobody was actively maintaining it. I just 
> > recently posted some comments about fixing it. It was an unofficial fix, I 
> > just did it one day. But EDT fans may be happy to know that EDT was the first 
> > editor to run on x86. I forget why EVE/TPU took longer, it may have been a 
> > compiler bug that affected it but not EDT. A different problem prevented EDT 
> > from working out of the box however.
> Both editors were affected by the change on X86 where code is placed in 64-bit 
> space by default. This default can be overriden with the LINK qualifier 
> /SEGMENT_ATTRIBUTE=CODE=P0. 
> 
> The problem was that in both editors (and other areas of the operating system 
> and layered products), certain data PSECTS were marked as EXECUTABLE. This 
> worked on VAX, Alpha, and IA64, and was likely a VAX-era optimization to keep 
> certain data co-located with the relevant code. This does not work on X86; 
> Reagan can give the details. 
> 
> Both editors are written in BLISS, and early BLISS compilers (or perhaps the 
> GEM-to-LLVM converter) did not deal with the GLOBAL BIND syntax correctly. 
> 
> I drew the short straw for both editors and had the pleasure of of tracking down 
> where in the code was failing, coming up with stripped-down reproducers, and 
> bringing my findings to Reagan so he could puzzle it out. 
> 
> -- 
> -- Rob
That's a reasonable summary.

I'm working on (pardon the BLISS for those who don't understand):

GLOBAL BIND A = PLIT(1,2,3);

The BLISS frontend generates two anonymous variables (one for the count and
another for the anonymous data) then one named variable A which is linker visible
for the data, and yet another anonymous variable to represent A's count.  Of course
all of these variables occupy the same memory.  We incorrectly allocated two count
variables and ended up with:

   .long 3
   .long 0
A:
   .long 1
   .long 2
   .long 3

Code that used the count to determine how many entries are in the vector would get
zero.  Fixing that, I found another case where we over-aligned something and let an
alignment hole get between the count and the data.  None of that is goodness.

As I've said before, the single biggest difference between GEM (well, VMS compilers
in general) and LLVM is that GEM is PSECT-oriented.  PSECTs have initial values and
variables are simply bound to "PSECT+offset".  That's a low-level assembler view of
the world (but very flexible).  LLVM is variable-oriented.  Variables occupy memory and
can be assigned to sections (aka PSECTs).  Variables have initial values.  It gets really
twisted with COMMON blocks and is one of the reasons that BASIC MAP statements
are causing my grief (among other things the BASIC frontend does).  We essentially
have to skim the PSECT initializers from the frontends, figure out which variables they
apply to, derive a datatype to describe it (LLVM's initializers are "strongly types" and
have to match the size/shape of the variable they are attached to), and stitch it all
together.  We had to add extra LLVM magic to get

GLOBAL BIND A = PLIT(1,2,3);
                         B = A[1];

to work at all.  This was one of the EDT issues.