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

[Dave Froble]

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.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486