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

[Dave Froble]

On 6/25/2021 11:09 PM, Richard Maher wrote:
> 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!

Not a chance.  Cobol was one of the first languages I learned, and I 
also learned to dislike it.

-- 
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