[Info-vax] Listeners in VMS Basic, was: Re: Integrity iLO Configuration?

[Richard Maher]

On 26/06/2021 9:57 am, Dave Froble wrote:
> On 6/25/2021 9:07 PM, John Reagan wrote:
>> Sorry for the late response, I was on the road all day.  Typing
>> this now from scenic Hagerstown Maryland on my way to visit my
>> sister for a week+
>> 
>> BASIC.  There are several reasons why BASIC is lagging....
>> 
>> The RTL LOVES to walk the stack.  We found a bug in one of the
>> LIB$X86 Calling Standard routines that no other language found.
>> Just printing a string causes the RTL to walk up the stack back to
>> the routine that literally just called the RTL.
>> 
>> The compiler and RTL LOVE floating point.  Printing an integer 
>> involves converting it to a floating point, converting that to a 
>> string, and printing everything to the left of the decimal point.
>> And even with the default being IEEE, we found that Itanium BASIC
>> still wants to use VAX floating.
>> 
>> And we found some other bugs in the RTL (like one routine passing
>> the address of short to another routine that wrote a longword
>> value).
>> 
>> BASIC was [ab]using a GEM interface to place stack allocated
>> variables at known offsets on the stack frame.  No other frontend
>> does that.  We do provide that feature for static variables for
>> BLISS.  We didn't know about BASIC's stack dependency until nothing
>> worked!  G2L has to collect all of the different GEM stack
>> variables, combine them into a single 'container' variable to give
>> to LLVM and then convert all of the references into offsets in the
>> container.   Getting the debug info right will be a nightmare and
>> describing all the jiggery pokery to the LLVM optimizer might not
>> be 100%.
>> 
>> 
>> Native compilers.  Yes, at one time the existence of native
>> compilers was tied to the definition of V9.1, but that isn't true
>> anymore. Compilers (well, other than Macro) are layered products,
>> not part of the OS.  [V9.1 doesn't contain a native Macro either.]
>> 
>> We have a native LLVM, libcxx, etc. on x86 (bootstrapped from
>> Linux). We have a native clang (with only a few OpenVMS'isms) on
>> x86.  It is wobbly but we're working through it.  Much has involved
>> clang treating "long" as 64-bits but the RTL headers and code
>> believing that "long" is only 32-bits.  As I've mentioned before,
>> we have to get the RTL to deal with both.  Doing RTL name
>> prefixing/mapping involves finding the right places in the clang
>> source tree...  And we haven't touched the libcxxabi library so no
>> exceptions (ie, TRY/CATCH) but that's OK since the compilers don't
>> use those features.
>> 
>> We are currently working on bootstrapping the GEM pieces needed for
>>  the legacy frontends (ie, processing the command line, managing
>> source files, creating symbol tables/GEM CIL, etc) so we can hook
>> up our first native legacy frontend to that native LLVM.  To make
>> it more "fun", we are using LLVM 3.4.2 with the cross-compilers but
>> are using LLVM 10.0.1 at the moment for the native compilers.  And
>> without a functional debugger, we're using DELTA for debugging.
>> Our first native compilers will probably be Macro or BLISS sometime
>> in the next month or so.
>> 
>> Mix in some recently found bugs in the G2L (GEM to LLVM converter)
>> and some missing functionality (including some needed for BASIC)
>> and things are just taking time.
>> 
>> And finally with the release of V9.1, we'll be letting more folks 
>> download it (and the cross-tools).  More people will find more bugs
>>  (thank you) but will generate questions as well.  That will take
>> time to answer them.  Please go easy on me.
>> 
> 
> John,
> 
> Perhaps not right away, but, do you see the possibility down the road
> of fixing some of those things Basic does, the stack nonsense, and
> such? Would be nice to improve Basic's performance some.
> 

Just use COBOL!